Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Découvrez le changement de zone du contrôleur de récupération d’application (ARC) Amazon dans Amazon EKS

Kubernetes dispose de fonctionnalités natives qui vous permettent de rendre vos applications plus résilientes face à des événements tels que la dégradation de l’état ou la défaillance d’une zone de disponibilité (AZ). Lorsque vous exécutez vos charges de travail dans un cluster Amazon EKS, vous pouvez améliorer davantage la tolérance aux pannes et la récupération de votre environnement d’application en utilisant le changement de zone du contrôleur de récupération d’application (ARC) Amazon ou le changement automatique de zone. Le changement de zone ARC est conçu comme une mesure temporaire qui vous permet de déplacer le trafic d’une ressource hors d’une AZ défaillante jusqu’à l’expiration du changement de zone ou jusqu’à ce que vous l’annuliez. Vous pouvez prolonger le changement de zone si nécessaire.

Vous pouvez démarrer un changement de zone pour un cluster EKS, ou vous pouvez autoriser AWS le transfert de trafic pour vous en activant le changement automatique de zone. Ce changement met à jour le flux de trafic east-to-west réseau dans votre cluster afin de ne considérer que les points de terminaison réseau des pods exécutés sur des nœuds de travail comme sains AZs. En outre, tout ALB ou NLB gérant le trafic entrant pour les applications de votre cluster EKS acheminera automatiquement le trafic vers les cibles saines. AZs Pour les clients qui recherchent une disponibilité maximale, dans le cas où une zone de disponibilité serait défaillante, il peut être important de pouvoir détourner tout le trafic de la zone défaillante jusqu’à ce qu’elle soit rétablie. Pour cela, vous pouvez également activer un ALB ou un NLB avec le changement de zone ARC.

Comprendre le flux de trafic réseau est-ouest entre les pod

Le diagramme suivant illustre deux exemples de charges de travail, Orders et Products. Le but de cet exemple est de montrer comment les charges de travail et les pods AZs communiquent entre eux dans différents environnements.

Comprendre le changement de zone ARC dans Amazon EKS

En cas de défaillance d’une zone de disponibilité dans votre environnement, vous pouvez initier un changement de zone pour votre environnement de cluster Amazon EKS. Vous pouvez également autoriser la gestion du trafic changeant AWS à votre place grâce à l'autoshift zonal. Grâce à l'autoshift zonal, il AWS surveille l'état général de la zone Z et répond à une éventuelle détérioration de la zone Z en transférant automatiquement le trafic vers l'autre zone affectée dans votre environnement de cluster.

Une fois que le décalage de zone est activé avec ARC sur votre cluster Amazon EKS, vous pouvez démarrer un changement de zone ou activer le décalage automatique de zone à l'aide de la console ARC, de la AWS CLI ou du décalage zonal et du décalage automatique de zone. APIs Lors d’un changement de zone EKS, les opérations suivantes sont effectuées automatiquement :

Les diagrammes suivants fournissent une vue d’ensemble de la manière dont le changement de zone EKS garantit que seuls les points de terminaison de pods sains sont ciblés dans votre environnement de cluster.

Exigences relatives au changement de zone EKS

Pour que le changement de zone fonctionne correctement avec EKS, vous devez configurer votre environnement de cluster à l’avance afin qu’il soit résilient en cas de défaillance d’une zone de disponibilité. Voici une liste d’options de configuration qui contribuent à garantir la résilience.

Provisionnez vos composants master EKS dans plusieurs zones de disponibilité

AWS Les régions disposent de plusieurs sites distincts dotés de centres de données physiques, appelés zones de disponibilité (AZs). AZs sont conçus pour être physiquement isolés les uns des autres afin d'éviter un impact simultané susceptible d'affecter une région entière. Lorsque vous provisionnez un cluster EKS, nous vous recommandons de déployer vos nœuds de travail sur plusieurs nœuds au AZs sein d'une même région. Cela permet de rendre votre environnement de cluster plus résilient face à la détérioration d'une seule AZ et vous permet de maintenir une haute disponibilité pour vos applications qui s'exécutent dans l'autre AZs. Lorsque vous amorcez un changement de zone par rapport à l'AZ concernée, le réseau intégré au cluster de votre environnement EKS se met automatiquement à jour pour n'utiliser que les zones saines AZs, afin de maintenir la haute disponibilité de votre cluster.

