DEV Community: Thomas Rannou

L'automatisation dans Azure Kubernetes Services avec Azure DevOps

Thomas Rannou — Wed, 10 Feb 2021 14:42:40 +0000

Dans cet article nous allons parler d’industrialisation avec un cluster Azure Kubernetes Services. Nous verrons comment :

Automatiser le déploiement d'un cluster avec Terraform
Automatiser le déploiement d’une application dans ce même cluster.

Let's go.

Automatiser le déploiement d’un AKS avec Terraform et Azure DevOps !

Dans cette première partie, je vous propose de configurer un pipeline Azure DevOps pour exécuter un script Terraform afin de provisionner un cluster Azure Kubernetes Services (AKS) !

Terraform

Terraform est un outil d’Infrastructure As Code qui permet de décrire les ressources (VM, VNet, Web App, cluster Kubernetes, base de données) à provisionner dans un environnement auquel on se connecte au moyen d’un provider.

Il peut s’agir d’un environnement Cloud comme Azure, AWS, GCP ou un environnement on premise virtualisé avec VMWare par exemple. L’infrastructure est décrite grâce au langage de configuration HCL (Hashicorp Configuration Language).

Pour une approche globale de Terraform avec Azure je vous renvoie à cette très bonne vidéo (et sa suite) réalisée par Stanislas Quastana.

Azure DevOps

Les élements présentés ici sont tous disponible dans ce répo GitHub.

Importer les fichiers

Dans mon projet Azure DevOps fraichement créé, onglet Repos j’importe les 6 fichiers disponibles :

Nous avons à disposition les fichiers suivants :

outputs.tf : permet de spécifier les informations renvoyées par Terraform à l’issu du déploiement
provider.tf : spécifie le provider cible : ici azurerm, permettra à Terraform de comprendre qu’il cible un déploiement dans le cloud Microsoft
variables.tf : la définition des variables utilisées dans le script
variables.tfvars : l’affectation de ces même variables
main.tf : le script Terraform en lui-même

Voyons maintenant les parties importantes de ces scripts pour notre automatisation.

Les variables

Dans le fichier .tfvars nous avons ceci :

On set les variables avec des valeurs assez abstraites pour le moment, ces variables seront renseignées à l’exécution du pipeline.

Le main.tf

Ce script contient un certain nombre de choses.
La description du Backend pour le stockage du tfstate :

La description du ressource group qui contiendra nos ressources Azure :

La définition d’un Azure Container Registry :

La définition du cluster Azure Kubernetes Services :

On remarque dans ce script l’utilisation des variable définies dans le tfvars au moyen de : ${var.nomDeLaVariable} et la relation entre les composants. Par exemple le resource_group_name et la location du cluster référence le resource group précédemment créé.

On notera également la configuration du node pool ou on précise que l’on utilisera des VM de type D2_V2 déployés dans 3 Availability Zone pour un cluster hautement disponible. Ce node pool est déployé en se basant sur le mécanisme Azure des VMSS.

J’ai également configuré un backend qui cible un Storage Account dans Azure. Cet espace de stockage héberge un conteneur : terraform-azure-kubernetes-tfstate.
Cet espace, je l’ai créé depuis le portail Azure. Il est de type Storage V2 et est en accessibilité publique. Mon conteneur est lui en accessibilité “Objet Blob”. On peut donc accéder à une ressource précise mais il n’est pas possible de lister toutes les ressources présentes dans le conteneur.

La documentation complète pour créer un Azure Storage Account est ici !

Service Connection

Avant de créer notre pipeline Azure DevOps nous aller configurer un service connection à notre tenant Azure. Pour cela dans les Project settings sélectionner l’onglet Service Connections.

Puis ajouter votre service connection. Vous devrez renseigner les informations suivantes :

Pour créer un service principal vous pouvez utiliser cette commande dans une fenêtre Powershell ou le shell du portail Azure :

az ad sp create-for-rbac --name spTerraformAzDo

Pour obtenir le tenantId et le subscriptionId vous pouvez utiliser cette commande :

az account show

Le pipeline

Il faut maintenant créer notre Pipeline pour exécuter ce script Terraform. Dans l’onglet Pipeline, choisir New Pipeline :

Mon code est ici stocké dans mon repo Azure DevOps mais il pourrait tout à fait être utilisé directement depuis mon repo GitHub.

Je choisis mon repository local :

Ici le pipeline est déjà écrit, il faut donc le réutiliser et sélectionner le fichier yml correspondant, ici nommé sobrement azure-pipelines.

Les variables du pipeline

Maintenant que notre pipeline est créé et avant de le détailler et de l’exécuter nous allons lui fournir les variables dont il aura besoin à l’exécution. Pour cela, sélectionner Variables :

