Recommandations de résilience de zone pour Azure Kubernetes Service (AKS)

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

La résilience de zone est une partie clé de l’exécution de clusters Kubernetes de niveau production. Avec l'évolutivité à son cœur, Kubernetes tire pleinement parti de l'infrastructure indépendante dans les centres de données sans encourir de coûts supplémentaires en provisionnant de nouveaux nœuds uniquement lorsque cela est nécessaire.

Dans cet article, vous allez découvrir des recommandations pour la résilience de zone dans AKS, notamment comment :

• Rendre la zone des composants de cluster AKS résiliente.
• Concevoir des applications sans état pour les scénarios de défaillance de zone.
• Choisissez les options de redondance de stockage.
• Testez le comportement de l’application et de la plateforme pendant les erreurs zonales.

Modes de cluster AKS et résilience de zone

AKS prend en charge deux modes de cluster :

• AKS Automatic, qui fournit des valeurs par défaut de plateforme préconfigurées.
• AKS Standard, qui fournit un contrôle d’opérateur direct plus large.

Les principes de résilience de zone de cet article s’appliquent aux deux modes de cluster. La principale différence est la propriété des opérations de plateforme.

Pour obtenir un comportement complet des fonctionnalités par mode, consultez la comparaison des fonctionnalités AKS Automatic et AKS Standard.

Rendre votre zone de composants de cluster AKS résiliente

Les sections suivantes décrivent les points de décision clés pour la résilience de zone dans AKS. Ils ne sont pas exhaustifs. Vous devez également valider la résilience de zone pour les dépendances telles que les magasins de données, les systèmes d’identité et les services externes.

Créer des clusters et des pools de nœuds redondants au niveau de la zone

AKS vous permet de sélectionner plusieurs AZ pendant la création du cluster et du pool de nœuds. Dans les régions qui prennent en charge plusieurs AZ, le plan de contrôle est automatiquement réparti entre les zones. Les nœuds du pool de nœuds sont répartis entre les zones sélectionnées. Cette approche garantit que le plan de contrôle et les nœuds sont répartis entre plusieurs AZ, ce qui assure la résilience en cas de défaillance d'une AZ.

Conseils en mode cluster :

• AKS Automatic : de nombreuses valeurs par défaut de plateforme sont préconfigurées. Vous devez toujours vérifier que les charges de travail critiques pour l’entreprise sont intentionnellement distribuées entre les zones et que le comportement d’échec répond aux exigences.
• AKS Standard : Concevoir une topologie de pool de nœuds, des paramètres de mise à l’échelle et un comportement de domaine d’échec explicitement.

L'exemple suivant montre comment créer un cluster avec trois nœuds répartis sur trois AZ à l'aide de l’interface de ligne de commande Azure :

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

Une fois le cluster créé, vous pouvez utiliser la commande suivante pour récupérer la région et la zone de disponibilité de chaque nœud agent à partir des étiquettes :

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

L'exemple suivant indique la région et la zone de disponibilité pour chaque nœud d'agent :

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

Pour plus d’informations, consultez Utiliser des zones de disponibilité dans Azure Kubernetes Service (AKS).

Veiller à ce que les pods soient répartis dans les AZ

La stratégie de placement des pods relève du niveau de la charge de travail dans AKS Automatic et AKS Standard. Les valeurs par défaut de la plateforme ne remplacent pas les exigences de topologie au niveau de la charge de travail.

À compter de Kubernetes version 1.33, la Kube-Scheduler par défaut dans AKS est configurée pour utiliser la MaxSkew valeur 1 pour topology.kubernetes.io/zone:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Cette configuration vise à ne pas avoir plus d’un pod d’écart entre les zones, ce qui réduit le risque qu’une défaillance zonale provoque une interruption du déploiement.

Si votre déploiement a des besoins de topologie spécifiques, remplacez ces paramètres par défaut dans votre spécification de pod. Vous pouvez utiliser des contraintes d’étalement de topologie des pods à l’aide des étiquettes zone et hostname pour répartir les pods entre les AZ d’une région et entre les hôtes au sein des AZ.