Le fait de disposer d’une configuration multi-AZ pour votre environnement EKS améliore la fiabilité globale de votre système. Cependant, les environnements multi-AZ influencent la manière dont les données des applications sont transférées et traitées, ce qui a un impact sur les frais de réseau de votre environnement. Plus précisément, le trafic sortant fréquent entre les zones (trafic réparti entre les zones AZs) peut avoir un impact majeur sur les coûts liés à votre réseau. Vous pouvez appliquer différentes stratégies pour contrôler le volume de trafic inter-zones entre les pods de votre cluster EKS et réduire les coûts associés. Pour plus d’informations sur la manière d’optimiser les coûts réseau lors de l’exécution d’environnements EKS hautement disponibles, consultez ces bonnes pratiques.

Le schéma suivant illustre un environnement EKS à haute disponibilité avec trois environnements sains. AZs

Le schéma suivant montre comment un environnement EKS composé de trois AZs est résilient à une déficience de l'AZ et reste hautement disponible car il en reste deux en bonne santé AZs.

Provisionner une capacité de calcul suffisante pour faire face à la suppression d’une seule zone de disponibilité

Afin d’optimiser l’utilisation des ressources et les coûts de votre infrastructure de calcul dans le plan de données EKS, il est une bonne pratique d’aligner la capacité de calcul sur les exigences de votre charge de travail. Cependant, si tous vos composants master sont à pleine capacité, vous devez ajouter de nouveaux composants master au plan de données EKS avant de pouvoir planifier de nouveaux pods. Lorsque vous exécutez des charges de travail critiques, il est généralement recommandé de disposer d’une capacité redondante en ligne pour faire face à des scénarios tels que des augmentations soudaines de la charge et des problèmes d’état des nœuds. Si vous prévoyez d’utiliser le changement de zone, vous envisagez de supprimer toute la capacité d’une zone de disponibilité en cas de défaillance. Cela signifie que vous devez ajuster votre capacité de calcul redondante de manière à ce qu'elle soit suffisante pour gérer la charge, même en AZs mode hors ligne.

Lorsque vous mettez à l’échelle vos ressources de calcul, le processus d’ajout de nouveaux nœuds au plan de données EKS prend un certain temps. Cela peut avoir des implications sur les performances en temps réel et la disponibilité de vos applications, en particulier en cas de défaillance de zone. Votre environnement EKS doit être capable d’absorber la charge liée à la perte d’une zone de disponibilité sans entraîner de dégradation de l’expérience pour vos utilisateurs finaux ou vos clients. Cela implique de réduire au minimum ou d’éliminer le décalage entre le moment où un nouveau pod est nécessaire et celui où il est effectivement planifié sur un composants master.

En outre, en cas d'altération de la zone, vous devez vous efforcer d'atténuer le risque de vous heurter à une contrainte de capacité de calcul qui empêcherait l'ajout de nouveaux nœuds à votre plan de données EKS en mode sain. AZs

Pour réduire le risque de ces impacts négatifs potentiels, nous vous recommandons de surallouer la capacité de calcul de certains nœuds de travail de chacun des AZs. Ce faisant, le planificateur Kubernetes dispose d'une capacité préexistante pour le placement de nouveaux pods, ce qui est particulièrement important lorsque vous perdez l'un d'entre eux dans votre environnement. AZs

Exécuter et répartir plusieurs réplicas de pod entre les zones de disponibilité

Kubernetes vous permet de mettre à l’échelle vos charges de travail à l’avance en exécutant plusieurs instances (réplicas de pod) d’une même application. L’exécution de plusieurs réplicas de pods pour une application élimine les points de défaillance uniques et augmente les performances globales en réduisant la pression sur les ressources d’un seul réplica. Toutefois, pour bénéficier à la fois d’une haute disponibilité et d’une meilleure tolérance aux pannes pour vos applications, nous vous recommandons d’exécuter plusieurs réplicas de votre application et de répartir les réplicas sur différents domaines de défaillance, également appelés domaines topologiques. Dans ce scénario, les domaines de défaillance sont les zones de disponibilité. En utilisant des contraintes de répartition topologique, vous pouvez configurer vos applications pour qu’elles bénéficient d’une stabilité statique préexistante. Ensuite, en cas de défaillance de l'AZ, votre environnement disposera de suffisamment de répliques en bon état AZs pour gérer immédiatement les pics ou les pics de trafic.