Vous allez devoir créer et valoriser l’ensemble de ces variables :

Ici vous avez dû remarquer que toutes mes variables déclarées ont le même nom que la valeur affectée à la variable Terraform dans mon fichier tfvars modulo les deux underscores positionnés avant et après le nom :

aks-cluster-name = __ aks-cluster-name __

Le contenu du pipeline

Si on s’intéresse maintenant au pipeline en lui-même on y trouve tout d’abord la copie des fichiers dans un espace de travail temporaire :

Gestion des variables

Etapes très importante ! Ici nous allons parcourir les fichiers tfvars et provider.tf pour y trouver __ positionnées autour d’un nom de variable. Exemple : __ aks-cluster-name __
Quand on en trouve, on remplace le contenu par la valeur renseignée précédemment dans la variable du pipeline :

Ainsi __ aks-cluster-name __ devient “lenomdemoncluster”.

On passe ensuite à la récupération de la dernière version de Terraform précisée dans une variable également :

Il est maintenant temps de voir les 3 étapes nécessaire à Terraform pour déployer mon cluster.

Init

Le Init permet de tester la connexion à l’environnement cible, ici ma souscription Azure et mon backend. Ce backend, un storage account Azure, doit, je le rappelle, avoir été créé au préalable.

Plan

Le plan permet de comparer le contenu décrit dans le script à son infrastructure actuelle (via le tfstate). Ainsi Terraform obtient une liste d’élément à supprimer / modifier / créer.

Apply

L’étape Apply permet de réaliser le déploiement de notre infrastructure sur Azure. Ici aussi j’ai besoin de passer dans commandOptions le nom de mon fichier de variables.

(Une étape Terraform Validate peux être présente entre le Init et le Plan pour valider la sémantique du script Terraform).

Une fois mon pipeline enregistré, un build démarre :

Le pipeline est en cours d’exécution :

Si vous cliquez sur l’étape Deploy vous obtiendrez les détails de l’exécution du traitement :

Une fois l’exécution achevée, vous pourrez vérifier sur le portail Azure le bon déploiement de votre ressource group contenant un Azure Container Registry et un cluster Azure Kubernetes Services :

Une fois le script exécuté Terraform m’affichera en vert toutes les informations demandées en output.

Vérifions maintenant notre déploiement !

Je me connecte au cluster via :

Az aks get-credentials -–resource-group rg-aks --name clustervacd

Et j’exécute la commande ci-dessous pour vérifier que mes nœuds sont bien sur des Availability Zones différentes :

kubectl describe nodes | select-string -pattern '^Name:','zone='

Dans Azure, si je retourne dans mon espace de stockage je trouve mon fichier tfstate !

Grace à ce state, si je réexécute mon pipeline, il n’y aura pas de redéploiement de mon cluster, puisqu’il existe déjà.
En revanche, si je modifie le node_count dans mon main.tf et que je le positionne à 10 :

Un build se relance automatiquement et je pourrais trouver dans les logs :

Ici Terraform a identifié, grace au tfstate, que ma ressource était bien présente (0 to Add) mais qu’il faut la modifier (1 to change).

Pendant le build, mon node pool se verra appliquer la modification demandée et passera automatiquement de 3 à 10 nœuds :

Voilà pour cette automatisation du déploiement d’un cluster AKS avec Terraform et Azure DevOps ! Terraform nous a ici permis de décrire un cluster AKS hautement disponible grâce aux Availability Zone.

On passe maintenant à la configuration d’un pipeline d’intégration / déploiement continu d’une application sur ce cluster fraichement créé !

Configurer un pipeline CI/CD Azure DevOps pour déployer dans AKS

Nous allons déployer sur notre cluster AKS une application hébergée sur GitHub toujours grâce à Azure DevOps !

Prérequis

Nous avons pour le moment créé :

Un Azure Container Registry pour stocker l’image Docker générée
Un cluster Azure Kubernetes Services pour hoster mon application

On peut passer à la partie applicative !

Je crée, tout d’abord, un nouveau projet Azure DevOps :

Mon code étant hébergé sur GitHub, je peux directement passer à la création du pipeline dans l’onglet Pipeline :

J’indique que mon code est sur GitHub, il faudra que vous vous identifiez sur votre compte quand Azure DevOps vous le demandera :

Je choisis le repository concerné :
https://github.com/thomasrannou/DemoAppAzDo

Cette fois-ci je ne vais pas immédiatement lancer de build (Run). Je choisis donc de sauvegarder mon pipeline en l’état (Save) :

Avant de l’exécuter, j’ai besoin d’ajouter 2 services connexion à mon projet Azure DevOps, une connexion à mon Container Registry Azure et une seconde à mon cluster AKS.

