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.
Comprenez l'expulsion des capsules lors de perturbations zonales
Lorsqu'une interruption complète de la zone de disponibilité se produit, c'est-à-dire lorsque tous les nœuds de cette zone de disponibilité perdent leur connectivité avec le plan de contrôle Kubernetes, le contrôleur du cycle de vie des nœudsTerminating et de nouveaux pods sont planifiés sur des nœuds sains dans les zones de disponibilité disponibles. Pendant cette période, les nœuds concernés affichent un NotReady état, le planificateur empêche le placement de nouveaux pods sur ces nœuds et le EndpointSlice contrôleur supprime les points de terminaison associés à la zone de disponibilité altérée du routage des services jusqu'à ce que la connectivité soit rétablie.
Pour les scénarios impliquant des défaillances partielles de nœuds au sein d'une zone (où seul un sous-ensemble de nœuds devient inaccessible), le Node Lifecycle Controller applique un comportement d'éviction différent. Si l'interruption persiste au-delà de la période de tolérance configurée (par défaut, cinq minutes), les pods des nœuds déconnectés sont marqués comme tels Terminating et les nouveaux pods sont planifiés sur des nœuds sains dans les zones de disponibilité disponibles.
Mise en œuvre du changement de zone Amazon EKS pour une meilleure résilience
Amazon EKS Zonal Shift, qui s'intègre à Amazon Application Recovery Controller (ARC), fournit un mécanisme permettant de gérer le trafic de manière proactive en cas de défaillance de la zone de disponibilité. Cette fonctionnalité permet de rediriger temporairement le trafic réseau d'une zone de disponibilité défaillante vers des zones saines au sein de celle-ci afin Région AWS de minimiser les interruptions de service.
Comprendre le mécanisme de changement de zone
Amazon EKS Zonal Shift gère le trafic est-ouest (communication entre les pods au sein du cluster). Lorsque le décalage de zone est configuré avec des équilibreurs de charge d'application ou des équilibreurs de charge réseau, il prend également en charge le routage du trafic entrant. Le mécanisme fonctionne en coordonnant plusieurs composants Kubernetes et du plan de AWS contrôle afin de rediriger le trafic en toute sécurité sans perturber les charges de travail en cours d'exécution. Lors d'un changement de zone actif, Amazon EKS exécute automatiquement les actions coordonnées suivantes :
-
Cordonage des nœuds : tous les nœuds de la zone de disponibilité affectée sont bouclés. Cela empêche le planificateur Kubernetes de placer de nouveaux pods sur les nœuds tout en maintenant les charges de travail existantes.
-
Suspension du rééquilibrage des zones de disponibilité : pour les groupes de nœuds gérés, les opérations de rééquilibrage des zones de disponibilité sont suspendues et les groupes Auto Scaling sont mis à jour pour lancer de nouveaux nœuds de plan de données exclusivement dans des zones de disponibilité saines. Cela garantit que la nouvelle capacité n'est pas allouée dans la zone affectée.
-
Suppression des points de terminaison : le EndpointSlice contrôleur supprime les points de terminaison du pod situés dans la zone de disponibilité altérée de tous les points concernés EndpointSlices. Cela garantit que les mécanismes de découverte des services et d'équilibrage de charge acheminent le trafic uniquement vers les pods exécutés dans des zones de disponibilité saines.
-
Préservation de la charge de travail : Amazon EKS s'abstient de résilier des nœuds ou d'expulser des pods dans la zone de disponibilité concernée. Il maintient la pleine capacité dans la zone affectée, de sorte que lorsque le changement de zone expire ou est annulé, le trafic peut revenir en toute sécurité sans nécessiter d'opérations de dimensionnement supplémentaires.
Méthodes d'activation du changement de zone
Vous pouvez choisir entre deux approches pour initier des changements de zone, en fonction de votre modèle opérationnel :
-
Le changement de zone manuel fournit un contrôle piloté par l'opérateur lorsque des problèmes spécifiques à la zone de disponibilité sont détectés par le biais de la surveillance, d'alertes ou de rapports clients. Cette méthode nécessite une action explicite via la console ARC, AWS Command Line Interface (AWS CLI), ou un changement de zone APIs, où les opérateurs spécifient la zone de disponibilité altérée et définissent une date d'expiration pour le changement. Les changements manuels sont appropriés lorsque les équipes disposent de capacités de surveillance et de disponibilité dédiées et préfèrent garder un contrôle direct sur les décisions de gestion du trafic.
-
L'autoshift zonal autorise le AWS lancement automatique des changements de vitesse lorsque l'ARC détecte des défaillances ou des déficiences potentielles de la zone de disponibilité sur la base de la télémétrie interne et de signaux de santé provenant de multiples indicateurs, Services AWS notamment les métriques du réseau, Amazon Elastic Compute Cloud (Amazon) et EC2 Elastic Load Balancing. AWS met automatiquement fin à un changement automatique lorsque les indicateurs indiquent que le problème a été résolu. Si vous recherchez une posture de disponibilité maximale avec un minimum d'intervention manuelle, nous vous recommandons cette approche, car elle permet de réagir en quelques minutes en cas de défaillance détectée dans la zone de disponibilité.
Conditions préalables à un changement de zone efficace
Pour que le changement de zone protège efficacement les applications en cas de détérioration de la zone de disponibilité, vous devez concevoir vos clusters pour une résilience multi-AZ avant d'activer la fonctionnalité de changement de zone :
-
Distribution de nœuds multi-AZ : provisionnez les nœuds de travail sur au moins trois zones de disponibilité afin de garantir une redondance suffisante lorsqu'une zone devient indisponible.
-
Planification des capacités : préprovisionnez une capacité de calcul suffisante dans des zones de disponibilité saines pour prendre en charge l'ensemble de la charge de travail lorsqu'une zone de disponibilité est supprimée du service, car le dimensionnement des opérations pendant une interruption active peut se heurter à une capacité insuffisante.
-
Distribution des modules et pré-dimensionnement : déployez plusieurs répliques de chaque application dans toutes les zones de disponibilité et prédimensionnez les composants critiques du système tels que CoreDNS dans chaque zone. Cela permet de garantir le maintien d'une capacité suffisante après le déplacement d'une zone.
Recommandations pour la résilience aux perturbations zonales
-
Activer le changement de zone lors de la création du cluster : pour les nouveaux clusters EKS, activez l'intégration du changement de zone avec ARC lors du provisionnement initial via la console Amazon EKS ou des outils d'infrastructure en tant que code (IaC) tels que. AWS CLI AWS CloudFormation Le décalage de zone est activé par défaut pour les clusters en mode automatique EKS créés avec une configuration rapide.
-
Sélectionnez la méthode d'activation appropriée : optez pour le changement automatique par zone pour les environnements de production qui nécessitent une disponibilité maximale avec réponse automatique, en particulier pour les applications destinées aux clients où des minutes d'indisponibilité pendant une panne de zone de disponibilité peuvent avoir un impact commercial significatif. Utilisez le changement de zone manuel pour les environnements dans lesquels les équipes opérationnelles préfèrent fournir une approbation explicite avant les changements de trafic, ou dans lesquels les tests et la validation des applications sont toujours en cours.
-
Testez la résilience avant le déploiement en production : validez le comportement du cluster en cas de perte mono-AZ en initiant manuellement les changements de zone de test ou en activant des tests d'autoshift pour vérifier que les applications restent disponibles, que les performances restent acceptables et que la capacité est suffisante lorsque le nombre de zones de disponibilité est réduit. Nous recommandons vivement ce test afin que vous puissiez identifier les lacunes de configuration avant que des défaillances réelles de la zone de disponibilité ne se produisent.
-
Coordonner avec la configuration de l'équilibreur de charge : pour les applications recevant du trafic externe, activez le décalage de zone ARC sur les équilibreurs de charge d'application et les équilibreurs de charge réseau associés afin de garantir que le trafic entrant et le trafic est-ouest du cluster se déplacent simultanément en cas de détérioration de la zone de disponibilité. Cette coordination permet d'éviter les scénarios dans lesquels les demandes externes atteignent des modules sains mais où ces modules ne peuvent pas communiquer avec les dépendances de la zone déplacée.
-
Surveillez les opérations de quart de travail : après avoir activé le changement de zone, configurez la surveillance et les alertes pour les événements liés aux équipes, notamment les activations de changement automatique, les initiations manuelles et les expirations des équipes, afin de maintenir une visibilité opérationnelle sur les actions de gestion du trafic et leur impact sur le comportement des applications.
Fin du quart de travail et reprise
Lorsqu'un décalage de zone expire en fonction de sa durée configurée ou qu'il est annulé manuellement une fois la détérioration de la zone de disponibilité résolue, le EndpointSlice contrôleur met automatiquement à jour tout EndpointSlices pour réintégrer les points de terminaison dans la zone de disponibilité restaurée. Le trafic revient progressivement vers la zone précédemment affectée au fur et à mesure que les clients actualisent les informations relatives aux terminaux et établissent de nouvelles connexions. Cela permet une utilisation complète de la capacité du cluster sans intervention manuelle ni replanification des pods.