Le schéma suivant illustre un environnement EKS où le east-to-west trafic est fluide lorsque tout le monde est AZs en bonne santé.

Le schéma suivant illustre un environnement EKS caractérisé par un flux de east-to-west trafic dans lequel un seul AZ est défaillant et où vous avez entamé un changement de zone.

L’extrait de code suivant est un exemple de configuration de votre charge de travail avec plusieurs réplicas dans Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 9
  selector:
    matchLabels:
      app:orders
  template:
    metadata:
      labels:
        app: orders
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: orders

Il est essentiel d’exécuter plusieurs réplicas de votre logiciel de serveur DNS (CoreDNS/kube-dns) et d’appliquer des contraintes de répartition topologique similaires, si elles ne sont pas configurées par défaut. Cela permet de garantir qu'en cas de défaillance d'AZ unique, vous disposez de suffisamment de pods DNS sains pour continuer AZs à traiter les demandes de découverte de service pour les autres pods communicants du cluster. Le module complémentaire CoreDNS EKS possède des paramètres par défaut pour les modules CoreDNS qui garantissent que, si AZs plusieurs nœuds sont disponibles, ils sont répartis dans les zones de disponibilité de votre cluster. Si vous le souhaitez, vous pouvez remplacer ces paramètres par défaut par vos propres configurations personnalisées.

Lorsque vous installez CoreDNS avec Helm, vous pouvez mettre à jour le replicaCount dans le fichier values.yaml afin de vous assurer que vous disposez d’un nombre suffisant de réplicas dans chaque zone de disponibilité. En outre, pour vous assurer que ces répliques sont réparties entre les différents AZs environnements de votre cluster, veillez à mettre à jour la topologySpreadConstraints propriété dans le même values.yaml fichier. L’extrait de code suivant illustre comment vous pouvez configurer CoreDNS pour cela.

CoreDNS Helm values.yaml

replicaCount: 6
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

En cas de défaillance d’une zone de disponibilité, vous pouvez absorber la charge accrue sur les pods CoreDNS en utilisant un système autoscaling pour CoreDNS. Le nombre d’instances DNS dont vous aurez besoin dépend du nombre de charges de travail exécutées dans votre cluster. CoreDNS est lié au CPU, ce qui lui permet de s’adapter en fonction du CPU à l’aide du Horizontal Pod Autoscaler (HPA). Voici un exemple que vous pouvez modifier en fonction de vos besoins.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

EKS peut également gérer l’autoscaling du déploiement CoreDNS dans la version du module complémentaire EKS de CoreDNS. Cet autoscaler CoreDNS surveille en continu l’état du cluster, y compris le nombre de nœuds et le nombre de cœurs de processeur. Sur la base de ces informations, le contrôleur ajuste dynamiquement le nombre de réplicas du déploiement CoreDNS dans un cluster EKS.

Pour activer la configuration de l’autoscaling dans le module complémentaire CoreDNS EKS, utilisez le paramètre de configuration suivant :

{
  "autoScaling": {
    "enabled": true
  }
}

Vous pouvez également utiliser le NodeLocal DNS ou l'autoscaler proportionnel au cluster pour dimensionner CoreDNS. Pour plus d’informations, consultez Mise à l’échelle horizontale de CoreDNS.

Colocaliser les pod interdépendants dans la même zone de disponibilité

Généralement, les applications ont des charges de travail distinctes qui doivent communiquer entre elles pour mener à bien un end-to-end processus. Si ces applications distinctes sont réparties entre différentes zones AZs et ne sont pas hébergées dans la même zone, une seule altération de la zone Z peut avoir un impact sur le end-to-end processus. Par exemple, si l'application A possède plusieurs répliques en AZ 1 et AZ 2, mais que l'application B possède toutes ses répliques en AZ 3, la perte de l'AZ 3 affectera les end-to-end processus entre les deux charges de travail, l'application A et l'application B. Si vous combinez les contraintes de dispersion topologique avec l'affinité des pods, vous pouvez améliorer la résilience de votre application en répartissant les pods sur l'ensemble du site. AZs De plus, cela permet de configurer une relation entre certains pods afin de garantir leur colocalisation.