Cela va se passer dans les “project settings”, onglet “Service Connections”. J’ajoute dans un premier temps une “Docker Registry service connection” que je nomme acr-connexion:

Vous devez ici choisir votre souscription Azure et le container registry que vous venez de créer précédemment. De même pour établir une connexion avec le cluster AKS (aks-connexion) :

De retour sur mon pipeline, on peut maintenant ajouter les variables globales (bouton Variables) :

J’ai besoin d’une variable “containerRegistry” avec l’url de ma registry précédemment créée. L’url de votre registry se présente comme ceci : nomdelaregistry suivi de azurecr.io.

Ainsi que le nom de l’image Docker “imageRepository”, ici valorisée comme ceci :

Je peux maintenant exécuter mon pipeline (Run) :

J’ai un indicateur visuel sur mon déploiement :

Une fois le build terminé, un :

kubectl get pods

m’indique que 5 pods exécutent mon application. Via un :

kubectl get services

je vois également que celle-ci est accessible via une external-ip :

Description du pipeline

On va maintenant passer en revue le pipeline que nous venons d’exécuter pour comprendre comment on en arrive à ce résultat !

Tout d’abord, on définit les variables de traitement :

Le nom de ma service connexion à mon Container Registry (acr-connexion)
Le path du dockerfile (présent sur GitHub)
Un tag automatiquement généré par le build
Le nom de mon pull secret, nous y reviendrons.

Première étape : le push sur ma registry, je dois ici renseigner que je veux effectuer un Docker « build and push » avec en paramètres :

le nom de mon repository (applicationnetcore)
le path du Dockerfile de mon projet
la connexion à utiliser pour atteindre mon registry
le tag généré précédemment

Déploiement

Le déploiement sur mon cluster Kubernetes sera réalisée grâce aux deux fichiers yml présent dans le dossier manifest de mon repository. On trouve un deployment.yml et un service.yml.

En vue de mon installation, je dois modifier (dans mon pipeline) le fichier Deployment.yml pour valoriser :
image: #{containerRegistry}#/#{imageRepository}#:#{tag}#

Pour ce faire, je vais utiliser l’instruction replacetokens. Je précise ici que je veux analyser les fichier .yml pour y trouver des chaines de caractère telles que #{texte}# et les remplacer par une valeur concrète renseignée dans les variables du pipeline (globales comme locales, les deux fonctionnent) :

Après cette étape, le contenu de mon fichier de travail deployment.yml sera par exemple :

image: registryacrdemo.azurecr.io/applicationnetcore:25

Kubernetes exige ensuite un secret pour que mon cluster puisse récupérer l’image sur mon container registry :

J’utilise enfin mes deux fichiers yml pour déployer mon application et un service pour l’exposer sur le port 80.

Modification du projet

Mon projet déployé ressemble à ceci :

Si je modifie la page pour ajouter une image, je peux créer une nouvelle branche :

Et déclencher une pull request :

Qui, une fois validée, va lancer un nouveau build coté Azure DevOps :

Mon application se met alors automatiquement à jour via un rolling update Kubernetes !

C'est la fin de cette mise en œuvre de pipeline Azure DevOps pour automatiser la gestion de mon cluster AKS ainsi que le déploiement d’applications !

J’espère que cet article vous aura été utile !
A bientôt.

Thomas

Azure Kubernetes Services en vidéos

Thomas Rannou — Sat, 06 Feb 2021 21:19:53 +0000

Bonjour,

J'ai eu l'occasion de proposer plusieurs talks sur Azure Kubernetes Services, en meetup ou conférence. Les voici agregé dans cet article par ordre d'accessibilité :)

Se simplifier Kubernetes grâce à Azure ? Merci AKS !

On ne présente plus Kubernetes, l'orchestrateur de conteneur de Google permet de déployer et mettre à l'échelle facilement nos conteneurs Docker. Azure nous propose avec AKS (Azure Kubernetes Services) une offre managée Kubernetes dans Azure pour faciliter la gestion de notre cluster k8s. Nous verrons dans cette présentation comment mettre en place cette solution pour déployer, manager et monitorer nos applications.
Vidéo : ici

Azure DevOps + Terraform + AKS = une automatisation de bout en bout pour du Kubernetes dans Azure

Aujourd'hui on aborde l'approche "Everything as Code" ! De l'infra aux apps sans oublier le CI/CD, tout est du code. Au programme : - Définition d'un cluster AKS avec Terraform - Automatisation du déploiement de l'infrastructure et des apps avec des pipelines Azure DevOps.
Vidéo : ici

Tips & Tricks pour de la haute disponibilité avec Azure Kubernetes Services

