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.
# Nœuds hybrides EKS et déconnexions réseau
L'architecture EKS Hybrid Nodes peut être une nouveauté pour les clients habitués à gérer des clusters Kubernetes locaux entièrement dans leurs propres centres de données ou emplacements périphériques. Avec les nœuds hybrides EKS, le plan de contrôle Kubernetes s'exécute dans une région AWS et seuls les nœuds s'exécutent sur site, ce qui permet d'obtenir une architecture de cluster Kubernetes « étendue » ou « étendue ».
Cela conduit à une question courante : « Que se passe-t-il si mes nœuds sont déconnectés du plan de contrôle Kubernetes ? »
Dans ce guide, nous répondons à cette question en passant en revue les sujets suivants. Il est recommandé de valider la stabilité et la fiabilité de vos applications par le biais de déconnexions réseau, car chaque application peut se comporter différemment en fonction de ses dépendances, de sa configuration et de son environnement. Consultez le eks-hybrid-examples GitHub référentiel aws-samples/ pour connaître la configuration, les procédures et les résultats des tests auxquels vous pouvez vous référer pour tester les déconnexions réseau avec les nœuds hybrides EKS et vos propres applications. Le GitHub dépôt contient également des détails supplémentaires sur les tests utilisés pour valider le comportement expliqué dans ce guide.
+ [Meilleures pratiques en matière de stabilité grâce aux déconnexions du réseau](hybrid-nodes-network-disconnection-best-practices.md)
+ [Comportement de basculement du pod Kubernetes lors de déconnexions réseau](hybrid-nodes-kubernetes-pod-failover.md)
+ [Trafic réseau des applications via des déconnexions réseau](hybrid-nodes-app-network-traffic.md)
+ [Informations d'identification de l'hôte via des déconnexions réseau](hybrid-nodes-host-creds.md)
# Meilleures pratiques en matière de stabilité grâce aux déconnexions du réseau
## Réseau à haute disponibilité
La meilleure approche pour éviter les déconnexions réseau entre les nœuds hybrides et le plan de contrôle Kubernetes consiste à utiliser des connexions redondantes et résilientes entre votre environnement sur site et AWS. Reportez-vous au [kit de résilience AWS Direct Connect et à la](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) [documentation AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) pour plus d'informations sur l'architecture de réseaux hybrides à haute disponibilité avec ces solutions.
## Applications à haute disponibilité
Lorsque vous concevez l'architecture des applications, tenez compte de vos domaines de défaillance et des effets des différents types de pannes. Kubernetes fournit des mécanismes intégrés pour déployer et gérer des répliques d'applications sur des domaines de nœuds, de zones et régionaux. L'utilisation de ces mécanismes dépend de l'architecture de votre application, de vos environnements et de vos exigences de disponibilité. Par exemple, les applications sans état peuvent souvent être déployées avec plusieurs répliques et peuvent être déplacées entre des hôtes et des capacités d'infrastructure arbitraires, et vous pouvez utiliser des sélecteurs de nœuds et des contraintes de répartition topologique pour exécuter des instances de l'application dans différents domaines. [Pour plus de détails sur les techniques au niveau des applications permettant de créer des applications résilientes sur Kubernetes, reportez-vous au guide des meilleures pratiques EKS.](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/)
Kubernetes évalue les informations zonales relatives aux nœuds déconnectés du plan de contrôle Kubernetes pour déterminer s'il convient de déplacer les pods vers d'autres nœuds. Si tous les nœuds d'une zone sont inaccessibles, Kubernetes annule les expulsions de pods pour les nœuds de cette zone. La meilleure pratique consiste à attribuer une zone à chaque nœud en fonction de son centre de données ou de son emplacement physique si vous effectuez un déploiement avec des nœuds exécutés dans plusieurs centres de données ou emplacements physiques. Lorsque vous exécutez EKS avec des nœuds dans le cloud, cette étiquette de zone est automatiquement appliquée par AWS cloud-controller-manager. Cependant, a n' cloud-controller-managerest pas utilisé avec les nœuds hybrides, vous pouvez donc transmettre ces informations via votre configuration kubelet. Vous trouverez ci-dessous un exemple de configuration d'une zone dans la configuration de votre nœud pour les nœuds hybrides. La configuration est transmise lorsque vous connectez vos nœuds hybrides à votre cluster à l'aide de la CLI (`nodeadm`) des nœuds hybrides. Pour plus d'informations sur l'`topology.kubernetes.io/zone`étiquette, consultez la documentation de [Kubernetes](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone). Pour plus d'informations sur la CLI des nœuds hybrides, consultez la référence [nodeadm sur les nœuds hybrides](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html).
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
region: my-region
kubelet:
flags:
- --node-labels=topology.kubernetes.io/zone=dc1
hybrid:
...
```
## Surveillance réseau
Si vous utilisez AWS Direct Connect ou AWS Site-to-Site VPN pour votre connectivité hybride, vous pouvez tirer parti des CloudWatch alarmes, des journaux et des mesures pour observer l'état de votre connexion hybride et diagnostiquer les problèmes. Pour plus d'informations, consultez [Surveillance des ressources AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) et [Surveillance d'une connexion Site-to-Site VPN AWS](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html).
Il est recommandé de créer des alarmes pour les `NodeNotReady` événements signalés par l' node-lifecycle-controllerexécution sur le plan de contrôle EKS, qui signalent qu'un nœud hybride est peut-être en train de se déconnecter du réseau. Vous pouvez créer cette alarme en activant la journalisation du plan de contrôle EKS pour le Controller Manager et en créant un filtre métrique CloudWatch pour le message « Enregistrement du message d'événement de changement de statut pour le nœud » avec le status = « NodeNotReady ». Après avoir créé un filtre métrique, vous pouvez créer une alarme pour ce filtre en fonction des seuils souhaités. Pour plus d'informations, consultez la section [Alarme relative aux journaux dans la CloudWatch documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html).
Vous pouvez utiliser les métriques intégrées Transit Gateway (TGW) et Virtual Private Gateway (VGW) pour observer le trafic réseau entrant et sortant de votre TGW ou VGW. Vous pouvez créer des alarmes pour ces métriques afin de détecter les scénarios dans lesquels le trafic réseau chute en dessous des niveaux normaux, indiquant un problème réseau potentiel entre les nœuds hybrides et le plan de contrôle EKS. Les métriques TGW et VGW sont décrites dans le tableau suivant.
| Passerelle | Métrique | Description |
| --- | --- | --- |
| Passerelle de transit | BytesIn | Les octets reçus par TGW depuis la pièce jointe (plan de contrôle EKS vers nœuds hybrides) |
| Passerelle de transit | BytesOut | Les octets envoyés par TGW à la pièce jointe (nœuds hybrides vers le plan de contrôle EKS) |
| Passerelle privée virtuelle | TunnelDataIn | Les octets envoyés depuis le côté AWS de la connexion via le tunnel VPN vers la passerelle client (plan de contrôle EKS vers les nœuds hybrides) |
| Passerelle privée virtuelle | TunnelDataOut | Les octets reçus du côté AWS de la connexion via le tunnel VPN depuis la passerelle client (nœuds hybrides vers le plan de contrôle EKS) |
Vous pouvez également utiliser [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) pour mieux comprendre vos connexions hybrides afin de réduire le temps moyen de restauration et de déterminer si les problèmes de réseau proviennent d'AWS ou de votre environnement. CloudWatch Network Monitor peut être utilisé pour visualiser la perte de paquets et la latence dans vos connexions réseau hybrides, définir des alertes et des seuils, puis prendre des mesures pour améliorer les performances de votre réseau. Pour plus d'informations, consultez la section [Utilisation d'Amazon CloudWatch Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html).
EKS propose plusieurs options pour surveiller l'état de santé de vos clusters et applications. Pour l'état du cluster, vous pouvez utiliser le tableau de bord d'observabilité de la console EKS pour détecter, résoudre et résoudre rapidement les problèmes. Vous pouvez également utiliser Amazon Managed Service pour Prometheus, AWS Distro for Open Telemetry (ADOT) et pour la surveillance des clusters CloudWatch , des applications et des infrastructures. Pour plus d'informations sur les options d'observabilité d'EKS, voir [Surveiller les performances de votre cluster et consulter les journaux](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html).
## Dépannage local
Pour vous préparer aux déconnexions réseau entre les nœuds hybrides et le plan de contrôle EKS, vous pouvez configurer des backends de surveillance et de journalisation secondaires afin de maintenir l'observabilité des applications lorsque les services AWS régionaux ne sont pas accessibles. Par exemple, vous pouvez configurer le collecteur AWS Distro for Open Telemetry (ADOT) pour envoyer des métriques et des journaux à plusieurs backends. Vous pouvez également utiliser des outils locaux, tels que la `crictl` CLI, pour interagir localement avec les pods et les conteneurs en remplacement d'autres clients compatibles avec l'API Kubernetes qui interrogent généralement le point de terminaison du serveur d'API Kubernetes. `kubectl` Pour plus d'informations`crictl`, consultez la [`crictl`documentation](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) dans les cri-tools GitHub. Quelques `crictl` commandes utiles sont répertoriées ci-dessous.
Répertoriez les pods exécutés sur l'hôte :
```
crictl pods
```
Répertoriez les conteneurs exécutés sur l'hôte :
```
crictl ps
```
Répertoriez les images exécutées sur l'hôte :
```
crictl images
```
Obtenez les journaux d'un conteneur en cours d'exécution sur l'hôte :
```
crictl logs CONTAINER_NAME
```
Obtenez des statistiques sur les pods exécutés sur l'hôte :
```
crictl statsp
```
## Trafic réseau des applications
Lorsque vous utilisez des nœuds hybrides, il est important de prendre en compte et de comprendre les flux réseau du trafic de vos applications et les technologies que vous utilisez pour exposer vos applications en externe à votre cluster. Les différentes technologies d'équilibrage de charge et d'entrée des applications se comportent différemment lors des déconnexions du réseau. Par exemple, si vous utilisez la fonctionnalité BGP Control Plane de Cilium pour l'équilibrage de charge des applications, la session BGP de vos pods et services peut être interrompue lors des déconnexions du réseau. Cela se produit parce que la fonctionnalité du haut-parleur BGP est intégrée à l'agent Cilium, qui redémarre en permanence lorsqu'il est déconnecté du plan de contrôle Kubernetes. La raison du redémarrage est due à l'échec du bilan de santé de Cilium, car son état de santé est associé à l'accès au plan de contrôle Kubernetes (voir [CFP : \$131702](https://github.com/cilium/cilium/issues/31702) avec une amélioration opt-in dans Cilium v1.17). De même, si vous utilisez des équilibreurs de charge d'application (ALB) ou des équilibreurs de charge réseau (NLB) pour le trafic d'applications provenant de la région AWS, ce trafic peut être temporairement interrompu si votre environnement sur site perd la connectivité avec la région AWS. Il est recommandé de vérifier que les technologies que vous utilisez pour l'équilibrage de charge et l'entrée restent stables pendant les déconnexions du réseau avant de les déployer en production. L'exemple du eks-hybrid-examples GitHub référentiel [aws-samples/](https://github.com/aws-samples/eks-hybrid-examples) utilise MetalLB pour l'équilibrage de charge en [mode L2](https://metallb.universe.tf/concepts/layer2/), qui reste stable lors des déconnexions réseau entre les nœuds hybrides et le plan de contrôle EKS.
## Passez en revue les dépendances sur les services AWS distants
Lorsque vous utilisez des nœuds hybrides, soyez conscient des dépendances que vous assumez vis-à-vis des services AWS régionaux externes à votre environnement sur site ou périphérique. Les exemples incluent l'accès à Amazon S3 ou Amazon RDS pour les données d'application, l'utilisation d'Amazon Managed Service pour Prometheus CloudWatch ou pour les métriques et les journaux, l'utilisation d'équilibreurs de charge d'applications et de réseaux pour le trafic provenant de régions et le retrait de conteneurs depuis Amazon Elastic Container Registry. Ces services ne seront pas accessibles lors des déconnexions réseau entre votre environnement sur site et AWS. Si votre environnement sur site est sujet à des déconnexions réseau avec AWS, passez en revue votre utilisation des services AWS et assurez-vous que la perte de connexion à ces services ne compromet pas la stabilité statique de vos applications.
## Régler le comportement de basculement du pod Kubernetes
Il existe des options permettant d'ajuster le comportement de basculement des pods lors des déconnexions réseau pour les applications qui ne sont pas portables entre les hôtes ou pour les environnements aux ressources limitées qui ne disposent pas de capacité de réserve pour le basculement des pods. En général, il est important de prendre en compte les besoins en ressources de vos applications et de disposer d'une capacité suffisante pour qu'une ou plusieurs instances de l'application puissent basculer vers un autre hôte en cas de défaillance d'un nœud.
+ Option 1 - Utilisation DaemonSets : Cette option s'applique aux applications qui peuvent et doivent s'exécuter sur tous les nœuds du cluster. DaemonSets sont automatiquement configurés pour tolérer les souillures inaccessibles, qui maintiennent les DaemonSet pods liés à leurs nœuds en cas de déconnexion du réseau.
+ Option 2 - Régler `tolerationSeconds` pour éviter les altérations inaccessibles : vous pouvez régler la durée pendant laquelle vos pods restent liés aux nœuds lors des déconnexions du réseau. Pour ce faire, configurez les modules d'application de manière à ce qu'ils tolèrent cette odeur inaccessible avec l'`NoExecute`effet pendant une durée que vous spécifiez (`tolerationSeconds`dans les spécifications de l'application). Avec cette option, en cas de déconnexion du réseau, les pods de votre application restent liés aux nœuds jusqu'à leur `tolerationSeconds` expiration. Réfléchissez bien à cette question, car si vous `tolerationSeconds` augmentez le nombre d'hôtes inaccessibles, `NoExecute` cela signifie que les pods fonctionnant sur des hôtes inaccessibles peuvent mettre plus de temps à être transférés vers d'autres hôtes sains et accessibles.
+ Option 3 : contrôleur personnalisé : vous pouvez créer et exécuter un contrôleur personnalisé (ou un autre logiciel) qui surveille Kubernetes pour détecter toute trace d'effet indésirable. `NoExecute` Lorsque cette altération est détectée, le contrôleur personnalisé peut vérifier les métriques spécifiques à l'application pour évaluer l'état de santé de l'application. Si l'application est saine, le contrôleur personnalisé peut supprimer la souillure inaccessible, empêchant ainsi l'expulsion des pods des nœuds lors des déconnexions du réseau.
Vous trouverez ci-dessous un exemple de configuration d'un déploiement en cas d'inaccessibilité. `tolerationSeconds` Dans l'exemple, `tolerationSeconds` est défini sur `1800` (30 minutes), ce qui signifie que les pods exécutés sur des nœuds inaccessibles ne seront expulsés que si la déconnexion du réseau dure plus de 30 minutes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 1800
```
# Basculement du pod Kubernetes via des déconnexions réseau
Nous commençons par un examen des concepts, composants et paramètres clés qui influencent le comportement de Kubernetes lors des déconnexions réseau entre les nœuds et le plan de contrôle Kubernetes. EKS est conforme à Kubernetes en amont, de sorte que tous les concepts, composants et paramètres Kubernetes décrits ici s'appliquent aux déploiements d'EKS et de nœuds hybrides EKS.
Des améliorations ont été apportées à EKS spécifiquement pour améliorer le comportement de basculement des pods lors de déconnexions réseau. Pour plus d'informations, consultez les GitHub problèmes [\$1131294](https://github.com/kubernetes/kubernetes/pull/131294) et [\$1131481](https://github.com/kubernetes/kubernetes/issues/131481) dans le référentiel Kubernetes en amont.
## Concepts
Contraintes et tolérances : les altérations et les tolérances sont utilisées dans Kubernetes pour contrôler la planification des pods sur les nœuds. Les taches sont définies par le node-lifecycle-controller pour indiquer que les nœuds ne sont pas éligibles à la planification ou que les pods de ces nœuds doivent être expulsés. Lorsque les nœuds sont inaccessibles en raison d'une déconnexion du réseau, le node.kubernetes node-lifecycle-controller s'applique. io/unreachable taint with a NoSchedule effect, and with a NoExecute effect if certain conditions are met. The node.kubernetes.io/unreachabletaint correspond au NodeCondition Ready being Unknown. Les utilisateurs peuvent spécifier des tolérances pour les taches au niveau de l'application dans le. PodSpec
+ NoSchedule: Aucun nouveau pod n'est prévu sur le nœud contaminé à moins qu'il n'ait une tolérance correspondante. Les pods déjà actifs sur le nœud ne sont pas expulsés.
+ NoExecute: Les capsules qui ne tolèrent pas la souillure sont immédiatement expulsées. Les pods qui tolèrent cette odeur (sans spécifier TolerationSeconds) restent liés pour toujours. Les capsules qui tolèrent l'odeur avec une valeur de TolerationSeconds spécifiée restent limitées pendant la durée spécifiée. Une fois ce délai écoulé, le contrôleur du cycle de vie du nœud évacue les pods du nœud.
Locations de nœuds : Kubernetes utilise l'API Lease pour communiquer les pulsations des nœuds Kubelet au serveur d'API Kubernetes. Pour chaque nœud, il existe un objet Lease dont le nom correspond. En interne, chaque battement de cœur du kubelet met à jour le champ spec.RenewTime de l'objet Lease. Le plan de contrôle Kubernetes utilise l'horodatage de ce champ pour déterminer la disponibilité des nœuds. Si les nœuds sont déconnectés du plan de contrôle Kubernetes, ils ne peuvent pas mettre à jour Spec.RenewTime pour leur bail, et le plan de contrôle interprète cela comme le Ready étant Unknown. NodeCondition
## Éléments
![\[Composants Kubernetes impliqués dans le comportement de basculement des pods\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png)
| Composant | Sous-composant | Description |
| --- | --- | --- |
| Plan de contrôle Kubernetes | kube-api-server | Le serveur d'API est un composant essentiel du plan de contrôle Kubernetes qui expose l'API Kubernetes. |
| Plan de contrôle Kubernetes | node-lifecycle-controller | L'un des contrôleurs qu'il fait kube-controller-manager fonctionner. Il est chargé de détecter les problèmes liés aux nœuds et d'y répondre. |
| Plan de contrôle Kubernetes | planificateur Kube | Un composant du plan de contrôle qui surveille les nouveaux pods sans nœud assigné et sélectionne un nœud sur lequel ils pourront s'exécuter. |
| Nœuds Kubernetes | kubelet | Un agent qui s'exécute sur chaque nœud du cluster. Le kubelet surveille PodSpecs et s'assure que les récipients décrits dans ces documents fonctionnent et PodSpecs sont sains. |
## Paramètres de configuration
| Composant | Paramètre | Description | K8s par défaut | EKS par défaut | Configurable dans EKS |
| --- | --- | --- | --- | --- | --- |
| kube-api-server | default-unreachable-toleration-seconds | Indique `tolerationSeconds` la tolérance `unreachable:NoExecute` qui est ajoutée par défaut à chaque pod qui ne dispose pas déjà d'une telle tolérance. | 300 | 300 | Non |
| node-lifecycle-controller | node-monitor-grace-period | Durée pendant laquelle un nœud peut ne pas répondre avant d'être marqué comme étant défectueux. Doit être N fois supérieur à celui de kubelet`nodeStatusUpdateFrequency`, où N est le nombre de tentatives autorisées pour que le kubelet publie le statut du nœud. | 40 | 40 | Non |
| node-lifecycle-controller | large-cluster-size-threshold | Le nombre de nœuds auxquels le cluster est node-lifecycle-controller considéré comme étant important pour la logique d'éviction. `--secondary-node-eviction-rate`est remplacé par 0 pour les clusters de cette taille ou moins. | 50 | 100 000 | Non |
| node-lifecycle-controller | unhealthy-zone-threshold | Pourcentage de nœuds d'une zone qui doivent être « Non prêts » pour que cette zone soit considérée comme non saine. | 55 % | 55 % | Non |
| kubelet | node-status-update-frequency | Fréquence à laquelle le kubelet publie l'état du nœud sur le plan de contrôle. Doit être compatible avec `nodeMonitorGracePeriod` in node-lifecycle-controller. | 10 | 10 | Oui |
| kubelet | étiquettes de nœuds | Étiquettes à ajouter lors de l'enregistrement du nœud dans le cluster. L'étiquette `topology.kubernetes.io/zone` peut être spécifiée avec des nœuds hybrides pour regrouper les nœuds en zones. | Aucune | Aucune | Oui |
## Basculement du pod Kubernetes via des déconnexions réseau
Le comportement décrit ici suppose que les pods s'exécutent en tant que déploiements Kubernetes avec des paramètres par défaut, et qu'EKS est utilisé comme fournisseur Kubernetes. Le comportement réel peut varier en fonction de votre environnement, du type de déconnexion réseau, des applications, des dépendances et de la configuration du cluster. Le contenu de ce guide a été validé à l'aide d'une application spécifique, d'une configuration de cluster et d'un sous-ensemble de plug-ins. Il est vivement recommandé de tester le comportement dans votre propre environnement et avec vos propres applications avant de passer à la production.
En cas de déconnexion réseau entre les nœuds et le plan de contrôle Kubernetes, le kubelet de chaque nœud déconnecté ne peut pas communiquer avec le plan de contrôle Kubernetes. Par conséquent, le kubelet ne peut pas expulser les pods sur ces nœuds tant que la connexion n'est pas rétablie. Cela signifie que les pods exécutés sur ces nœuds avant la déconnexion du réseau continuent de fonctionner pendant la déconnexion, en supposant qu'aucune autre défaillance ne provoque leur arrêt. En résumé, vous pouvez obtenir une stabilité statique lors des déconnexions réseau entre les nœuds et le plan de contrôle Kubernetes, mais vous ne pouvez pas effectuer d'opérations de mutation sur vos nœuds ou vos charges de travail tant que la connexion n'est pas rétablie.
Cinq scénarios principaux produisent différents comportements de basculement des pods en fonction de la nature de la déconnexion du réseau. Dans tous les scénarios, le cluster redevient sain sans intervention de l'opérateur une fois que les nœuds sont reconnectés au plan de contrôle Kubernetes. Les scénarios ci-dessous décrivent les résultats attendus sur la base de nos observations, mais ces résultats peuvent ne pas s'appliquer à toutes les configurations d'applications et de clusters possibles.
### Scénario 1 : interruption complète du cluster
**Résultat attendu** : les pods situés sur des nœuds inaccessibles ne sont pas expulsés et continuent de fonctionner sur ces nœuds.
Une interruption complète du cluster signifie que tous les nœuds du cluster sont déconnectés du plan de contrôle Kubernetes. Dans ce scénario, node-lifecycle-controller le plan de contrôle détecte que tous les nœuds du cluster sont inaccessibles et annule toute expulsion de pods.
Les administrateurs du cluster verront l'état de tous les nœuds `Not Ready` lors de la déconnexion. L'état du pod ne change pas et aucun nouveau pod n'est programmé sur aucun nœud pendant la déconnexion et la reconnexion ultérieure.
### Scénario 2 : perturbation complète de la zone
**Résultat attendu** : les pods situés sur des nœuds inaccessibles ne sont pas expulsés et continuent de fonctionner sur ces nœuds.
Une interruption de zone complète signifie que tous les nœuds de la zone sont déconnectés du plan de contrôle Kubernetes. Dans ce scénario, node-lifecycle-controller le plan de contrôle détecte que tous les nœuds de la zone sont inaccessibles et annule toute expulsion de pods.
Les administrateurs du cluster verront l'état de tous les nœuds `Not Ready` lors de la déconnexion. L'état du pod ne change pas et aucun nouveau pod n'est programmé sur aucun nœud pendant la déconnexion et la reconnexion ultérieure.
### Scénario 3 : perturbation de la zone majoritaire
**Résultat attendu** : les pods situés sur des nœuds inaccessibles ne sont pas expulsés et continuent de fonctionner sur ces nœuds.
Une interruption de zone majoritaire signifie que la plupart des nœuds d'une zone donnée sont déconnectés du plan de contrôle Kubernetes. Les zones de Kubernetes sont définies par des nœuds portant le même label. `topology.kubernetes.io/zone` Si aucune zone n'est définie dans le cluster, une perturbation majeure signifie que la majorité des nœuds de l'ensemble du cluster sont déconnectés. Par défaut, une majorité est définie par le node-lifecycle-controller « s »`unhealthy-zone-threshold`, qui est défini à 55 % dans Kubernetes et EKS. Étant donné que ce paramètre `large-cluster-size-threshold` est défini sur 100 000 dans EKS, si 55 % ou plus des nœuds d'une zone sont inaccessibles, les expulsions de pods sont annulées (étant donné que la plupart des clusters sont bien inférieurs à 100 000 nœuds).
Les administrateurs du cluster verront la majorité des nœuds de la zone avoir un statut `Not Ready` lors de la déconnexion, mais le statut des pods ne changera pas et ils ne seront pas reprogrammés sur les autres nœuds.
Notez que le comportement ci-dessus s'applique uniquement aux clusters de plus de trois nœuds. Dans les clusters de trois nœuds ou moins, les pods situés sur des nœuds inaccessibles sont planifiés pour être expulsés, et les nouveaux pods sont planifiés sur des nœuds sains.
Au cours des tests, nous avons parfois observé que des pods étaient expulsés d'un seul nœud inaccessible lors de déconnexions du réseau, même lorsque la majorité des nœuds de la zone étaient inaccessibles. Nous étudions toujours une éventuelle condition de race dans Kubernetes node-lifecycle-controller à l'origine de ce comportement.
### Scénario 4 : Perturbation de la zone minoritaire
**Résultat attendu** : les pods sont expulsés des nœuds inaccessibles, et de nouveaux pods sont programmés sur les nœuds éligibles disponibles.
Une interruption minoritaire signifie qu'un faible pourcentage de nœuds d'une zone sont déconnectés du plan de contrôle Kubernetes. Si aucune zone n'est définie dans le cluster, une interruption minoritaire signifie que la minorité de nœuds de l'ensemble du cluster est déconnectée. Comme indiqué, la minorité est définie par le `unhealthy-zone-threshold` paramètre de node-lifecycle-controller, qui est de 55 % par défaut. Dans ce scénario, si la déconnexion du réseau dure plus de 5 minutes et 40 secondes et `node-monitor-grace-period` que moins de 55 % des nœuds d'une zone sont inaccessibles, de nouveaux pods sont programmés sur des nœuds sains tandis que les pods situés sur des nœuds inaccessibles sont marqués pour expulsion. `default-unreachable-toleration-seconds`
Les administrateurs de clusters verront de nouveaux pods créés sur des nœuds sains, et les pods sur des nœuds déconnectés seront affichés sous la forme`Terminating`. N'oubliez pas que, même si les pods des nœuds déconnectés ont un `Terminating` statut, ils ne sont pas complètement expulsés tant que le nœud ne se reconnecte pas au plan de contrôle Kubernetes.
## Scénario 5 : redémarrage du nœud lors d'une interruption du réseau
**Résultat attendu** : les pods situés sur des nœuds inaccessibles ne sont pas démarrés tant que les nœuds ne sont pas reconnectés au plan de contrôle Kubernetes. Le basculement du pod suit la logique décrite dans les scénarios 1 à 3, en fonction du nombre de nœuds inaccessibles.
Un redémarrage d'un nœud lors d'une interruption du réseau signifie qu'une autre panne (telle qu'un cycle d'alimentation, un out-of-memory événement ou un autre problème) s'est produite sur un nœud en même temps qu'une déconnexion du réseau. Les pods qui s'exécutaient sur ce nœud lorsque la déconnexion du réseau a commencé ne sont pas automatiquement redémarrés lors de la déconnexion si le kubelet a également redémarré. Le kubelet interroge le serveur d'API Kubernetes au démarrage pour savoir quels pods il doit exécuter. Si le kubelet ne peut pas atteindre le serveur API en raison d'une déconnexion du réseau, il ne peut pas récupérer les informations nécessaires pour démarrer les pods.
Dans ce scénario, les outils de dépannage locaux tels que la `crictl` CLI ne peuvent pas être utilisés pour démarrer les pods manuellement afin de « briser la vitre ». Kubernetes supprime généralement les pods défaillants et en crée de nouveaux plutôt que de redémarrer les pods existants (voir \$110213 [dans](https://github.com/containerd/containerd/pull/10213) le dépôt GitHub containerd pour plus de détails). Les pods statiques sont le seul objet de charge de travail Kubernetes contrôlé par le kubelet et peuvent être redémarrés dans ces scénarios. Cependant, il n'est généralement pas recommandé d'utiliser des pods statiques pour les déploiements d'applications. Déployez plutôt plusieurs répliques sur différents hôtes pour garantir la disponibilité des applications en cas de défaillances simultanées multiples, telles qu'une panne de nœud ou une déconnexion du réseau entre vos nœuds et le plan de contrôle Kubernetes.
# Trafic réseau des applications via des déconnexions réseau
Les rubriques de cette page sont liées à la mise en réseau des clusters Kubernetes et au trafic des applications lors des déconnexions réseau entre les nœuds et le plan de contrôle Kubernetes.
## Cilium
Cilium dispose de plusieurs modes de gestion des adresses IP (IPAM), d'encapsulation, d'équilibrage de charge et de routage de clusters. Les modes validés dans ce guide utilisaient Cluster Scope IPAM, la superposition VXLAN, l'équilibrage de charge BGP et le kube-proxy. Le cilium a également été utilisé sans équilibrage de charge BGP, en le remplaçant par un équilibrage de charge MetalLB L2.
La base de l'installation Cilium se compose de l'opérateur Cilium et des agents Cilium. [L'opérateur Cilium s'exécute en tant que déploiement et enregistre les définitions de ressources personnalisées Cilium (CRDs), gère l'IPAM et synchronise les objets du cluster avec le serveur API Kubernetes, entre autres fonctionnalités.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Les agents Cilium s'exécutent sur chaque nœud en tant que DaemonSet et gèrent les programmes eBPF afin de contrôler les règles réseau applicables aux charges de travail exécutées sur le cluster.
En général, le routage intégré au cluster configuré par Cilium reste disponible et en place pendant les déconnexions du réseau, ce qui peut être confirmé en observant les flux de trafic internes au cluster et les règles de table IP (iptables) pour le réseau du pod.
```
ip route show table all | grep cilium
```
```
10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16
10.86.3.16 dev cilium_host proto kernel scope link
...
```
Cependant, lors des déconnexions du réseau, l'opérateur Cilium et les agents Cilium redémarrent en raison du couplage de leurs bilans de santé avec l'état de la connexion avec le serveur API Kubernetes. On s'attend à voir ce qui suit dans les journaux de l'opérateur Cilium et des agents Cilium lors des déconnexions du réseau. Pendant les déconnexions du réseau, vous pouvez utiliser des outils tels que la `crictl` CLI pour observer les redémarrages de ces composants, y compris leurs journaux.
```
msg="Started gops server" address="127.0.0.1:9890" subsys=gops
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client
msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s
msg=Stopping
msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops
msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon
```
Si vous utilisez la fonctionnalité du plan de contrôle BGP de Cilium pour l'équilibrage de charge des applications, la session BGP pour vos pods et services peut être interrompue lors des déconnexions réseau car la fonctionnalité des haut-parleurs BGP est intégrée à l'agent Cilium, et l'agent Cilium redémarre en permanence lorsqu'il est déconnecté du plan de contrôle Kubernetes. Pour plus d'informations, consultez le guide d'utilisation du plan de contrôle Cilium BGP dans la documentation de Cilium. En outre, si vous rencontrez une panne simultanée lors d'une déconnexion du réseau, telle qu'un cycle d'alimentation ou un redémarrage de machine, les routes Cilium ne seront pas préservées grâce à ces actions, bien qu'elles soient recréées lorsque le nœud se reconnecte au plan de contrôle Kubernetes et que Cilium redémarre.
## Calico
*Prochainement*
## Métal B
[MetalLB dispose de deux modes d'équilibrage de charge : le mode [L2 et le mode](https://metallb.universe.tf/concepts/layer2/) BGP.](https://metallb.universe.tf/concepts/bgp/) Consultez la documentation de MetalLB pour plus de détails sur le fonctionnement de ces modes d'équilibrage de charge et leurs limites. La validation de ce guide a utilisé MetalLB en mode L2, où une machine du cluster prend possession du service Kubernetes et utilise ARP pour rendre les adresses IP de l'équilibreur IPv4 de charge accessibles sur le réseau local. Lors de l'exécution de MetalLB, un contrôleur est responsable de l'attribution des adresses IP et des haut-parleurs exécutés sur chaque nœud sont responsables des services publicitaires auxquels les adresses IP sont attribuées. Le contrôleur MetalLB fonctionne en tant que déploiement et les haut-parleurs MetalLB fonctionnent en tant que. DaemonSet Lors des déconnexions réseau, le contrôleur MetalLB et les haut-parleurs ne surveillent pas les ressources du cluster sur le serveur d'API Kubernetes, mais continuent de fonctionner. Plus important encore, les Services qui utilisent MetalLB pour la connectivité externe restent disponibles et accessibles pendant les déconnexions du réseau.
## kube-proxy
Dans les clusters EKS, kube-proxy s'exécute en tant que serveur DaemonSet sur chaque nœud et est chargé de gérer les règles du réseau afin de permettre la communication entre les services et les pods en traduisant les adresses IP des services en adresses IP des pods sous-jacents. Les règles des tables IP (iptables) configurées par kube-proxy sont maintenues pendant les déconnexions du réseau, le routage au sein du cluster continue de fonctionner et les pods kube-proxy continuent de fonctionner.
Vous pouvez observer les règles de kube-proxy avec les commandes iptables suivantes. La première commande montre que les paquets passant par la `PREROUTING` chaîne sont dirigés vers la `KUBE-SERVICES` chaîne.
```
iptables -t nat -L PREROUTING
```
```
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
```
En inspectant la `KUBE-SERVICES` chaîne, nous pouvons voir les règles des différents services du cluster.
```
Chain KUBE-SERVICES (2 references)
target prot opt source destination
KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP /
KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP /
KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP /
KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP /
KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP /
KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP /
KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP /
KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP /
KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP /
KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP /
KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP /
KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */
```
En inspectant la chaîne du service frontal de l'application, nous pouvons voir les adresses IP des pods qui soutiennent le service.
```
iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q
```
```
Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references)
target prot opt source destination
KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349
KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000
KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */
```
Les messages du journal kube-proxy suivants sont attendus lors des déconnexions du réseau lorsqu'il tente de surveiller le serveur d'API Kubernetes pour détecter les mises à jour des ressources des nœuds et des points de terminaison.
```
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError"
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError"
```
## CoreDNS
Par défaut, les pods des clusters EKS utilisent l'adresse IP du cluster CoreDNS comme serveur de noms pour les requêtes DNS internes au cluster. Dans les clusters EKS, CoreDNS s'exécute en tant que déploiement sur des nœuds. Avec les nœuds hybrides, les pods peuvent continuer à communiquer avec le CoreDNS pendant les déconnexions du réseau lorsque des répliques de CoreDNS s'exécutent localement sur des nœuds hybrides. Si vous avez un cluster EKS avec des nœuds dans le cloud et des nœuds hybrides dans votre environnement sur site, il est recommandé de disposer d'au moins une réplique CoreDNS dans chaque environnement. CoreDNS continue de répondre aux requêtes DNS pour les enregistrements créés avant la déconnexion du réseau et continue à exécuter la reconnexion réseau pour garantir une stabilité statique.
Les messages de journal CoreDNS suivants sont attendus lors des déconnexions du réseau lorsqu'il tente de répertorier des objets depuis le serveur d'API Kubernetes.
```
Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout
Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout
Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout
```
# Informations d'identification de l'hôte via des déconnexions réseau
EKS Hybrid Nodes est intégré aux activations hybrides d'AWS Systems Manager (SSM) et à AWS IAM Roles Anywhere pour les informations d'identification IAM temporaires utilisées pour authentifier le nœud auprès du plan de contrôle EKS. SSM et IAM Roles Anywhere actualisent automatiquement les informations d'identification temporaires qu'ils gèrent sur les hôtes locaux. Il est recommandé d'utiliser un seul fournisseur d'informations d'identification pour tous les nœuds hybrides de votre cluster, qu'il s'agisse d'activations hybrides SSM ou d'IAM Roles Anywhere, mais pas les deux.
## Activations hybrides SSM
Les informations d'identification temporaires fournies par SSM sont valides pendant une heure. Vous ne pouvez pas modifier la durée de validité des informations d'identification lorsque vous utilisez SSM comme fournisseur d'informations d'identification. Les informations d'identification temporaires sont automatiquement modifiées par SSM avant leur expiration, et cette rotation n'affecte pas le statut de vos nœuds ou applications. Toutefois, en cas de déconnexion réseau entre l'agent SSM et le point de terminaison régional SSM, SSM n'est pas en mesure d'actualiser les informations d'identification et celles-ci peuvent expirer.
SSM utilise un retard exponentiel pour les nouvelles tentatives d'actualisation des informations d'identification s'il n'est pas en mesure de se connecter aux points de terminaison régionaux SSM. Dans les versions de l'agent SSM `3.3.808.0` et ultérieures (publiées en août 2024), le retard exponentiel est plafonné à 30 minutes. Selon la durée de la déconnexion de votre réseau, l'actualisation des informations d'identification par SSM peut prendre jusqu'à 30 minutes, et les nœuds hybrides ne se reconnecteront pas au plan de contrôle EKS tant que les informations d'identification ne seront pas actualisées. Dans ce scénario, vous pouvez redémarrer l'agent SSM pour forcer l'actualisation des informations d'identification. Comme effet secondaire du comportement actuel d'actualisation des informations d'identification SSM, les nœuds peuvent se reconnecter à des moments différents selon le moment où l'agent SSM de chaque nœud parvient à actualiser ses informations d'identification. De ce fait, vous pouvez assister à un basculement du pod depuis des nœuds qui ne sont pas encore reconnectés vers des nœuds déjà reconnectés.
Obtenez la version de l'agent SSM. Vous pouvez également consulter la section Fleet Manager de la console SSM :
```
# AL2023, RHEL
yum info amazon-ssm-agent
# Ubuntu
snap list amazon-ssm-agent
```
Redémarrez l'agent SSM :
```
# AL2023, RHEL
systemctl restart amazon-ssm-agent
# Ubuntu
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
Afficher les journaux des agents SSM :
```
tail -f /var/log/amazon/ssm/amazon-ssm-agent.log
```
Messages de journal attendus lors des déconnexions du réseau :
```
INFO [CredentialRefresher] Credentials ready
INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials
```
## Rôles Anywhere IAM
Les informations d'identification temporaires fournies par IAM Roles Anywhere sont valides pendant une heure par défaut. Vous pouvez configurer la durée de validité des informations d'identification avec IAM Roles Anywhere via le [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object)champ de votre profil IAM Roles Anywhere. La durée maximale de validité des informations d'identification est de 12 heures. Le [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html)paramètre de votre rôle IAM Hybrid Nodes doit être supérieur à celui `durationSeconds` de votre profil IAM Roles Anywhere.
Lorsque vous utilisez IAM Roles Anywhere comme fournisseur d'informations d'identification pour vos nœuds hybrides, la reconnexion au plan de contrôle EKS après une déconnexion du réseau a généralement lieu quelques secondes après la restauration du réseau, car le kubelet appelle `aws_signing_helper credential-process` pour obtenir des informations d'identification à la demande. Bien que cela ne soit pas directement lié aux nœuds hybrides ou aux déconnexions du réseau, vous pouvez configurer des notifications et des alertes relatives à l'expiration des certificats lorsque vous utilisez IAM Roles Anywhere. Pour plus d'informations, voir [Personnaliser les paramètres de notification dans IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html).