Grâce aux règles d’affinité des pods, vous pouvez définir des relations entre les charges de travail afin d’influencer le comportement du planificateur Kubernetes, de manière à ce qu’il effectue la colocalisation des pods sur le même nœud de travail ou dans la même AZ. Vous pouvez également configurer le niveau de rigueur des contraintes de planification.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: products
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"

    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"

Le diagramme suivant montre plusieurs pods que le planificateur a colocalisés sur le même nœud à l’aide des règles d’affinité des pods.

Vérifier que votre environnement de cluster peut gérer la perte d’une zone de disponibilité

Une fois que vous avez rempli les conditions décrites dans les sections précédentes, l’étape suivante consiste à vérifier que vous disposez d’une capacité de calcul et de charge de travail suffisante pour gérer la perte d’une zone de disponibilité. Pour ce faire, vous pouvez lancer manuellement un changement de zone dans EKS. Vous pouvez également activer le transfert automatique de zone et configurer des essais, qui permettent également de vérifier que vos applications fonctionnent comme prévu avec une zone de disponibilité en moins dans votre environnement de cluster.

Questions fréquentes (FAQ)

Pourquoi utiliser cette fonctionnalité ?

En utilisant le changement de zone ARC ou le transfert automatique de zone dans votre cluster EKS, vous pouvez mieux maintenir la disponibilité des applications Kubernetes en automatisant le processus de récupération rapide consistant à transférer le trafic réseau du cluster hors d’une zone de disponibilité défaillante. Avec ARC, vous pouvez éviter les étapes longues et compliquées qui peuvent entraîner une période de récupération prolongée lors d’événements de défaillance d’une zone de disponibilité.

Comment fonctionne cette fonctionnalité avec les autres AWS services ?

EKS s'intègre à ARC, qui fournit l'interface principale dans laquelle vous pouvez effectuer des opérations de restauration AWS. Afin de garantir que le routage du trafic au sein du cluster soit correctement acheminé hors d’une zone de disponibilité défaillante, EKS modifie la liste des points de terminaison réseau pour les pods s’exécutant dans le plan de données Kubernetes. Si vous utilisez Elastic Load Balancing pour le routage du trafic externe vers le cluster, vous pouvez enregistrer vos équilibreurs de charge auprès d’ARC et lancer un changement de zone sur ceux-ci afin d’empêcher le trafic d’affluer vers la zone de disponibilité dégradée. Zonal Shift fonctionne également avec les groupes Amazon EC2 Auto Scaling créés par des groupes de nœuds gérés par EKS. Afin d’empêcher qu’une zone de disponibilité défaillante ne soit utilisée pour de nouveaux pods Kubernetes ou le lancement de nouveaux nœuds, EKS supprime la zone de disponibilité défaillante des groupes Auto Scaling.

En quoi cette fonctionnalité diffère-t-elle des protections Kubernetes par défaut ?

Cette fonctionnalité fonctionne en tandem avec plusieurs protections intégrées à Kubernetes qui contribuent à la résilience des applications des clients. Vous pouvez configurer des sondes de disponibilité et de vitalité des pods qui déterminent quand un pod doit prendre en charge le trafic. Lorsque ces sondes échouent, Kubernetes supprime ces pods en tant que cibles pour un service, et le trafic n’est plus envoyé au pod. Bien que cela soit utile, il n’est pas simple pour les clients de configurer ces surveillances de l’état de manière à garantir leur échec lorsqu’une AZ est dégradée. La fonctionnalité de changement de zone ARC fournit un filet de sécurité supplémentaire qui vous aide à isoler entièrement une AZ dégradée lorsque les protections natives de Kubernetes ne sont pas suffisantes. Le changement de zone vous offre également un moyen simple de tester la disponibilité opérationnelle et la résilience de votre architecture.

