Créer un cluster Azure Kubernetes Service (AKS) qui utilise des zones de disponibilité

Article
12/06/2023

Un cluster AKS (Azure Kubernetes Service) répartit des ressources telles que des nœuds et le stockage entre des sections logiques de l’infrastructure Azure sous-jacente. L’utilisation de zones de disponibilité sépare physiquement les nœuds des autres nœuds déployés dans des zones de disponibilité différentes. Les clusters AKS déployés avec plusieurs zones de disponibilité configurées sur un cluster offrent un niveau plus élevé de disponibilité pour se protéger contre une défaillance matérielle ou un événement de maintenance planifiée.

En définissant des pools de nœuds dans un cluster de façon à ce qu’ils s’étendent sur plusieurs zones, les nœuds d’un pool de nœuds donné peuvent continuer à fonctionner même si une zone tombe en panne. Vos applications peuvent continuer à être disponibles même en cas de la défaillance physique dans un centre de donnée si elles sont orchestrées de façon à tolérer la défaillance d’un sous-ensemble de nœuds.

Cet article vous explique comment créer un cluster AKS et répartir les composants de nœud entre des zones de disponibilité.

Avant de commencer

La version 2.0.76 d’Azure CLI (ou ultérieure) doit être installée et configurée. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Limitations et disponibilité de la région

Les clusters AKS peuvent utiliser des zones de disponibilité dans n’importe quelle région Azure qui a des zones de disponibilité.

Les limitations suivantes s'appliquent lorsque vous créez un cluster AKS à l'aide de zones de disponibilité :

Vous pouvez définir des zones de disponibilité seulement lors de la création du pool de clusters ou de nœuds.
Il n’est pas possible de mettre à jour un cluster sans zone de disponibilité existant pour qu’il utilise des zones de disponibilité après qu’il a été créé.
La taille de nœud (référence SKU de la machine virtuelle) choisie doit être disponible dans toutes les zones de disponibilité sélectionnées.
Les clusters avec des zones de disponibilité activées nécessitent l’utilisation d’équilibreurs de charge Standard Azure pour la distribution entre les zones. Vous pouvez définir ce type d’équilibreur de charge seulement au moment de la création du cluster. Pour plus d'informations et connaître les limites de l’équilibreur de charge Standard, consultez Limites de la référence SKU Standard de l’équilibreur de charge Azure.

Prise en charge des zones de disponibilité des disques Azure

Les volumes qui utilisent des disques LRS managés Azure ne sont pas des ressources redondantes interzones, l’attachement à plusieurs zones n’est pas pris en charge. Vous devez colocaliser les volumes dans la même zone que le nœud spécifié hébergeant le pod cible.
Les volumes qui utilisent des disques ZRS managés par Azure sont des ressources redondantes interzones. Vous pouvez planifier ces volumes sur tous les nœuds d’agent de zone et de non-zone ; voici un exemple de création d’une classe de stockage utilisant le disque StandardSSD_ZRS :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_ZRS  # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Kubernetes prend en charge les zones de disponibilité Azure depuis la version 1.12. Vous pouvez déployer un objet PersistentVolumeClaim référençant un disque managé Azure dans un cluster AKS à plusieurs zones, et Kubernetes s’occupera de la planification des pods qui revendiquent cette PVC dans la zone de disponibilité correcte.

Modèles Resource Manager et zones de disponibilité

Quand vous créez un cluster AKS, vous devez bien comprendre les informations détaillées suivantes sur la spécification de zones de disponibilité dans un modèle :

Si vous définissez explicitement une valeur Null dans un modèle, par exemple en spécifiant "availabilityZones": null, le modèle Resource Manager traite la propriété comme si elle n’existait pas. Cela signifie que votre cluster ne se déploie pas dans une zone de disponibilité.
Si vous n’incluez pas la propriété "availabilityZones": dans votre modèle Resource Manager, votre cluster ne se déploie pas dans une zone de disponibilité.
Vous ne pouvez pas mettre à jour les paramètres des zones de disponibilité sur un cluster existant ; le comportement diffère quand vous mettez à jour un cluster AKS avec des modèles Resource Manager. Si vous définissez explicitement une valeur Null dans votre modèle pour les zones de disponibilité et que vous mettez à jour votre cluster, cela ne met pas à jour votre cluster quant aux zones de disponibilité. Toutefois, si vous omettez la propriété zones de disponibilité avec une syntaxe telle que "availabilityZones": [], le déploiement tente de désactiver des zones de disponibilité sur votre cluster AKS existant et échoue.

Vue d’ensemble des zones de disponibilité pour les clusters AKS

Les zones de disponibilité constituent une offre à haute disponibilité qui protège vos applications et données des pannes des centres de données. Les zones sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone comprend un ou plusieurs centres de données, équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Pour garantir la résilience, il existe toujours plus d’une zone dans toutes les régions activées. La séparation physique des zones de disponibilité dans une région protège les applications et les données des défaillances dans le centre de données.

Pour plus d’informations, consultez Que sont les zones de disponibilité dans Azure ?.

Les clusters AKS déployés en utilisant des 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 USA Est 2 peut créer des nœuds dans les trois zones de disponibilité de USA Est 2. Cette distribution des ressources du cluster AKS améliore la disponibilité du cluster car elles résistent aux défaillances d'une zone spécifique.

