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

Article
04/29/2024

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.
Lisez Vue d’ensemble des zones de disponibilité dans AKS pour comprendre les avantages et les limites liés à l’utilisation de zones de disponibilité dans AKS.

Modèles Resource Manager et zones de disponibilité

Tenez compte des détails suivants au moment de créer un cluster AKS avec des zones de disponibilité en utilisant un modèle Azure Resource Manager :

Si vous définissez explicitement une valeur Null dans un modèle, par exemple "availabilityZones": null, le modèle considère que la propriété n’existe 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 le modèle, 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, car le comportement est différent quand vous mettez à jour un cluster AKS avec des modèles Azure 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.

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

Lorsque vous créez un cluster à l’aide de la commande az aks create, le paramètre --zones spécifie les zones de disponibilité dans lesquelles les nœuds d’agent sont déployés. 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.

Les exemples de commandes suivants montrent comment créer un groupe de ressources et un cluster AKS 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.

Créez un groupe de ressources avec la commande az group create.
```
az group create --name $RESOURCE_GROUP --location $LOCATION
```
Créez un cluster AKS en utilisant la commande az aks create avec le paramètre --zones.
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --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.

Obtenez les informations d’identification du cluster AKS à l’aide de la commande az aks get-credentials :
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
```
Affichez la liste des nœuds présents dans le cluster à l’aide de la commande kubectl describe et filtrez sur la valeur topology.kubernetes.io/zone.
```
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 les étiquettes topology.kubernetes.io/zone et failure-domain.beta.kubernetes.io/zone, laquelle est déconseillée. En utilisant la commande suivante, vous pouvez obtenir le même résultat qu’en exécutant la commande kubectl describe nodes dans l’exemple précédent :

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. Dans cet exemple, vous testez l’étiquette et mettez à l’échelle votre cluster, passant de 3 à 5 nœuds, pour vérifier que le pod est correctement réparti.

Mettez à l’échelle votre cluster AKS de 3 à 5 nœuds en utilisant la commande az aks scale avec --node-count défini sur 5.
```
az aks scale \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --node-count 5
```

Une fois l’opération de mise à l’échelle terminée, vérifiez la répartition de pod entre les zones à l’aide de la commande kubectl describe suivante :

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

L’exemple de sortie suivant montre les cinq 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 :

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

Déployez une application NGINX avec trois réplicas à l’aide des commandes kubectl create deployment et kubectl scale suivantes :

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

Vérifiez la répartition de pod entre les zones à l’aide de la commande kubectl describe suivante :
```
kubectl describe pod | grep -e "^Name:" -e "^Node:"
```
L’exemple de sortie suivant montre les trois pods 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 :
```
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).

Partager via