Puis-je AWS commencer un changement de zone en mon nom ?

Oui, si vous voulez utiliser le changement de zone ARC de manière entièrement automatisée, vous pouvez activer le changement automatique de zone ARC. Avec le changement automatique de zone, vous pouvez compter sur vous AWS pour surveiller l'état de santé de votre cluster EKS et AZs pour démarrer automatiquement un changement de zone lorsqu'une altération de l'AZ est détectée.

Que se passe-t-il si j’utilise cette fonctionnalité et que mes composants master et mes charges de travail ne sont pas mis à l’échelle au préalable ?

Si vous n’avez pas effectué de mise à l’échelle préalable et que vous comptez sur le provisionnement de nœuds ou de pod supplémentaires pendant un changement de zone, vous risquez un retard dans la récupération. Le processus d’ajout de nouveaux nœuds au plan de données Kubernetes prend un certain temps, ce qui peut avoir un impact sur les performances en temps réel et la disponibilité de vos applications, en particulier en cas de défaillance de zone. En outre, en cas d'altération de la zone, vous pouvez rencontrer une contrainte de capacité de calcul potentielle qui pourrait empêcher l'ajout de nouveaux nœuds au nœud sain AZs.

Si vos charges de travail ne sont pas prédimensionnées et réparties sur l'ensemble AZs de votre cluster, une altération zonale peut avoir un impact sur la disponibilité d'une application exécutée uniquement sur les nœuds de travail dans une zone de zone affectée. Afin d’atténuer le risque d’une interruption complète de la disponibilité de votre application, EKS dispose d’un dispositif de sécurité qui permet d’envoyer le trafic vers les points de terminaison des pods dans une zone défaillante si cette charge de travail a tous ses points de terminaison dans la zone de disponibilité défaillante. Cependant, nous vous recommandons vivement de pré-dimensionner et de répartir vos applications sur l'ensemble du AZs site afin de maintenir la disponibilité en cas de problème de zone.

Comment cela fonctionne-t-il si j’exécute une application avec état ?

Si vous exécutez une application avec état, vous devez évaluer sa tolérance aux pannes en fonction de votre cas d’utilisation et de votre architecture. Si vous avez une active/standby architecture ou un modèle, il se peut que l'actif se trouve dans un AZ altéré. Au niveau de l’application, si l’instance de secours n’est pas activée, vous risquez de rencontrer des problèmes avec votre application. Vous pouvez également rencontrer des problèmes lorsque de nouveaux pods Kubernetes sont lancés en bon état AZs, car ils ne pourront pas se connecter aux volumes persistants liés à l'AZ altérée.

Cette fonctionnalité est-elle compatible avec Karpenter ?

La prise en charge de Karpenter n’est actuellement pas disponible avec le changement de zone ARC et le changement automatique de zone dans EKS. Si un AZ est altéré, vous pouvez ajuster la NodePool configuration Karpenter correspondante en supprimant l'AZ défectueux afin que les nouveaux nœuds de travail ne soient lancés que dans l'autre AZs.

Cette fonctionnalité est-elle compatible avec EKS Fargate ?

Cette fonctionnalité n’est pas compatible avec EKS Fargate. Par défaut, lorsqu'EKS Fargate reconnaît un événement sanitaire dans une zone, Pods préfère fonctionner dans l'autre zone. AZs

Le plan de contrôle Kubernetes géré par Amazon EKS sera-t-il affecté ?

Non, par défaut, Amazon EKS exécute et adapte le plan de contrôle Kubernetes sur plusieurs plans afin de garantir une AZs haute disponibilité. Le changement de zone ARC et le déplacement automatique de zone n’agissent que sur le plan de données Kubernetes.

Cette nouvelle fonctionnalité entraîne-t-elle des coûts supplémentaires ?

Vous pouvez utiliser le changement de zone ARC et le changement automatique de zone dans votre cluster EKS sans frais supplémentaires. Cependant, vous continuerez à payer les instances provisionnées et nous vous recommandons vivement de mettre à l’échelle au préalable votre plan de données Kubernetes avant d’utiliser cette fonctionnalité. Il est important de trouver un équilibre entre le coût et la disponibilité des applications.

Ressources supplémentaires