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.
# Meilleures pratiques en matière de stabilité grâce à la déconnexion 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 de Kubernetes consiste à utiliser des connexions redondantes et résilientes depuis et vers AWS depuis et vers votre environnement sur site. Consultez le kit de résilience [ AWS Direct Connect ](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) et la 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 hautement disponibles avec ces solutions.
## Applications à haute disponibilité
Lorsque vous concevez 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 nœuds, des zones et des domaines régionaux. L'utilisation de ces mécanismes dépend de l'architecture de votre application, de ses environnements et de ses exigences de disponibilité. Par exemple, les applications sans état peuvent souvent être déployées avec plusieurs répliques et peuvent se déplacer entre des hôtes et des capacités d'infrastructure arbitraires. 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 appliquées pour créer des applications résilientes sur Kubernetes, consultez le [ guide des meilleures pratiques EKS. ](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/)
Kubernetes évalue les informations zonales pour les nœuds déconnectés du plan de contrôle Kubernetes pour déterminer s'il faut déplacer des 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. Il est recommandé d'attribuer une zone à chaque nœud en fonction de son centre de données ou de son emplacement physique dans un déploiement dont les nœuds sont 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 le gestionnaire de contrôleurs cloud AWS. Cependant, aucun gestionnaire de contrôleur cloud n'est utilisé avec les nœuds hybrides. Vous pouvez donc transmettre ces informations via votre configuration kubelet. Un exemple de configuration d'une zone dans la configuration de votre nœud pour les nœuds hybrides est illustré ci-dessous. La configuration est transmise lorsque vous connectez vos nœuds hybrides à votre cluster à l'aide de la CLI des nœuds hybrides (`nodeadm`). Pour plus d'informations sur l'`topology.kubernetes.io/zone`étiquette, consultez la documentation [ 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 des 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 le contrôleur de cycle de vie des nœuds exécuté sur le plan de contrôle EKS, qui signalent qu'un nœud hybride est peut-être en train de subir une déconnexion 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 d'état 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 pour les journaux dans la CloudWatch documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html).
Vous pouvez utiliser les mesures intégrées de Transit Gateway (TGW) et de 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 mesures afin de détecter les scénarios dans lesquels le trafic réseau descend 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 du côté AWS de la connexion via le tunnel VPN à 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 délai moyen de restauration et de déterminer si les problèmes 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 de santé du cluster, vous pouvez utiliser le tableau de bord d'observabilité de la console EKS pour détecter, dépanner et résoudre rapidement les problèmes. Vous pouvez également utiliser Amazon Managed Service pour Prometheus, AWS Distro for Open Telemetry (ADOT) et CloudWatch pour la surveillance des clusters, des applications et de l'infrastructure. Pour plus d'informations sur les options d'observabilité d'EKS, consultez [ Surveiller les performances de votre cluster et consulter les journaux](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html).
## Résolution des problèmes locaux
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 secondaires de surveillance et de journalisation 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 des autres API-compatible clients Kubernetes qui interrogent généralement le point de terminaison du serveur API Kubernetes. `kubectl` Pour plus d'informations sur`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 en cours d'exécution sur l'hôte :
```
crictl pods
```
Répertoriez les conteneurs en cours d'exécution 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 en cours d'exécution sur l'hôte :
```
crictl statsp
```
## Trafic réseau d'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 la charge des applications, la session BGP de vos pods et services peut être interrompue lors de déconnexions réseau. Cela est dû au fait que la fonctionnalité du haut-parleur BGP est intégrée à l'agent Cilium et que l'agent Cilium redémarre continuellement 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 : \#31702 ](https://github.com/cilium/cilium/issues/31702) avec une amélioration optionnelle 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 des Region-originated applications AWS, ce trafic peut être temporairement interrompu si votre environnement sur site perd la connectivité à 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 réseau avant de les déployer en production. L'exemple du [ GitHub référentiel ](https://github.com/aws-samples/eks-hybrid-examples) 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 vis-à-vis des 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 ou CloudWatch pour les métriques et les journaux, l'utilisation d'équilibreurs de charge des applications et du réseau pour le Region-originated trafic et l'extraction 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, vérifiez votre utilisation des services AWS et assurez-vous que la perte d'une connexion à ces services ne compromet pas la stabilité statique de vos applications.
## Régler le comportement de basculement des pods Kubernetes
Il existe des options permettant de régler 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é disponible pour le basculement des pods. En règle générale, 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 le caractère inaccessible, qui maintient les DaemonSet pods liés à leurs nœuds par le biais de déconnexions réseau.
+ Option 2 - Régler `tolerationSeconds` les problèmes d'accessibilité : vous pouvez régler la durée pendant laquelle vos pods restent liés aux nœuds pendant les déconnexions du réseau. Pour ce faire, configurez les pods d'application de manière à tolérer l'`NoExecute`effet inaccessible 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, vos pods d'application restent liés aux nœuds jusqu'à `tolerationSeconds` expiration. Réfléchissez bien à cela, car si vous `tolerationSeconds` augmentez la valeur « inaccessible », `NoExecute` cela signifie que les pods exécutés sur des hôtes inaccessibles peuvent mettre plus de temps à se déplacer 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'inaccessibilité associée à l'effet. `NoExecute` Lorsque cette altération est détectée, le contrôleur personnalisé peut vérifier les mesures spécifiques à l'application pour évaluer l'état de santé de l'application. Si l'application est saine, le contrôleur personnalisé peut supprimer le défaut d'accessibilité, empêchant ainsi l'expulsion des pods des nœuds lors des déconnexions du réseau.
Un exemple de configuration d'un déploiement avec `tolerationSeconds` pour le défaut inaccessible est illustré ci-dessous. 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
```