Si il y a une seule raison à retenir pour l'utilisation d'un cluster Kubernetes c'est bien pour garantir de la haute disponibilité. En théorie ça peut paraître simple mais en pratique ... Voyons ensemble les différentes stratégies pour garantir de la haute disponibilité au niveau de son infra et de ces applications dans AKS.
Vidéo : ici

Du DevOps multi Cloud avec Kubernetes et Terraform

Un cluster Kubernetes sur le Cloud c’est bien, mais sur plusieurs Clouds c’est mieux ! Mise en oeuvre, à partir d’un projet .Net Core et de script Terraform, d’un pipeline d’intégration et déploiement continu avec Azure DevOps pour déployer une application dans un cluster Kubernetes sur Azure, AWS et GCP. Ou comment rendre son application et son CI/CD agnostique du clouder utilisé !
Vidéo : ici

J'espère que ces présentations vous seront utile :)
A bientôt.

Thomas

De la haute disponibilité avec Azure Kubernetes Services : le focus Apps !

Thomas Rannou — Tue, 20 Oct 2020 09:10:01 +0000

Après s’être intéressé à la haute disponibilité de notre infrastructure, au menu aujourd'hui : la configuration de la montée en charge automatique sur nos pods et nos nodes.

Rappel sur le scaling

Il y a deux possibilités de scale.

Scaling Vertical

Si un traitement dans un pod necessite plus de ressources mémoire ou vCPU que ce que vous avez prévu mais que ce traitement ne peux être réparti sur plusieurs instances, vous devrez allouer plus de ressources à votre pod. On parle alors de scaling vertical.

Scaling horizontal

Cette méthode permet de multiplier le nombre d'instance d'une application si l'instance est trop sollicitée afin de repartir la charges.

Aujourd'hui nous allons nous concentrer sur le scaling horizontal et la façon de l'automatiser.

L’autoscaling sur les pods

Le scaling consiste à augmenter ou diminuer le nombre d’instances d’une application. Cela permet par exemple de résister à un pic de charge si votre service est fortement sollicité par moments et très peu le reste du temps. On peut configurer grâce à Kubernetes l’upscale et le downscale pour s’adapter en temps réel aux besoins de nos utilisateurs.

Montée en charge manuelle

Avant de rentrer dans le vif du sujet, petite précision sur le scaling : la commande kubectl scale vous permet de modifier instantanément le nombre d’instances dont vous souhaitez disposer pour exécuter votre application.

kubectl scale --replicas=5 deployment/myApp

Montée en charge automatique

Préparation du cluster

Je provisionne un AKS avec le monitoring activé, comme expliqué ici et je vais utiliser un container registry pour déployer mon app comme expliqué dans ce tuto.

Déploiement de mon application

Voici le yaml que j’ai écrit pour mon application :

L’élément qui va nous intéresser aujourd’hui est “ressources” avec la définition des propriétés requests et limits.

Requests, c’est ce que le pod est garanti d’avoir à sa disposition pour fonctionner. Ici mon container aura donc 100m de CPU et 15Mi de RAM.
Limits en revanche c’est une sécurité sur la consommation de ressources du container. Il ne pourra pas utiliser plus de 500m de CPU et 512Mi de RAM.

Si le pod consomme trop de ressources :

CPU : un mécanisme de throttling permet de limiter la charge CPU
RAM : le pod est détruit

Les valeurs de CPU sont définies en milli-cores. Si vous avez besoin de deux VCPU il faudra indiquer 2000m. La notation “2” sera équivalente.

Déployons mon application avec un :

Kubectl apply –f .\deploytoaks.yaml

Ajoutons de l’HPA

La commande kubectl autoscale crée un objet HorizontalPodAutoscaler (HPA) qui cible une ressource spécifiée et la fait évoluer si nécessaire. Le HPA ajuste périodiquement le nombre d’instances dupliquées en fonction de la consommation CPU ou RAM.

En cas de modification de la charge, cet objet augmente ou réduit le nombre d’instances de l’application.

Ici, je vais demander un HPA sur mon application aspwebsitenetcore. Je lui indique de scaler entre 2 et 10 réplicas. L’upscale se fera si le pourcentage CPU consommé dépasse les 10% de ce qui est alloué, ici c’est donc 10% de consommé sur les 500millicores de CPU.

kubectl autoscale deployment aspwebsitenetcore --max 10 --min 2 --cpu-percent 10

Précision : La commande kubectl get hpa me permet d’afficher mes différents scaling mis en place sur mon cluster k8s.
Je constate qu’après la mise en place de mon HPA, j’ai désormais deux pods d’opérationnel ! Les appels vers mon site web seront automatiquement répartis vers ces deux pods via le loadbalancer de Kubernetes.

Si je rééxecute un get hpa, je visualise dans la colonne targets ou se situent mes conteneurs par rapport à la limite qu’on leur a fixée :

