Zones de disponibilité dans Azure Kubernetes Service (AKS)

2025-05-12

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’Azure Kubernetes Service (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é.

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 mentionnées dans les sections suivantes.

Pools des nœuds

Les pools de nœuds sont créés dans le cadre d'ensembles de mise à l'échelle de machines virtuelles dans votre abonnement Azure.

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

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

Étendue de zone
Aligné par zone
Régional

Les zones de pool de nœuds système sont configurées lorsque le cluster ou le pool de nœuds est créé.

Étendue de zone

Dans cette configuration, les nœuds sont répartis entre toutes les zones sélectionnées. Ces zones sont spécifiées à l’aide du --zones paramètre.

# Create an AKS cluster, and create a zone-spanning system node pool 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 node pool, 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, mais les nœuds d’autres zones de disponibilité ne sont pas affectés.

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

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.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

Zone alignée

Dans cette configuration, 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é :

# # Add three new zone-aligned user node pools, 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 lorsque vous utilisez le Cluster Autoscaler.

Remarque

Si une charge de travail unique est déployée sur des pools de nœuds, nous vous recommandons de définir --balance-similar-node-groups à true afin de maintenir une distribution équilibrée des nœuds entre les zones de vos charges de travail pendant les opérations d’extension.

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

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

Dans cette configuration, le pool de nœuds crée des instances régionales (et non épinglées par zone) et place implicitement des instances dans toute la région. Il n’existe aucune garantie que les instances sont équilibrées ou réparties entre les zones, ou que les instances se trouvent dans la même zone de disponibilité.

Dans le cas rare d’une panne zonale complète, 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 get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Déploiements

Pods

Kubernetes prend en compte les zones de disponibilité Azure et peut répartir les pods entre les nœuds situés dans différentes zones. Si une zone devient indisponible, Kubernetes déplace automatiquement les pods des nœuds affectés.

Comme décrit dans la référence Kubernetes É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 voir quels pods et nœuds sont en cours d’exécution, exécutez la commande suivante :

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

Le maxSkew paramètre décrit le degré de distribution inégale des pods. 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 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Stockage et volumes

Par défaut, les versions 1.29 et suivantes de Kubernetes utilisent des disques managés Azure en utilisant le stockage redondant interzone pour les demandes de volumes persistants.

Ces disques sont répliqués entre les zones pour améliorer la résilience de vos applications. Cette action permet de protéger vos données contre les défaillances du centre de données.

L’exemple suivant montre une demande de volume persistant qui utilise le SSD Standard Azure dans le stockage redondant entre zones.

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 aux zones, vous pouvez créer une nouvelle 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 requête de volume persistant.

Bien que les disques de stockage localement redondants 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.

L’exemple suivant montre une classe de stockage SSD standard de stockage localement redondante :

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 Azure Standard Load Balancer 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 Basic Load Balancer, veillez à effectuer une mise à niveau vers Standard Load Balancer avant la date de mise hors service.

Limites

Les limitations suivantes s’appliquent lorsque vous utilisez des zones de disponibilité :

Consultez Quotas, restrictions de taille des machines virtuelles et disponibilité des régions dans AKS.
Le nombre de zones de disponibilité utilisées ne peut pas être modifié après la création du pool de nœuds.
La plupart des régions prennent en charge les zones de disponibilité. Consultez la liste des régions.

Découvrez les pools de nœuds système.
Découvrez les pools de nœuds utilisateur.
Découvrez les équilibreurs de charge.
Obtenez les meilleures pratiques pour la continuité d’activité et la récupération d’urgence dans AKS.