J’ai écrit sur la plateforme Dev.to deux articles traitant de la haute disponibilité d’un cluster Azure Kubernetes Services.
Infrastructure
Le premier disponible ici se concentre sur la partie infrastructure.
Au menu :
Configuration des pools de nœuds
Utilisation des Availability Zones
Déploiement multi région
Les SLA possible sur le cluster et les nodes
Application
Le second, disponible ici, est focus sur la partie applicative.
Au programme la configuration de la montée en charge automatique sur les pods et les nodes.
Les deux articles sont complémentaires et adressent un même objectifs 🙂 Vous ne pourrez pas vous en sortir en mettant en œuvre un seul des deux, le sujet concerne donc autant les devs que les ops 🙂 Une infrastructure résiliente c’est bien, mais si l’applicatif ne l’est pas cela ne sert à rien !
Aujourd’hui, petit trick ! Quand on déploie un cluster AKS via une commande telle que :
az aks create --name aksCluster --resource-group rgAks --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3
On retrouve bien un objet aksCluster dans le ressource group demandé :
Mais on obient également ceci :
En effet, par défaut, AKS créé un second ressource group pour le pool de noeud. Celui-ci est nommé comme ceci : MC_resourcegroup_cluster_location, ce qui ne me convient pas trop personnellement 🙂
On a cependant la main sur ce comportement grâce à l’option “–node-resource-group” :
az aks create --name aksCluster --resource-group rgAks --node-resource-group rgNodeAks
Bien utile pour mettre en place un nommage cohérent (à contrôler grâce aux policy) dans ces déploiements sur Azure plutôt que de conserver un nommage par défaut.
Azure Kubernetes Service (AKS) propose une fonctionnalité très sympa : les virtual nodes. Ils permettent aux utilisateurs de mettre à l’échelle rapidement leurs applications à l’aide de conteneurs s’exécutant en mode Serverless grâce aux Azure Container Instances.
Les nœuds virtuels assurent un provisionnement rapide des pods et sont facturés à la seconde d’exécution. Ce mode de déploiement est à envisager pour l’exécution d’une application périodiquement tel qu’un traitement batch.
Aujourd’hui parlons d’une nouveauté plutôt attendue 🙂 Microsoft introduit un “uptime SLA” pour AKS pour garantir la disponibilité de l’API Server Kubernetes, le point d’entrée de toutes les sollicitations du cluster.
Cette possibilité se positionne en parallèle du déploiement classique d’AKS, que nous connaissons déja.
Le contrat de SLA garantit une durée de bon fonctionnement de 99,95 % pour le serveur d’API Kubernetes pour les clusters utilisant des zones de disponibilité Azure et de 99,9 % pour les clusters n’utilisant pas de zones de disponibilité.
Pour atteindre ce niveau de SLA, la plateforme utilise une réplication de nodes du master sur des availability set : des “zones” d’un datacenter qui garantissent :
Des mises à jour qui ne seront pas appliquées en même temps qu’une autre zone
Une alimentation électrique spécifique
Une gestion réseau spécifique
Le coût de cet option est d’environ (il varie suivant les régions) de 0.10$ par heure par cluster.
Un cluster AKS déployé sans cette option (comme actuellement donc) conserve son SLO de 99.5% !
Le tableau récapitulatif :
La disponibilité des nœuds, quand à elle, est couverte par le contrat SLA des machine virtuelle sur lesquelles s’exécutent les pods. Pour avoir toutes les infos sur cette gestion et réussir à mettre en oeuvre un cluster AKS hautement disponible, je vous renvoie à cet article : La résilience applicative avec AKS.
Disponibilité régionale :
Cette fonctionnalité est pour le moment disponible dans ces régions :
Australia East
Canada Central
East US
East US 2
South Central US
South East Asia
West US 2
Mise en oeuvre
Pour utiliser cette garantie de disponibilité, il faudra utiliser le paramètre --uptime-sla comme dans la commande ci-dessous, fournie par Microsoft :
az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla --node-count 1 --generate-ssh-keys
Pour cela il faudra mettre à jour votre CLI en version 2.7 ! Attention, il n’est pas possible d’appliquer ou de retirer cette configuration à un cluster existant (mais ça devrait arriver) !
La différence se situe ici au niveau du SKU du cluster déployé :
Aujourd’hui, je vous propose un petit récapitulatif des projets que j’ai mis à disposition sur mon Github et qui peuvent vous servir de templates pour déployer dans un cluster AKS.
Suite au meetup sur Blazor, j’ai voulu partager un template de projet et expliquer la façon de le déployer dans un cluster Kubernetes dans Azure (AKS).
Après la mise à jour de la version de kubernetes sur nos nodes, nous allons nous intéresser désormais à une nouvelle bonne pratique : le redémarrage des nœuds du cluster AKS pour appliquer les mises à jour du système.