Stress Test

Maintenant, je vais stresser un peu mon application et simuler un fort trafic sur mon site. En toute logique, l’autoscaling configuré pour mon cluster AKS doit intervenir et mon nombre de pods devraient se dupliquer. Pour ce faire je vais utiliser Vegeta !

L'installation et l'utilisation de l'outil est super simple.
Pour le télécharger, rendez vous ici

La commande me permet de lancer une "attaque" pendant 5 minutes à raison de 5 appels seconde.

echo GET http://40.121.84.148 | vegeta.exe attack -duration=5m -rate=5 -output=stress-results.bin

J'ai spécifié un output qui me permettra ensuite de générer un rapport comme ceci afin de constater la latence induite par mon test de charge.

vegeta.exe plot -title=Results stress-results.bin > stress-results-plot.html

Assez rapidement, des événements m’informent du scale up :

J’ai maintenant 5 pods d’actif :

Puis 6 :

Quand je stoppe le load, je vais constater l’inverse et voir progressivement mon nombre de pods diminuer :

Jusqu’à revenir à ma situation initiale :

Pour déterminer à quel moment scale up ou down, Kubernetes utilise un algorithme présenté ici.

Un autoscale déployé via un YAML

Et oui, il est possible de configurer un scaling via une description yaml comme celle-ci :

Je précise toujours sur quel déploiement je veux positionner mon scaling, un nombre de pod min et max et une condition ici représentée par “targetAverageValue” sur la consommation mémoire de mes conteneurs. Ici la montée en charge sera toujours entre 2 et 10 pods et le scale se fera si on dépasse les 32Mi de mémoire.

KEDA

Il est possible de configurer un autoscaling sur des métriques autres que la charge CPU et RAM. Pour se faire je vous invite à vous intéresser à KEDA.

Cet outil permet par exemple de configurer un autoscale sur :

Le nombre de message dans une queue Azure Service Bus ou RabbitMQ
Le nombre de fichiers dans Azure Storage
Des métriques customs exposées via Prometheus
et bien d'autres sources !

La liste complète ici !

Après la gestion du scaling des pods, voyons comment configurer une montée en charge sur les nodes.

Autoscaling de nodes

AKS nous offre la possibilité d’allouer et de désallouer automatiquement des nodes Kubernetes pour l’hébergement de nos applications : c’est grâce à l’autoscaler de cluster.

Création du cluster

Demandons un cluster de test :

az group create --name rg-aks --location eastus
az aks create --resource-group rg-aks --name myAKS --node-count 1 --generate-ssh-keys

Autoscale manuel

Comme vu ici AKS fonctionne avec un système de node pool. Un pool est un regroupement de nœuds dans mon cluster, chaque nœud étant une machine virtuelle Azure.

Pour scaler manuellement mes nodes il faut cibler un pool :

az aks scale --resource-group rg-aks --name myAKS --node-count 3 --nodepool-name #NodePoolName#

Pour obtenir un descriptif du/des pool(s), utilisez cette commande. On y voit le nom du pool à utiliser dans la commande ci-dessus.

az aks nodepool list --resource-group rg-aks --cluster-name myAKS

Il y a maintenant 3 nœuds, donc 3 VM pouvant héberger des pods, dans notre cluster.

Autoscale automatique

Nous avons parlé précédemment des “ressources” avec la définition des propriétés requests et limits.

L’autoscaler AKS augmente ou diminue automatiquement la taille du pool de nœuds, en analysant la demande de ressources des pods.
• Si les pods ne peuvent pas être démarrés, car il n’y a pas assez de puissance cpu/ram sur les nœuds du pool, l’autoscaler de cluster en ajoute, jusqu’à atteindre la taille maximale du pool de nœuds.
• Si les nœuds sont sous-utilisés et que tous les pods peuvent être déployés en utilisant moins de noeuds, l’autoscaler de cluster déplace les pods puis supprime des nœuds, jusqu’à atteindre la taille minimale du pool.

Pour la mise en œuvre je dois provisionner un AKS avec le support de l’autoscale sur les nodes, il faut alors spécifier une taille minimale et maximale pour le pool de nœuds.

az aks create --resource-group rg-aks --name myAKSWithAutoscale --node-count 1 --vm-set-type VirtualMachineScaleSets --enable-cluster-autoscaler --min-count 1 --max-count 3

Par ailleurs, il est possible de configurer plus finement le fonctionnement du scaling via des paramètres supplémentaires.
Par exemple :
--scan-interval : permet de fixer la fréquence d'évaluation du cluster pour un éventuel scale. Ce paramètre permettra de temporiser suite à au scaling avant de provisionner ou supprimer à nouveau une VM. La liste complète des paramètres est disponible ici

