Zones de disponibilité dans Azure Kubernetes Service (AKS)

Article
02/05/2025

Les zones de disponibilité contribuent à protéger les applications et les données contre les défaillances de centre 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.

L’utilisation d’AKS avec des zones de disponibilité distribue physiquement les ressources entre différentes zones de disponibilité au sein d’une seule région, ce qui améliore la fiabilité. Le déploiement de nœuds dans plusieurs zones n’entraîne pas de coûts supplémentaires.

Cet article explique comment configurer des ressources AKS pour utiliser des zones de disponibilité Azure.

Ressources AKS

Ce diagramme montre les ressources Azure qui sont créées lorsque vous créez un cluster AKS :

Plan de contrôle AKS

Microsoft héberge le plan de contrôle AKS, le serveur d’API Kubernetes et les services tels que scheduler et etcd en tant que service managé. Microsoft réplique le plan de contrôle dans plusieurs zones.

D’autres ressources de votre cluster sont déployées dans un groupe de ressources managé dans votre abonnement Azure. Par défaut, ce groupe de ressources est préfixé par MC_, pour le cluster managé et contient les ressources suivantes :

Pools des nœuds

Les pools de nœuds sont créés en tant que groupe de machines virtuelles identiques dans votre abonnement Azure.

Lorsque vous créez un cluster AKS, un pool de nœuds système est requis et créé automatiquement. Il héberge des pods système critiques tels que CoreDNS et metrics-server. D’autres pools de nœuds utilisateur peuvent être ajoutés à votre cluster AKS pour héberger vos applications.

Il existe trois façons de déployer des pools de nœuds :

Étendue de zone
Zone alignée
Regional

Pour le pool de nœuds système, le nombre de zones utilisées est configuré lors de la création du cluster.

Étendue de zone

Une zone couvrant un groupe identique répartit les nœuds entre toutes les zones sélectionnées, en spécifiant ces zones avec le paramètre --zones.

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

AKS équilibre automatiquement le nombre de nœuds entre les zones.

Si une panne zonale se produit, les nœuds de la zone affectée peuvent être affectés, tandis que les nœuds d’autres zones de disponibilité ne sont pas affectés.

Zone alignée

Chaque nœud est aligné (épinglé) à une zone spécifique. Pour créer trois pools de nœuds pour une région avec trois zones de disponibilité Azure :

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Cette configuration peut être utilisée lorsque vous avez besoin d'une latence plus faible entre les nœuds. Il fournit également un contrôle plus précis sur les opérations de mise à l’échelle, ou lors de l’utilisation de l’autoscaler de cluster.

Remarque

Si une charge de travail unique est déployée sur plusieurs pools de nœuds, il est recommandé de définir ce paramètre --balance-similar-node-groups à true afin de maintenir une distribution équilibrée des nœuds entre les zones pour vos charges de travail lors des opérations de mise à l'échelle.

Régional (sans utiliser les zones de disponibilité Azure)

Le mode régional est utilisé lorsque l’affectation de zone n’est pas définie dans le modèle de déploiement ("zones"=[] or "zones"=null).

Dans cette configuration, le pool de nœuds crée des instances régionales (non épinglées à une zone) et place implicitement des instances dans toute la région. Il n’existe aucune garantie pour l’équilibre ou la répartition entre les zones, ou que les instances atterrissent dans la même zone de disponibilité.

Dans le cas rare d'une panne totale de la zone, une ou toutes les instances du pool de nœuds peuvent être affectées.

Pour valider l'emplacement des nœuds, exécutez la commande suivante :

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

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

Déploiements

Pods

Kubernetes est conscient des zones de disponibilité Azure et peut équilibrer les pods entre les nœuds dans différentes zones. Si une zone devient indisponible, Kubernetes déplace automatiquement les pods des nœuds affectés.

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 visualiser les nœuds de pods en cours d'exécution, exécutez la commande suivante :

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

Le paramètre « maxSkew » décrit le degré dans lequel les pods peuvent être distribués de manière inégale. En supposant trois zones et trois réplicas, la définition de cette valeur sur 1 garantit que chaque zone a au moins un pod en cours d’exécution :

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Stockage et volumes

Par défaut, Kubernetes versions 1.29 et ultérieures utilisent des disques managés Azure à l’aide de ZRS (Zone-Redondant-Storage) pour les revendications de volume persistant.

Ces disques sont répliqués entre les zones, afin d'améliorer la résilience de vos applications et de protéger vos données contre les défaillances du centre de données.

Exemple de revendication de volume persistant qui utilise ssd standard dans ZRS :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Pour les déploiements alignés sur des zones, vous pouvez créer une classe de stockage avec le paramètre skuname défini sur LRS (stockage localement redondant). Vous pouvez ensuite utiliser la nouvelle classe de stockage dans votre revendication de volume persistant (PVC).

Bien que les disques LRS soient moins coûteux, ils ne sont pas redondants interzone et l’attachement d’un disque à un nœud dans une autre zone n’est pas pris en charge.

Exemple de classe de stockage SSD standard LRS :

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Équilibreurs de charge

Kubernetes déploie un Standard Load Balancer Azure par défaut, qui équilibre le trafic entrant entre toutes les zones d’une région. Si un nœud devient indisponible, l’équilibreur de charge redirige le trafic vers des nœuds sains.

Exemple de service qui utilise Azure Load Balancer :

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Important

Le 30 septembre 2025, l’équilibreur de charge De base sera mis hors service. Pour plus d’informations, consultez l’annonce officielle. Si vous utilisez actuellement des équilibreurs de charge De base, veillez à effectuer une mise à niveau vers Standard Load Balancer avant la date de mise hors service.

Limites

Les limitations suivantes s'appliquent à l'utilisation des zones de disponibilité Azure :

Voir Quotas, restrictions de taille des machines virtuelles et disponibilité des régions dans AKS.
Le nombre de zones de disponibilité Azure utilisées ne peut pas être modifié une fois le pool de nœuds créé.
La plupart des régions prennent en charge les zones de disponibilité Azure. Une liste peut être consultée ici.

Étapes suivantes

Apprenez-en sur le pool de nœuds système
En savoir plus sur les pools de nœuds utilisateur
En savoir plus sur l’équilibrage de charge
Meilleures pratiques relatives à la continuité d’activité et reprise d’activité dans AKS

Partager via