Par exemple, supposons que vous disposez d’un cluster à quatre nœuds où se trouvent trois pods étiquetés app: mypod-app dans node1, node2 et node3 respectivement. Si vous souhaitez que le déploiement entrant soit hébergé sur des nœuds distincts autant que possible, vous pouvez utiliser un manifeste similaire à l’exemple suivant :

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Pour plus d’informations sur la configuration de la distribution des pods et la compréhension des implications de MaxSkew, consultez la documentation sur la topologie des pods Kubernetes. Par exemple, comment nodeTaintsPolicy: Honor affecte la distribution des pods.

Configurer le réseau compatible avec AZ

Si vous avez des pods qui servent le trafic réseau, vous devez équilibrer la charge du trafic sur plusieurs AZ pour vous assurer que votre application est hautement disponible et résiliente aux pannes. Vous pouvez utiliser Azure Load Balancer pour distribuer le trafic entrant entre les nœuds de votre cluster AKS.

Azure Load Balancer prend en charge l’équilibrage de charge interne et externe, et vous pouvez le configurer pour utiliser une référence SKU Standard pour l’équilibrage de charge redondant interzone. La référence SKU Standard est la référence SKU par défaut dans AKS et prend en charge la résilience régionale avec les zones de disponibilité pour vous assurer que votre application n’est pas affectée par un échec de région. En cas de défaillance d'une zone, un équilibreur de charge Standard SKU redondant n'est pas affecté par la défaillance et permet à vos déploiements de continuer à servir le trafic des zones restantes. Vous pouvez utiliser un équilibreur de charge global, tel que Front Door ou Traffic Manager, ou utiliser des équilibreurs de charge inter-régions devant vos clusters AKS régionaux pour vous assurer que votre application n’est pas affectée par des défaillances régionales. Pour créer une équilibreur de charge des références SKU Standard, consultez Utiliser un équilibreur de charge Standard dans Azure Kubernetes Service (AKS).

Pour garantir la résilience du trafic réseau de votre application en cas de défaillance, vous devez configurer un réseau compatible avec AZ pour vos charges de travail AKS. Azure propose différents services de mise en réseau qui prennent en charge AZ :

• passerelle VPN Azure : vous pouvez déployer des passerelles VPN et ExpressRoute dans AZ Azure pour améliorer la résilience, la scalabilité et la disponibilité des passerelles de réseau virtuel. Pour plus d’informations, consultez Créer des passerelles de réseau virtuel redondantes interzones dans les zones de disponibilité.
• Azure Application Gateway v2 : Azure Application Gateway fournit un équilibreur de charge L7 régional avec prise en charge de la zone de disponibilité. Pour plus d’informations, consultez Diriger le trafic web avec Azure Application Gateway.
• Azure Front Door : Azure Front Door fournit un équilibreur de charge L7 global et tire parti des points de présence (POP) ou du réseau de distribution de contenu Azure (CDN). Pour plus d’informations, consultez Emplacements POP d’Azure Front Door.

Mise en place d'un registre de conteneurs géo-répliqués et redondants par zone

Pour vous assurer que vos images de conteneurs sont hautement disponibles et résistent aux pannes, vous devez mettre en place un registre de conteneurs redondant par rapport à la zone. La référence SKU Premium Azure Container Registry (ACR) prend en charge la géo-réplication et la redondance de zone facultative. Ces caractéristiques assurent la disponibilité et réduisent les temps de latence pour les opérations régionales.

Assurer la disponibilité et la redondance des clés et des secrets

Azure Key Vault fournit plusieurs couches de redondance pour vous assurer que vos clés et secrets restent disponibles pour votre application même si des composants individuels du service échouent, ou si les régions Azure ou les AZ ne sont pas disponibles. Pour plus d’informations, consultez Disponibilité et redondance d’Azure Key Vault.

Utiliser des fonctionnalités de mise à l’échelle automatique

Vous pouvez améliorer la disponibilité et la résilience des applications dans AKS à l'aide des fonctions de mise à l'échelle automatique, qui vous aident à atteindre les objectifs suivants :

• Optimisez l'utilisation des ressources et la rentabilité en augmentant ou en réduisant l'échelle en fonction de l'utilisation du CPU et de la mémoire de vos pods.
• Améliorer la tolérance aux pannes et la reprise en ajoutant des nœuds ou des pods supplémentaires en cas de défaillance d'une zone.