On a maintenant un cluster avec une VM dans le node pool déclaré, scalable entre 1 et 3.

Modifier son autoscale

Si mon cluster contient un seul nodepool, je peux utiliser la commande :

az aks update --resource-group rg-aks --name myAKSWithAutoscale --update-cluster-autoscaler --min-count 1 --max-count 5

Si mon cluster utilise plusieurs nodepools, je dois utiliser l'instruction az aks nodepool update, comme ceci :

az aks nodepool update --resource-group rg-aks --cluster-name myAKSWithAutoscale --name nodepool1 --update-cluster-autoscaler --min-count 1 --max-count 5

Dernier cas d'usage, si notre cluster existe mais que l’autoscale n’a pas été configuré à la création il faut l’activer via une commande sur le pool cible avec l'argument --enable-cluster-autoscaler :

az aks nodepool update --resource-group rg-aks --cluster-name myAKSWithAutoscale --name nodepool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Nous avions précédemment demandé 3 nodes mais suite à notre configuration de l’autoscale, le nombre de nœud redescend progressivement à 1 puisqu’il n’y a pas de charge sur mes nœuds !

Nous avons donc vu ici un second niveau d’autoscaling, nous permettant de provisionner des nodes dynamiquement, afin de s’adapter à la demande en ressources des pods.

Conclusion

Après avoir abordé la haute disponibilité coté Infrastructure nous avons vu aujourd'hui comment rendre nos applicatifs résilient grâce à l'autoscaling. En effet l'un ne vas pas sans l'autre ! Configuré en premier lieu sur les pods il doit également être géré sur les nodes pour une meilleure élasticité face à la charge.

Merci à Louis-Guillaume Morand et Yves de Caqueray pour la relecture et leurs précieux conseils.

Thomas

De la haute disponibilité avec Azure Kubernetes Services : le focus Infra !

Thomas Rannou — Tue, 06 Oct 2020 13:32:55 +0000

Quand on choisit d’utiliser AKS, c’est pour répondre à un besoin de haute disponibilité et de résilience applicative. Dans ce post, je vous propose d'analyser quelques points d’attention au niveau infrastructure pour atteindre ces objectifs. Nous parlerons donc ici de pools de nœuds, de déploiement multi zone et multi région ainsi que de SLA.

Organiser son cluster avec des pools de nœuds

Quand on utilise un cluster Kubernetes, nous sommes amenés à utiliser des nodes. Ces nodes sont des VMs composant le cluster permettant d’exécuter des pods contenant nos applications.

Ces nœuds sont regroupés en pool de nœuds, un regroupement logique de VM du même type grâce aux VMSS Azure (Virtual Machine Scale Set).

Petit apparté : il est possible d'utiliser des VMAS (VM avec Availability Set plutôt que des VMSS). J'en parle pour être complet mais je déconseille cette approche car il vous sera alors impossible de gérer plusieurs nodepools et configurer un autoscale sur le cluster.

Tout l’intérêt des nodepools est la possibilité de gérer des nœuds spécifiques pour exécuter nos pods afin de répondre à des besoins bien précis. Voyons comment les manipuler.

Création du cluster

Je créé un cluster AKS avec un pool de noeud de 2 VM. Important : Le cluster AKS doit utiliser un loadbalancer en SKU "Standard" pour pouvoir utiliser plusieurs pools de nœuds :

az aks create --resource-group rgAks --name myAKSCluster --vm-set-type VirtualMachineScaleSets --node-count 2 --generate-ssh-keys --load-balancer-sku standard

La commande suivante (az aks nodepool list) me renseigne sur les node pools de mon cluster. Pour le moment il n'y en a qu'un :

Ajout d’un pool de noeud

J'ajoute un second node pool contenant une VM de type D4s_v3 :

az aks nodepool add --resource-group rgAks --cluster-name myAKSCluster --name nodepool2 --node-count 1 --node-vm-size Standard_D4s_v3 --no-wait

J'ai maintenant deux pools de nœuds à disposition. Deux pools qui contiennent des VM de taille (et donc de puissance de calcul) différente ! Et nous allons tout de suite voir en quoi cette capacité est hyper intéressante :)

Le choix des noeuds

Il est possible de créer des nodes particuliers :

  •   Optimisé en quantité de mémoire ou de processeur.
  •   Avec une prise en charge GPU. 
  •   Optimisé pour le stockage.

Je ne vais pas présenter ici les différents type de VM et le nommage associé donc pour obtenir des informations sur les machine virtuelles vous pouvez consulter ce lien !

Ici par exemple je créé un pool de nœud conçu pour le calcul GPU.

