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.
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions contribueront à améliorer notre guide de l'utilisateur pour tous.
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.
Kubernetes possède des fonctionnalités natives qui vous permettent de rendre vos applications plus résilientes face à des événements tels que la détérioration de l'état de santé ou la détérioration d'une zone de disponibilité (AZ). Lorsque vous exécutez vos charges de travail dans un EKS cluster Amazon, vous pouvez améliorer encore la tolérance aux pannes de votre environnement applicatif et la restauration des applications grâce au changement de zone ou à l'autoshift de zone d'Amazon Application Recovery Controller (ARC). ARCle changement de zone est conçu pour être une mesure temporaire qui vous permet de déplacer le trafic vers une ressource hors d'une zone AZ altérée jusqu'à ce que le décalage de zone expire ou que vous l'annuliez. Vous pouvez étendre le décalage de zone si nécessaire.
Vous pouvez démarrer un changement de zone pour un EKS cluster, ou vous pouvez autoriser le changement de zone à le AWS faire 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 sainsAZs. En outre, tout trafic NLB entrant ALB ou gérant le trafic entrant pour les applications de votre EKS cluster acheminera automatiquement le trafic vers les cibles sainesAZs. Pour les clients qui recherchent les objectifs de disponibilité les plus élevés, en cas de défaillance d'une zone de disponibilité, il peut être important de pouvoir orienter tout le trafic vers cette zone jusqu'à ce qu'elle se rétablisse. Pour cela, vous pouvez également activer un ALB ou NLB avec un décalage de ARC zone.
Comprendre le flux de trafic réseau est-ouest entre les modules
Le schéma suivant illustre deux exemples de charges de travail : les commandes et les produits. Le but de cet exemple est de montrer comment les charges de travail et les pods AZs communiquent entre eux dans différents environnements.
-
Pour que les commandes puissent communiquer avec les produits, elles doivent d'abord résoudre le DNS nom du service de destination. Les commandes communiqueront avec Core DNS pour récupérer l'adresse IP virtuelle (IP du cluster) pour ce service. Une fois que Orders a résolu le nom du service Products, il envoie le trafic vers cette adresse IP cible.
-
Le kube-proxy s'exécute sur tous les nœuds du cluster et surveille en permanence EndpointSlices
les services. Lorsqu'un service est créé, un EndpointSlice est créé et géré en arrière-plan par le EndpointSlice contrôleur. Chacun EndpointSlice possède une liste ou un tableau de points de terminaison contenant un sous-ensemble d'adresses Pod ainsi que les nœuds sur lesquels ils s'exécutent. Le kube-proxy définit des règles de routage pour chacun de ces points de terminaison Pod en utilisant iptables
les nœuds. Le kube-proxy est également responsable d'une forme de base d'équilibrage de charge en redirigeant le trafic destiné à l'adresse IP du cluster d'un service pour qu'il soit envoyé directement à l'adresse IP d'un pod. Pour ce faire, le kube-proxy réécrit l'adresse IP de destination sur la connexion sortante. -
Les paquets réseau sont ensuite envoyés au Products Pod dans AZ 2 via ENIs les nœuds respectifs (comme illustré dans le schéma ci-dessus).
Comprendre le changement ARC de zone dans EKS
Dans le cas d'une altération de l'AZ dans votre environnement, vous pouvez initier un changement de zone pour votre environnement de EKS cluster. Vous pouvez également autoriser la gestion AWS de cela pour vous grâce à l'autoshift zonal. Grâce à l'autoshift zonal, il AWS surveillera l'état général de l'AZ et répondra à une éventuelle détérioration de l'AZ en transférant automatiquement le trafic de l'AZ altéré dans votre environnement de cluster.
Une fois que le changement de zone de votre EKS cluster est activé avecARC, vous pouvez déclencher un changement de zone ou activer le décalage automatique de zone à l'aide de la ARC console AWS CLI, ou du décalage de zone et du décalage automatique de zone. APIs Lors d'un changement EKS de zone, les opérations suivantes se produiront automatiquement :
-
Tous les nœuds de l'AZ concernée seront bouclés. Cela empêchera le planificateur Kubernetes de planifier de nouveaux pods sur les nœuds de l'AZ malsaine.
-
Si vous utilisez des groupes de nœuds gérés, le rééquilibrage des zones de disponibilité sera suspendu et votre groupe Auto Scaling (ASG) sera mis à jour pour garantir que les nouveaux nœuds du plan de EKS données ne soient lancés que dans les nœuds sainsAZs.
-
Les nœuds de l'AZ en mauvais état ne seront pas résiliés et les pods ne seront pas expulsés de ces nœuds. Cela permet de garantir qu'en cas d'expiration ou d'annulation d'un changement de zone, votre trafic puisse être renvoyé en toute sécurité vers l'AZ, qui est toujours à pleine capacité
-
Le EndpointSlice contrôleur trouvera tous les points de terminaison du Pod dans la zone AZ altérée et les retirera de la zone correspondante EndpointSlices. Cela garantira que seuls les points de terminaison Pod sains AZs sont ciblés pour recevoir du trafic réseau. Lorsqu'un changement de zone est annulé ou expire, le EndpointSlice contrôleur le met à jour EndpointSlices pour inclure les points de terminaison dans l'AZ restaurée.
Les diagrammes ci-dessous illustrent de manière détaillée comment le changement de EKS zone garantit que seuls les points de terminaison Pod sains sont ciblés dans l'environnement de votre cluster.
EKSExigences relatives au décalage zonal
Pour que le changement de zone fonctionne correctementEKS, vous devez au préalable configurer votre environnement de cluster de manière à ce qu'il soit résilient à une altération de l'AZ. Vous trouverez ci-dessous une liste des étapes à suivre.
-
Provisionnez les nœuds de travail de votre cluster sur plusieurs AZs
-
Fournir une capacité de calcul suffisante pour résister à la suppression d'un seul AZ
-
Prédimensionnez vos pods (y compris CoreDNS) dans chaque AZ
-
Répartissez plusieurs répliques de Pod sur l'ensemble du AZs site pour vous assurer que le fait de vous éloigner d'un seul AZ vous permettra de disposer d'une capacité suffisante
-
Colocalisez des pods interdépendants ou connexes dans la même zone
-
Vérifiez que votre environnement de cluster fonctionnerait comme prévu avec pas moins d'AZ en démarrant manuellement un changement de zone. Vous pouvez également activer le changement automatique par zone et répondre aux essais d'entraînement du changement automatique. Cela n'est pas nécessaire pour que le changement de zone fonctionneEKS, mais c'est fortement recommandé.
Provisionnez EKS vos nœuds de travail sur plusieurs AZs
AWS Les régions disposent de plusieurs sites distincts dotés de centres de données physiques appelés zones de disponibilité (AZs). AZssont 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 EKS cluster, vous devez déployer vos nœuds de travail sur plusieurs nœuds au AZs sein d'une même région. Cela rendra votre environnement de cluster plus résilient face à la détérioration d'une seule AZ et vous permettra de maintenir la haute disponibilité (HA) de vos applications exécutées dans l'autreAZs. Lorsque vous commencez un changement de zone par rapport à l'AZ concernée, le réseau intégré au cluster de votre EKS environnement est automatiquement mis à jour pour n'utiliser que les zones sainesAZs, tout en maintenant une position de haute disponibilité pour votre cluster.
Le fait de disposer d'une telle configuration multi-AZ pour votre EKS environnement améliorera la fiabilité globale de votre système. Cependant, les environnements multi-AZ peuvent jouer un rôle important dans la manière dont les données d'application sont transférées et traitées, ce qui aura un impact sur les frais de réseau de votre environnement. En particulier, le trafic sortant fréquent entre les zones (trafic réparti entre les zonesAZs) 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 entre les zones entre les pods de votre EKS cluster et réduire les coûts associés. Consultez ce guide des meilleures pratiques
Le schéma ci-dessous représente un EKS environnement hautement disponible avec 3 environnements sainsAZs.
Le schéma ci-dessous montre comment un EKS environnement contenant 3 AZs est résilient à une déficience AZ et reste hautement disponible grâce aux 2 autres environnements sainsAZs.
Fournir une capacité de calcul suffisante pour résister à la suppression d'un seul AZ
Pour optimiser l'utilisation des ressources et les coûts de votre infrastructure informatique dans le plan de EKS données, il est recommandé d'aligner la capacité de calcul sur les exigences de votre charge de travail. Toutefois, si tous vos nœuds de travail sont à pleine capacité, vous devez alors compter sur l'ajout de nouveaux nœuds de travail au plan de EKS données avant de pouvoir planifier de nouveaux pods. Lorsque vous exécutez des charges de travail critiques, il est généralement recommandé d'utiliser une capacité redondante en ligne pour faire face à des éventualités telles que des augmentations soudaines de la charge, des problèmes de santé des nœuds, etc. Si vous envisagez d'utiliser le décalage de zone, vous prévoyez de supprimer l'intégralité d'un AZ de capacité. Vous devez donc ajuster votre capacité de calcul redondante afin qu'elle soit suffisante pour supporter la charge même avec un AZ hors ligne.
Lors de la mise à l'échelle de votre calcul, le processus d'ajout de nouveaux nœuds au plan de EKS données prend un certain temps, ce qui peut avoir des répercussions sur les performances et la disponibilité en temps réel de vos applications, en particulier en cas de détérioration zonale. Votre EKS environnement doit être résilient pour absorber le fardeau lié à la perte d'un AZ afin d'éviter une dégradation de l'expérience pour vos utilisateurs finaux ou vos clients. Cela signifie minimiser ou éliminer tout décalage entre le moment où un nouveau Pod est nécessaire et le moment où il est réellement planifié sur un nœud de travail.
En outre, en cas d'altération de la zone, vous devez atténuer le risque d'une éventuelle contrainte de capacité de calcul qui empêcherait l'ajout de nouveaux nœuds à votre plan de EKS données en cours de fonctionnement. AZs
Pour ce faire, vous devez surprovisionner la capacité de calcul de certains nœuds de travail de chacun des AZs afin que le Kubernetes Scheduler dispose d'une capacité préexistante pour les nouveaux emplacements de pods, en particulier lorsque vous avez un AZ de moins dans votre environnement.
Exécutez et répartissez plusieurs répliques de pods sur plusieurs AZs
Kubernetes vous permet de prédimensionner vos charges de travail en exécutant plusieurs instances (répliques Pod) d'une seule application. L'exécution de plusieurs répliques de Pod pour une application élimine un point de défaillance unique et augmente ses performances globales en réduisant la charge de ressources sur une seule réplique. Toutefois, pour garantir à la fois une haute disponibilité et une meilleure tolérance aux pannes pour vos applications, vous devez exécuter et répartir plusieurs répliques d'une application sur différents domaines de défaillance (également appelés domaines de topologie) dans ce cas. AZs Grâce aux contraintes de dispersion topologique
Le schéma ci-dessous décrit un EKS environnement où le east-to-west trafic est fluide lorsque tout le monde est AZs en bonne santé.
Le schéma ci-dessous décrit un EKS environnement caractérisé par un flux de east-to-west trafic lorsqu'une seule AZ tombe en panne et que vous initiez un changement de zone.
L'extrait de code ci-dessous est un exemple de configuration de votre charge de travail avec cette fonctionnalité de 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
Plus important encore, vous devez exécuter plusieurs répliques de votre logiciel DNS serveur (Core DNS /kube-dns) et appliquer des contraintes de propagation topologique similaires si elles ne sont pas déjà configurées par défaut. Cela permettra de garantir que vous disposez de suffisamment de DNS pods sains AZs pour continuer à traiter les demandes de découverte de service pour les autres pods communicants du cluster en cas de défaillance d'AZ unique. Le DNSEKSmodule complémentaire Core possède des paramètres par défaut pour que les Core DNS Pods soient répartis dans les zones de disponibilité de votre cluster si plusieurs nœuds sont AZs disponibles. Vous pouvez également remplacer ces paramètres par défaut par vos propres configurations personnalisées.
Lorsque vous installez Core DNS with HelmreplicaCount
dans chaque AZ. En outre, pour vous assurer que ces répliques sont réparties entre les différents AZs environnements de votre cluster, vous devez mettre à jour la topologySpreadConstraints
propriété dans le même fichier values.yaml. L'extrait de code ci-dessous montre comment configurer Core DNS pour cela.
Core DNS 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 de l'AZ, vous pouvez absorber la charge accrue sur les Core DNS Pods en utilisant un système de mise à l'échelle automatique pour CoreDNS. Le nombre d'DNSinstances dont vous avez besoin dépend du nombre de charges de travail exécutées dans votre cluster. DNSLe noyau est CPU lié, ce qui lui permet de s'adapter CPU en utilisant le Horizontal Pod Autoscaler () HPA
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
Vous EKS pouvez également gérer le dimensionnement automatique du DNS déploiement principal dans la version EKS complémentaire de CoreDNS. Cet DNS autoscaler Core surveille en permanence l'état du cluster, y compris le nombre de nœuds et CPU de cœurs. Sur la base de ces informations, le contrôleur adaptera dynamiquement le nombre de répliques du DNS déploiement Core dans un EKS cluster.
Pour activer la configuration de mise à l'échelle automatique dans le DNS EKS module complémentaire Core, vous devez ajouter les paramètres de configuration facultatifs suivants :
{
"autoScaling": {
"enabled": true
}
}
Vous pouvez également utiliser l'NodeLocal DNS
Colocalisez des pods interdépendants dans la même zone
Dans la plupart des cas, il se peut que vous exécutiez des charges de travail distinctes qui doivent communiquer entre elles pour mener à bien un end-to-end processus. Si les différentes applications sont réparties entre différentes zones AZs mais 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 processus sous-jacent end-to-end. Par exemple, si l'application A possède plusieurs répliques dans AZ 1 et AZ 2, mais que l'application B possède toutes ses répliques dans AZ 3, la perte de l'AZ 3 affectera tous les end-to-end processus entre ces deux charges de travail (application A et B). La combinaison des contraintes de dispersion topologique avec l'affinité des pods peut améliorer la résilience de votre application en répartissant les pods sur l'ensembleAZs, ainsi qu'en configurant une relation entre certains pods pour garantir qu'ils sont colocalisés ensemble.
À l'aide des règles d'affinité des pods
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 schéma ci-dessous décrit les pods qui ont été co-localisés sur le même nœud en utilisant des règles d'affinité des pods.
Vérifiez que votre environnement de cluster peut gérer la perte d'un AZ
Après avoir satisfait aux exigences ci-dessus, la prochaine étape importante consiste à vérifier que vous disposez d'une capacité de calcul et de charge de travail suffisante pour faire face à la perte d'un AZ. Vous pouvez le faire en déclenchant manuellement un décalage de zone. EKS Vous pouvez également activer l'autoshift zonal et configurer des essais pratiques pour vérifier que vos applications fonctionnent comme prévu avec un AZ de moins dans votre environnement de cluster.
Questions fréquentes (FAQ)
Pourquoi utiliser cette fonctionnalité ?
En utilisant le décalage de ARC zone ou le décalage automatique de zone dans votre EKS cluster, vous pouvez mieux maintenir la disponibilité des applications Kubernetes en automatisant le processus de restauration rapide qui consiste à déplacer le trafic réseau interne au cluster vers une zone de zone endommagée. Vous pouvez ainsi éviter des étapes longues et compliquées qui entraînent souvent une période de récupération prolongée en cas d'altération de l'AZ. ARC
Comment fonctionne cette fonctionnalité avec les autres AWS services ?
EKSs'intègre à ARC ce qui fournit l'interface principale dans laquelle vous pouvez effectuer des opérations de restauration AWS. Pour garantir que le trafic interne au cluster est correctement acheminé hors d'une zone de disponibilité altérée, des modifications sont apportées à la liste des points de terminaison réseau pour les pods exécutés dans le plan de données Kubernetes. Si vous utilisez des équilibreurs de AWS charge pour acheminer le trafic externe vers le cluster, vous pouvez déjà enregistrer vos équilibreurs de charge auprès de ceux-ci ARC et déclencher un changement de zone pour empêcher le trafic de pénétrer dans la zone dégradée. Cette fonctionnalité interagit également avec Amazon EC2 Auto Scaling Groups (ASG) créés par EKS Managed Node Groups (MNG). Pour empêcher qu'un AZ altéré ne soit utilisé pour de nouveaux pods Kubernetes ou le lancement de nœuds, EKS supprimez l'AZ altéré du. ASG
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 natives de Kubernetes qui aident les clients à rester résilients. Vous pouvez configurer des sondes de disponibilité et de réactivité du pod qui déterminent à quel moment un pod doit recevoir du trafic. Lorsque ces sondes échouent, Kubernetes supprime ces pods en tant que cibles pour un service et le trafic n'est plus envoyé vers le pod. Bien que cela soit utile, il n'est pas trivial pour les clients de configurer ces contrôles de santé de manière à garantir leur échec en cas de dégradation d'une zone. La fonction de changement de ARC zone vous fournit un filet de sécurité supplémentaire qui les aide à isoler complètement une zone de zone dégradée lorsque les protections natives de Kubernetes ne sont pas suffisantes. Il vous permet également de tester facilement l'état de préparation opérationnelle et la résilience de votre architecture.
Puis-je AWS déclencher un changement de zone en mon nom ?
Oui, si vous souhaitez utiliser le changement de ARC zone de manière entièrement automatisée, vous pouvez activer le changement automatique de ARC zone. Avec l'autoshift zonal, vous pouvez compter sur vous AWS pour surveiller l'état de santé de votre EKS cluster et AZs pour déclencher automatiquement un changement de vitesse lorsqu'une altération de l'AZ est détectée.
Que se passe-t-il si j'utilise cette fonctionnalité et que mes nœuds de travail et mes charges de travail ne sont pas prédimensionnés ?
Si vous n'êtes pas prédimensionné et que vous comptez sur le provisionnement de nœuds ou de pods supplémentaires lors d'un changement de zone, vous risquez de connaître un retard de restauration. Le processus d'ajout de nouveaux nœuds au plan de données Kubernetes prendra un certain temps, ce qui peut avoir des répercussions sur les performances et la disponibilité en temps réel de vos applications, en particulier en cas de détérioration zonale. En outre, en cas d'altération de la zone, vous pouvez rencontrer une contrainte de capacité de calcul potentielle qui empêcherait l'ajout de nouveaux nœuds au nœud sainAZs.
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 qui s'exécute uniquement sur les nœuds de travail dans une zone de zone affectée. Pour atténuer le risque d'une interruption complète de la disponibilité de votre application, disposez d'une sécurité EKS intégrée pour que le trafic soit envoyé vers les points de terminaison du Pod situés dans une zone affectée si tous les points de terminaison de cette charge de travail se trouvent dans une zone de non-conformité. Cependant, il est vivement recommandé de pré-dimensionner et de répartir vos applications sur l'ensemble du site AZs afin de maintenir la disponibilité en cas de problème de zone.
Que se passe-t-il si j'exécute une application dynamique ?
Si vous exécutez une application dynamique, vous devez évaluer sa tolérance aux pannes en fonction du cas d'utilisation et de l'architecture. Si vous avez une architecture ou un modèle actif/en veille, il se peut que l'actif se trouve dans une zone de disponibilité altérée. Au niveau de l'application, si le mode veille n'est pas activé, 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é fonctionne-t-elle avec Karpenter ?
Le support Karpenter n'est actuellement pas disponible avec le changement de ARC zone et le décalage automatique de zone intégrés. EKS Si un AZ est altéré, vous pouvez ajuster la NodePool configuration Karpenter appropriée en supprimant l'AZ défectueux afin que les nouveaux nœuds de travail ne soient lancés que dans le nœud sainAZs.
Cette fonctionnalité fonctionne-t-elle avec EKS Fargate ?
Cette fonctionnalité ne fonctionne pas avec EKS Fargate. Par défaut, lorsque EKS Fargate reconnaît un événement sanitaire dans une zone, Pods préfère courir dans l'autre zone. AZs
Le plan de contrôle Kubernetes EKS géré sera-t-il impacté ?
Non, Amazon EKS exécute et adapte par défaut le plan de contrôle Kubernetes AZs à plusieurs pour garantir une haute disponibilité. ARCle décalage de zone et le décalage automatique de zone n'agiront que sur le plan de données Kubernetes.
Y a-t-il des coûts associés à cette nouvelle fonctionnalité ?
Vous pouvez utiliser ARC le changement de zone et le décalage automatique de zone dans votre EKS cluster sans frais supplémentaires. Cependant, vous continuerez à payer pour les instances provisionnées et il est vivement recommandé de prédimensionner votre plan de données Kubernetes avant d'utiliser cette fonctionnalité. Vous devez trouver le juste équilibre entre le coût et la disponibilité des applications.
Ressources supplémentaires
📝 Modifiez cette page sur GitHub