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.
Basculement de pods Kubernetes par déconnexion réseau
Nous commençons par passer en revue les 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 de Kubernetes. EKS étant conforme à Kubernetes en amont, tous les concepts, composants et paramètres de Kubernetes décrits ici s'appliquent aux déploiements d'EKS et de nœuds hybrides EKS.
Certaines améliorations ont été apportées à EKS spécifiquement pour améliorer le comportement de basculement des pods lors des déconnexions réseau. Pour plus d'informations, consultez les GitHub problèmes #131294
Concepts
Nuances et tolérances : Les limites et les tolérances sont utilisées dans Kubernetes pour contrôler la planification des pods sur les nœuds. Les contaminations sont définies par le contrôleur de cycle de vie des nœuds 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 réseau, le node-lifecycle-controller applique le node.kubernetes. io/unreachable altérer avec NoSchedule effet, et avec NoExecute effet si certaines conditions sont remplies. Le node.kubernetes. io/unreachable taint correspond au fait que 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 programmé sur le nœud contaminé à moins qu'il n'ait une tolérance correspondante. Les pods qui fonctionnent déjà sur le nœud ne sont pas expulsés.
-
NoExecute: Les cabines qui ne tolèrent pas l'odeur sont expulsées immédiatement. Les pods qui tolèrent l'altération (sans spécifier TolerationSeconds) restent liés pour toujours. Les pods qui tolèrent l'altération avec une valeur de TolerationSeconds spécifiée restent liés pendant la durée spécifiée. Une fois ce délai écoulé, le contrôleur de cycle de vie du nœud expulse les Pods du nœud.
Location de nœuds : Kubernetes utilise l'API Lease pour communiquer les battements de cœur des nœuds Kubelet au serveur API Kubernetes. Pour chaque nœud, il existe un objet Lease avec un nom correspondant. En interne, chaque pulsation de 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 étant Ready being Unknown. NodeCondition
Éléments
| Composant | Sub-component | Description |
|---|---|---|
|
Plan de contrôle Kubernetes |
serveur kube-api-server |
Le serveur d'API est un composant essentiel du plan de contrôle de Kubernetes qui expose l'API Kubernetes. |
|
Plan de contrôle Kubernetes |
contrôleur de cycle de vie des nœuds |
L'un des contrôleurs exécutés par le kube-controller-manager. Il est chargé de détecter les problèmes de nœuds et d'y répondre. |
|
Plan de contrôle Kubernetes |
planificateur kube |
Un composant du plan de contrôle qui surveille les Pods nouvellement créés sans nœud attribué et sélectionne un nœud sur lequel ils peuvent s'exécuter. |
|
Nœuds Kubernetes |
kubelet |
Un agent qui s'exécute sur chaque nœud du cluster. La kubelet surveille PodSpecs et s'assure que les contenants qui y sont décrits fonctionnent et PodSpecs sont sains. |
Paramètres de configuration
| Composant | Paramètre | Description | Par défaut de K8s | EKS par défaut | Configurable dans EKS |
|---|---|---|---|---|---|
|
serveur kube-api-server |
secondes de tolérance inaccessibles par défaut |
Indique |
300 |
300 |
Non |
|
contrôleur de cycle de vie des nœuds |
node-monitor-grace-period |
La durée pendant laquelle un nœud peut ne pas répondre avant d'être marqué comme étant défectueux. Doit être N fois plus élevé que celui de kubelet |
40 |
40 |
Non |
|
contrôleur de cycle de vie des nœuds |
seuil de grande taille de cluster |
Le nombre de nœuds sur lesquels le contrôleur de cycle de vie des nœuds considère le cluster comme étant grand pour la logique d'expulsion. |
50 |
100 000 |
Non |
|
contrôleur de cycle de vie des nœuds |
seuil de zone insalubre |
Le pourcentage de nœuds d'une zone qui doivent être non prêts pour que cette zone soit considérée comme insalubre. |
55 % |
55 % |
Non |
|
kubelet |
fréquence de mise à jour de l'état des nœuds |
Fréquence à laquelle le kubelet publie l'état du nœud sur le plan de contrôle. Doit être compatible avec |
10 |
10 |
Oui |
|
kubelet |
étiquettes de nœuds |
Étiquettes à ajouter lors de l'enregistrement du nœud dans le cluster. L'étiquette |
Aucune |
Aucune |
Oui |
Basculement de pods Kubernetes par déconnexion réseau
Le comportement décrit ici suppose que les pods sont exécutés en tant que déploiements Kubernetes avec les 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 plugins. Il est vivement recommandé de tester le comportement dans votre propre environnement et avec vos propres applications avant de passer en 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 de 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 panne ne les arrête. 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.
Il existe cinq scénarios principaux qui 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 se 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 de Kubernetes. Dans ce scénario, le contrôleur de cycle de vie des nœuds situé sur le plan de contrôle détecte que tous les nœuds du cluster sont inaccessibles et annule toute expulsion de pod.
Les administrateurs du cluster verront tous les nœuds dont l'état est affiché 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 perturbation complète de la zone signifie que tous les nœuds de la zone sont déconnectés du plan de contrôle Kubernetes. Dans ce scénario, le contrôleur de cycle de vie des nœuds situé sur le plan de contrôle détecte que tous les nœuds de la zone sont inaccessibles et annule toute expulsion de pod.
Les administrateurs du cluster verront tous les nœuds dont l'état est affiché 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 lors de la déconnexion et de 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 perturbation 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 la même étiquette. topology.kubernetes.io/zone Si aucune zone n'est définie dans le cluster, une interruption majeure signifie que la majorité des nœuds de l'ensemble du cluster sont déconnectés. Par défaut, la majorité est définie par le contrôleur de cycle de vie des nœudsunhealthy-zone-threshold, qui est défini à 55 % dans Kubernetes et EKS. Comme il 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 plus petits que 100 000 nœuds).
Les administrateurs de cluster verront la majorité des nœuds de la zone avec un statut Not Ready lors de la déconnexion, mais l'état des pods ne changera pas et ils ne seront pas reprogrammés sur d'autres nœuds.
Notez que le comportement ci-dessus ne s'applique qu'aux clusters de plus de trois nœuds. Dans les clusters de trois nœuds ou moins, l'expulsion des modules situés sur des nœuds inaccessibles est programmée et de nouveaux modules 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 des 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 concurrence dans le contrôleur de cycle de vie des nœuds Kubernetes comme cause 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 de 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 longtemps que default-unreachable-toleration-seconds (5 minutes) et node-monitor-grace-period (40 secondes) et que moins de 55 % des nœuds d'une zone sont inaccessibles, de nouveaux modules sont planifiés sur des nœuds sains tandis que les modules situés sur des nœuds inaccessibles sont marqués pour expulsion.
Les administrateurs de cluster verront de nouveaux espaces créés sur des nœuds sains, et les modules sur des nœuds déconnectés s'afficheront sous la formeTerminating. N'oubliez pas que, même si les pods situés sur 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 de Kubernetes.
Scénario 5 : redémarrage du nœud en cas d'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 des pods 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 événement d'insuffisance de mémoire ou 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 pendant la déconnexion si le kubelet a également redémarré. Le kubelet interroge le serveur 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 réseau, il ne peut pas récupérer les informations nécessaires au démarrage des pods.
Dans ce scénario, les outils de dépannage locaux tels que l'crictlinterface de ligne de commande 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 #10213