az aks nodepool add --resource-group rgAks--cluster-name myAKSCluster --name gpunodepool --node-count 1 --node-vm-size Standard_NC6 --no-wait

Associer des nodes au pods

Maintenant que nous avons des nœuds spécifiques, il serait intéressant que des pods s’exécutent sur ces nœuds en conséquence. Pour ce besoin nous pouvons utiliser les notions de "taints" et "tolerations" !

  •   Si j’applique une taint à un nœud je pourrais déployer sur ce nœud uniquement des pods prévu pour la supporter.
  •   Je peux alors appliquer une toleration à un pod pour lui permettre de supporter la taint d’un nœud.

Voici les types de taint disponibles :

  •   NoSchedule : les pods qui ne tolèrent pas la taint ne seront pas déployés sur le nœud.
  •   PreferNoSchedule : Kubernetes évite de déployer les pods sur le nœud. Mais si besoin, il peut le faire.
  •   NoExecute : Même punition que le NoSchedule mais en prime, si un pod est déjà en cours d’exécution sur ce nœud, il est supprimé de celui-ci.

Grâce à ces pools de nœuds ainsi que les taints et tolerations nous avons la possibilité de prévoir des nœuds dans notre cluster AKS destinés à des types de pods bien précis. Il est donc possible d’adapter l’environnement d’exécution Kubernetes en fonction du type d’application déployé pour lui affecter plus ou moins de ressources, du stockage ou un GPU.

Quelques précisions :

  •   La création du cluster crée un pool de nœuds par défaut, qu’il n’est pas possible de supprimer.
  •   Le cluster AKS peut avoir un maximum de huit pools de nœuds et 800 nœuds dans ces 8 pools de nœuds.

Maintenant que nous avons des pools de nœuds adaptés à notre besoin, voyons comment les déployer dans Azure.

Comment déployer mes nœuds ?

On désigne par résilience la capacité d’un service à continuer de fonctionner malgré la défaillance d’un ou plusieurs éléments d’infrastructure (base de données, serveurs Web, accès réseau, … ). La résilience désigne également la capacité du service à revenir dans un mode nominal de façon automatisée.

Les régions et zones Azure

Avant de parler de régions, il faut introduire les zone géographiques. Une zone géographique correspond à une offre de déploiement de composants Azure. Par exemple France. Une zone géographique contient au minimum deux régions, qui peuvent être géorépliqué (le pairage des régions étant définis par Microsoft).
Par exemple la zone géographique France est composée de France Centre et France Sud. Celles-ci permettent de répondre à des exigences clients concernant le déploiement et le stockage des informations.

Une région est un emplacement physique de datacenter Azure. Par exemple la région France Centre est constitué de 3 datacenters situés en région parisienne.

Les zones de disponibilité sont des emplacements physiquement séparés au sein d’une région Azure comme France Centre. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un refroidissement et d’un réseau indépendants.

AKS et zones de disponibilité

Voyons l’application des zones de disponibilités sur AKS ! Si vous avez bien suivis, vous comprenez maintenant que les clusters AKS déployés à l’aide de zones de disponibilité peuvent répartir les nœuds sur plusieurs zones au sein d’une même région ! Par exemple, un cluster dans la région  France Centre  peut créer des nœuds dans les trois zones de disponibilité de France Centre. Il y aura des noeuds sur chaque datacenter composant la région.

Grace à cela votre cluster AKS est capable de tolérer une défaillance dans l’une de ces zones ; si un des datacenter de la région est indisponible la continuité de service est assuré. A contrario, si tout les nœuds de notre cluster était déployé au même endroit, le service serait indisponible.

SLA des Nodes AKS

Le SLA d’un node de notre cluster correspond au SLA de la VM utilisée par ce node.

Le SLA “standard” est à 99.9%. Si nous utilisons un availability set : 99.95% soit environ 4h d’indisponibilité par an.
Grace à l’availability zone, on monte à 99.99% soit moins d’une heure d’indisponibilité par an.

Limitations et disponibilité de la région

Attention, toutes les régions ne gèrent pas les AZ ! Nous pouvons actuellement créer des clusters AKS en utilisant des zones de disponibilité dans les régions listées ici.

Attention, quelques informations à prendre en compte !

  •   Les zones de disponibilité se gèrent à la création du cluster. Ces paramètres ne sont pas modifiables ultérieurement.
  •   Les clusters avec des zones de disponibilité activées nécessitent l’utilisation du loadbalancer SKU Standard Azure pour la distribution entre les zones.
  •   Incompatible avec les pods statefulset avec un volume persistent !

Mise en oeuvre

Le paramètre permettant d’utiliser les zones de disponibilité est zones :

az aks create --resource-group aksAvailabilityZone --name aks --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

Je me connecte à mon cluster nouvellement créé :