Vous pouvez utiliser Horizontal Pod Autoscaler (HPA) et Cluster Autoscaler pour implémenter la mise à l’échelle automatique dans AKS. Le HPA adapte automatiquement le nombre de pods dans un déploiement en fonction de l'utilisation observée du processeur, de l'utilisation de la mémoire, des mesures personnalisées et des mesures d'autres services. L'autoscaler de clusters ajuste automatiquement le nombre de nœuds dans un pool de nœuds en fonction des pods en attente et des demandes de ressources des pods en attente.

Conseils en mode cluster :

• AKS Automatic : Concentrez-vous sur les demandes et limites de charge de travail, les stratégies de distribution des pods et les contrôles d’interruption afin que la mise à l’échelle de la plateforme préconfigurée puisse récupérer le service pendant le stress zonal.
• AKS Standard : Concevez explicitement les limites du pool de nœuds, la stratégie de mise à l’échelle et les paramètres de mise à l’échelle automatique pour s’aligner sur les contraintes de planification prenant en charge les zones.

La fonctionnalité fournisseur AKS Karpenter active le provisionnement automatique des nœuds à l’aide de Karpenter sur votre cluster AKS. Pour plus d’informations, consultez la vue d’ensemble des fonctionnalités du fournisseur AKS Karpenter.

Le module complémentaire KEDA (Mise à l’échelle automatique de Kubernetes pilotée par l’événement) pour AKS applique la mise à l’échelle automatique pilotée par les événements pour mettre à l’échelle votre application en fonction des métriques des services externes pour répondre à la demande. Pour plus d’informations, consultez la section Installer l’extension KEDA dans AKS (Azure Kubernetes Service).

Stratégie de mise à l’échelle de zone par mode de cluster AKS

Pour un comportement de scale-up prenant en charge les zones, alignez votre modèle de pool de nœuds avec les contraintes du planificateur et votre mode cluster.

AKS Standard

Lors de l’utilisation de cluster Autoscaler avec des zones de disponibilité, une bonne pratique courante est un pool de nœuds par zone. Vous pouvez définir --balance-similar-node-groups sur True afin de maintenir une répartition équilibrée des nœuds entre les zones lors de la mise à l’échelle.

Pourquoi cela est important :

• Le générateur de mise à l’échelle automatique du cluster simule la planification par pool de nœuds, et non par positionnement de zone spécifique.
• Dans un pool de nœuds couvrant plusieurs zones, la mise à l’échelle peut placer un nouveau nœud dans une zone qui viole encore les contraintes strictes de répartition topologique, ce qui laisse des pods en attente.
• Virtual Machine Scale Sets utilise un équilibrage de zone best-effort. En cas de contraintes de capacité dans une zone ou d’incidents d’indisponibilité de zone, l’allocation peut échouer et mettre le pool de nœuds en temporisation.
• L’utilisation d’un pool de nœuds par zone améliore le contrôle du comportement de mise à l’échelle spécifique à la zone.

Le Cluster Autoscaler n'est pas sensible aux zones, et la répartition entre les zones est gérée par les groupes de machines virtuelles identiques (Virtual Machine Scale Sets) sous-jacents, et non par AKS. Cette bonne pratique devient encore plus pertinente lors de l’utilisation de contraintes de répartition de la topologie des pods basées sur les zones au sein d’un pool de nœuds multizone unique, car des contraintes trop restrictives peuvent laisser les pods à l’état Pending, en particulier dans les régions où la capacité est limitée ou en cas de défaillance d’une zone.

AKS Automatic

AKS Automatic utilise le comportement de nœud managé préconfiguré et les valeurs par défaut de l’autoprovisionnement des nœuds. Vous ne pouvez pas supposer que les charges de travail critiques sont résilientes en zone sans stratégie au niveau de la charge de travail.

Pour les services critiques, validez :

• Comportement de répartition de la topologie des pods entre les zones.
• Comportement de récupération pendant la pression zonale.
• Planification des résultats lorsque des contraintes strictes sont utilisées.
• Comportement de l’application lorsqu’une zone devient indisponible.

Concevoir une application sans état

Lorsqu’une application est sans état, la logique d’application et les données sont découplées et les pods ne stockent pas de données persistantes ou de session sur leurs disques locaux. Cette conception permet d'augmenter ou de réduire facilement la taille de l'application sans craindre de perdre des données. Les applications sans état sont plus résistantes aux pannes car elles peuvent être facilement remplacées ou reprogrammées sur un autre nœud en cas de défaillance d'un nœud.