AKS node distribution across availability zones

Si une zone devient indisponible, vos applications continuent à s’exécuter sur les clusters configurés pour être répartis sur plusieurs zones.

Remarque

Lors de l’implémentation de zones de disponibilité avec le générateur de mise à l’échelle automatique du cluster, nous vous recommandons d’utiliser un pool de nœuds unique pour chaque zone. Vous pouvez définir le --balance-similar-node-groups paramètre pour True maintenir une distribution équilibrée des nœuds entre les zones de vos charges de travail pendant les opérations de scale-up. Lorsque cette approche n’est pas implémentée, les opérations de scale-down peuvent perturber l’équilibre des nœuds entre les zones.

Créer un cluster AKS sur plusieurs zones de disponibilité

Quand vous créez un cluster en utilisant la commande az aks create, le paramètre --zones définit les zones de disponibilité où déployer les nœuds d’agent. Les zones de disponibilité dans laquelle les composants du plan de contrôle managé sont déployés ne sont pas contrôlées par ce paramètre. Elles sont réparties automatiquement sur toutes les zones de disponibilité (le cas échéant) de la région pendant le déploiement du cluster.

L’exemple suivant crée un cluster AKS nommé myAKSCluster dans le groupe de ressources nommé myResourceGroup avec un total de trois nœuds. Un agent de noeud dans la zone 1, un dans la zone 2 et un dans la zone 3.

az group create --name myResourceGroup --location eastus2

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

La création du cluster AKS ne prend que quelques minutes.

Quand vous décidez de la zone à laquelle un nouveau nœud doit appartenir, un pool de nœuds AKS spécifié utilise le meilleur équilibrage des zones possible offert par les groupes de machines virtuelles identiques sous-jacents. Le pool de nœuds AKS est « équilibré » quand le nombre de machines virtuelles de chaque zone est égal à celui de toutes les autres zones du groupe identique, à + ou - 1 machine virtuelle près.

Vérifier la distribution des nœuds entre les zones

Quand le cluster est prêt, listez les zones de disponibilité où se trouvent les nœuds d’agent du groupe identique.

Tout d’abord, obtenez les informations d’identification du cluster AKS à l’aide de la commande az aks get-credentials :

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Utilisez ensuite la commande kubectl describe pour répertorier les nœuds du cluster et filtrer sur la valeur topology.kubernetes.io/zone. L’exemple suivant est destiné à un interpréteur de commandes Bash.

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

L'exemple de sortie suivant montre les trois nœuds répartis dans la région et les zones de disponibilité spécifiées, notamment eastus2-1 pour la première zone de disponibilité et eastus2-2 pour la deuxième zone de disponibilité :

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

Quand vous ajoutez des nœuds supplémentaires à un pool d’agents, la plateforme Azure distribue automatiquement les machines virtuelles sous-jacentes entre les zones de disponibilité spécifiées.

Avec Kubernetes versions 1.17.0 et ultérieures, AKS utilise l’étiquette topology.kubernetes.io/zone plus récente et l’étiquette dépréciée failure-domain.beta.kubernetes.io/zone. En exécutant le script suivant, vous pouvez obtenir le même résultat qu’en exécutant la commande kubelet describe nodes de l’étape précédente :

kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'

L’exemple suivant ressemble à la sortie avec des informations plus détaillés :

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Vérifier la distribution des pods entre les zones

Comme décrit dans Étiquettes, annotations et non-affinités connues, Kubernetes utilise l’étiquette topology.kubernetes.io/zone pour distribuer automatiquement les pods dans un contrôleur ou un service de réplication entre les différentes zones disponibles. Pour tester l’étiquette et mettre à l’échelle votre cluster de 3 à 5 nœuds, exécutez la commande suivante pour vérifier que le pod est correctement réparti :

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

Quand l’opération de mise à l’échelle se termine au bout de quelques minutes, exécutez la commande kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" dans un shell Bash. La sortie suivante ressemble aux résultats :

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

Vous avez maintenant deux nœuds supplémentaires dans les zones 1 et 2. Vous pouvez déployer une application composée de trois réplicas. L’exemple suivant utilise NGINX :

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

En affichant les nœuds où s’exécutent vos pods, vous voyez que les pods s’exécutent sur les nœuds correspondant aux trois différentes zones de disponibilité. Par exemple, avec la commande kubectl describe pod | grep -e "^Name:" -e "^Node:" dans un shell Bash, vous voyez l’exemple de sortie suivant :

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

Comme vous pouvez le voir dans la sortie précédente, le premier pod s’exécute sur le nœud 0, qui se trouve dans la zone de disponibilité eastus2-1. Le deuxième pod s’exécute sur le nœud 2, qui correspond à eastus2-3, et le troisième dans le nœud 4, dans eastus2-2. Sans aucune configuration supplémentaire, Kubernetes répartit correctement les pods entre les trois zones de disponibilité.

Étapes suivantes

Cet article explique comment créer un cluster AKS en utilisant des zones de disponibilité. Pour plus d’informations sur les clusters à haute disponibilité, consultez Best practices for business continuity and disaster recovery in AKS (Meilleures pratiques pour la continuité d’activité et la récupération d’urgence dans AKS).