az aks get-credentials --resource-group aksAvailabilityZone --name aks

Pour obtenir la description des nodes :

kubectl describe nodes | select-string -pattern '^Name:','zone='

J’ai bien un node de déployé dans chaque zone de la région France Centre. Réalisons une montée en charge pour analyser la répartition des nodes :

az aks scale --resource-group aksAvailabilityZone --name myAKSCluster --node-count 5
kubectl describe nodes | select-string -pattern '^Name:','zone='

J’ai donc deux nodes sur France Centre 1 et 2, et un node sur France Centre 3. Je déploie un nginx :

kubectl run nginx --image=nginx --replicas=3

Et je demande un descriptif de mes pods :

kubectl describe pod | select-string -pattern '^Name:','^Node:'

J’ai donc un pod en zone 1 et 3. Si le premier datacenter de la région est indisponible, j'aurais toujours un pod à s'éxécuter sur un autre datacenter.

Comment fonctionne le déploiement multi zones ?

Par défaut Kubernetes est capable de répartir automatiquement les pods sur les différents noeuds du cluster. Ceci afin de prévenir la défaillance de l'un d'eux. Cependant, sans contrôle de notre part, rien ne garantit qu'ils seront répartis de façon optimale.

Dans le cas d'un déploiement multi zones il peux être intéressant d'influer sur la façon dont la répartition est effectuée.
Il pourra par exemple être pertinent de demander l'exécution de minimum 2 réplicas sur chacune des 3 AZ d'une région.

Pour ce faire nous pourrons utiliser les topology spread constraints. Associé aux labels des nodes, ces topologies nous permettront de contrôler la propagation des pods dans notre cluster afin de garantir au mieux la haute disponibilité et l'utilisation des ressources allouées.

Je vous renvoie à la doc officielle du composant pour la mise en œuvre.

Pour aller plus loin : le déploiement multi-région

Pour se prémunir de l’indisponibilité d’une région entière comme France Centre, on peux imaginer déployer deux clusters AKS sur deux régions différentes.

A ce moment-là, on peut utiliser Traffic Manager pour contrôler la façon dont le trafic est dirigé vers les clusters dans différentes régions.

On peux router le traffic suivant divers paramètres :

  •   Le temps de réponse des clusters
  •   En fonction de critères géographiques (pour connecter un utilisateur à sa région la plus proche par exemple).
  •   Si cette région rencontre un problème, Traffic Manager peux diriger l’utilisateur vers une autre région.

Nous pourrons utiliser cette approche conjointement avec la Réplication des registry afin d’accélérer les déploiements applicatifs.

Coté backend (base de données, stockage de documents) il est possible également de mettre en oeuvre des mécanismes de déploiement multi régions et de synchronisation automatique des données :

Avec une base de données SQL Database géo répliqué.
Avec un storage account avec une réplication GRS voir RA-GRS afin que les données puissent être en R/W dans les deux régions simultanément.

Concernant le master ...

En déploiement « standard » Microsoft fournit un SLO de 99.5% pour l’API Server du Master Kubernetes, point d’entrée de toutes les sollicitations au cluster.

Depuis peu Microsoft propose un “uptime SLA” pour AKS pour garantir la disponibilité de l’API Server Kubernetes.

Cette possibilité se positionne en parallèle du déploiement classique d’AKS, que nous connaissons déjà.

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 (99.9), 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 :

Pricing par région : https://azure.microsoft.com/fr-fr/pricing/details/kubernetes-service/

La disponibilité des nœuds, comme vu précédemment, est couverte par le contrat SLA des machine virtuelle sur lesquelles s’exécutent les pods.

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

Attention, il n’est pas possible de retirer cette configuration à un cluster une fois appliquée. En revanche il est possible de créer un cluster "standard" puis de configurer le uptime SLA.

La différence se verra ici au niveau du SKU du cluster déployé :

"sku": {
"name": "Basic",
"tier": "Paid"
},

Conclusion

Nous avons vu dans cet article les différents éléments composants un cluster AKS et les moyens d'optimiser leur disponibilité. Nous étions aujourd'hui concentré sur la partie infrastructure, mais attention cette gestion seule n'est pas suffisante ! Il faut également s'intéresser à la haute disponibilité applicative. Une infrastructure résiliente c'est bien, mais si l'applicatif ne l'est pas cela ne sert à rien !

Dans un prochain article nous nous intéresserons au façon de propager cette haute disponibilité aux applications avec l'autoscaling au niveau des pods comme du cluster.

J'espère que cet article vous aura apporté des informations pour la gestion de votre cluster k8s dans Azure !

Merci à Louis-Guillaume Morand et Yves de Caqueray pour la relecture et leurs précieux conseils.

Thomas