Lors de la conception d’une application sans état avec AKS, vous devez utiliser des services Azure managés, tels qu’Azure Databases, Azure Managed Redis ou Stockage Azure pour stocker les données de l’application. L'utilisation de ces services garantit que votre trafic peut être déplacé d'un nœud à l'autre et d'une zone à l'autre sans risque de perte de données ou d'impact sur l'expérience de l'utilisateur. Vous pouvez utiliser les Déploiements, les Services et les Sondes d’intégrité Kubernetes pour gérer les pods sans état et garantir même la distribution entre les zones.

Prendre la décision de votre disque de stockage

Choisir le bon type de disque en fonction des besoins de l'application

Azure propose deux types de disques pour le stockage persistant : le stockage à redondance locale (LRS) et le stockage à redondance de zone (ZRS). LRS réplique vos données au sein d'un seul AZ. ZRS réplique vos données sur plusieurs AZ au sein d'une région. À partir de la version 1.29 d'AKS, la classe de stockage par défaut utilise des disques ZRS pour le stockage permanent. Pour plus d’informations, consultez Classes de stockage intégrées AKS.

La façon dont votre application réplique les données peut influencer le choix du disque. Si votre application est située dans plusieurs zones et réplique les données à l'intérieur de l'application, vous pouvez assurer la résilience avec un disque LRS dans chaque AZ, car si une AZ tombe en panne, les autres AZ disposeront des données les plus récentes. Si votre couche applicative ne gère pas cette réplication, les disques ZRS sont un meilleur choix, car Azure gère la réplication dans la couche de stockage.

Le tableau suivant présente les avantages et les inconvénients de chaque type de disque :

Pour plus d’informations sur les types de disque LRS et ZRS, consultez Redondance de Stockage Azure. Pour approvisionner des disques de stockage dans AKS, consultez Provisionner le stockage Disques Azure dans Azure Kubernetes Service (AKS).

Surveiller les performances des disques

Pour garantir des performances et une disponibilité optimales de vos disques de stockage dans AKS, vous devez surveiller les paramètres clés, tels que IOPS, le débit et la latence. Ces mesures peuvent vous aider à identifier les problèmes ou les goulets d'étranglement susceptibles d'affecter les performances de votre application. Si vous constatez des problèmes de performance constants, vous devriez peut-être reconsidérer le type ou la taille de votre disque de stockage. Vous pouvez utiliser Azure Monitor pour collecter et visualiser ces mesures et configurer des alertes pour vous avertir de tout problème de performance.

Pour plus d’informations, consultez Superviser Azure Kubernetes Service (AKS) avec Azure Monitor.

Tester la résilience AZ

Méthode 1 : cordon et drainage des nœuds dans un seul AZ

L'un des moyens de tester la résilience de votre cluster AKS consiste à vider un nœud dans une zone et à voir comment il affecte le trafic jusqu'à ce qu'il bascule dans une autre zone. Cette méthode simule un scénario réel dans lequel une zone entière est indisponible en raison d'une catastrophe ou d'une panne. Pour tester ce scénario, vous pouvez utiliser la commande kubectl drain pour supprimer correctement tous les pods d’un nœud et le marquer comme non planifié. Vous pouvez ensuite surveiller le trafic et les performances du cluster à l'aide d'outils tels que Azure Monitor ou Prometheus.

Le tableau suivant présente les avantages et les inconvénients de cette méthode :

Méthode 2 : simuler une panne AZ à l'aide d’Azure Chaos Studio

Une autre façon de tester la résilience de votre cluster AKS est d'injecter des failles dans votre cluster et d'observer l'impact sur votre application à l'aide d’Azure Chaos Studio. Azure Chaos Studio est un service qui vous permet de créer et de gérer des expériences de chaos sur les ressources et les services Azure. Vous pouvez utiliser Chaos Studio pour simuler une panne AZ en créant une expérience d'injection de fautes qui cible une zone spécifique et arrête ou redémarre les machines virtuelles (VM) dans cette zone. Vous pouvez ensuite mesurer la disponibilité, la latence et le taux d'erreur de votre application à l'aide de métriques et de journaux.

Le tableau suivant présente les avantages et les inconvénients de cette méthode :

Pour plus d’informations, consultez Qu’est-ce qu’Azure Chaos Studio ?.

Contenu connexe

• Qu’est-ce qu’AKS Automatic ?
• Guide sur les clusters AKS à redondance de zone et le stockage