Activation de la réparation automatique des nœuds et examen des problèmes d’état de ces derniers

L’état d’un nœud fait référence à son état opérationnel et à sa capacité à exécuter efficacement des charges de travail. Un nœud en bon état maintient la connectivité attendue, dispose de ressources suffisantes et peut exécuter avec succès des pods sans interruption. Pour plus d’informations sur vos nœuds, consultez Afficher l’état de santé de vos nœuds et Extraction des journaux d’un nœud géré à l’aide de kubectl et S3.

Afin de vous aider à maintenir vos nœuds en bon état de fonctionnement, Amazon EKS propose l’agent de surveillance des nœuds et la réparation automatique des nœuds.

Important

L’agent de surveillance des nœuds et la réparation automatique des nœuds ne sont disponibles que sous Linux. Ces fonctionnalités ne sont pas disponibles sous Windows.

Agent de surveillance des nœuds

L’agent de surveillance des nœuds journalise automatiquement les journaux des nœuds afin de détecter certains problèmes de leur état. Il analyse les journaux des nœuds afin de détecter les défaillances et affiche diverses informations sur l’état des composants master. Une NodeCondition dédiée est appliquée aux composants master pour chaque catégorie de problèmes détectés, tels que les problèmes de stockage et de réseau. Les descriptions des problèmes d’état détectés sont disponibles dans le tableau de bord d’observabilité. Pour de plus amples informations, veuillez consulter Problèmes d’état du nœud.

L’agent de surveillance des nœuds est inclus en tant que fonctionnalité pour tous les clusters du mode automatique Amazon EKS. Pour les autres types de clusters, vous pouvez ajouter l’agent de surveillance en tant que module complémentaire Amazon EKS. Pour de plus amples informations, veuillez consulter Créer un module complémentaire Amazon EKS.

Réparation automatique de nœuds

La réparation automatique des nœuds est une fonctionnalité supplémentaire qui surveille en permanence l’état des nœuds, réagit automatiquement aux problèmes détectés et remplace les nœuds lorsque cela est possible. Cela contribue à la disponibilité globale du cluster avec un minimum d’intervention manuelle. Si une surveillance de l’état échoue, le nœud est automatiquement isolé afin qu’aucun nouveau pod ne soit planifié sur ce nœud.

En soi, la réparation automatique des nœuds peut réagir à la condition Ready de kubelet et à tous les objets de nœuds qui sont supprimés manuellement. Associée à l’agent de surveillance des nœuds, la réparation automatique des nœuds peut réagir à davantage de conditions qui ne seraient pas détectées autrement. Ces conditions supplémentaires incluent KernelReady, NetworkingReady et StorageReady.

Cette restauration automatique des nœuds résout automatiquement les problèmes intermittents liés aux nœuds, notamment les échecs de connexion au cluster, des kubelets qui ne répondent pas et l’augmentation des erreurs de l’accélérateur (appareil). La fiabilité accrue permet de réduire la durée d’indisponibilité des applications et d’améliorer le fonctionnement des clusters. La réparation automatique des nœuds ne peut pas traiter certains problèmes signalés, tels que DiskPressure, MemoryPressure et PIDPressure. Amazon EKS attend 10 min avant d’agir sur les AcceleratedHardwareReady NodeConditions et 30 min pour toutes les autres conditions.

Les groupes de nœuds gérés désactivent également automatiquement les réparations de nœuds pour des raisons de sécurité dans deux cas de figure. Toutes les opérations de réparation déjà en cours se poursuivent dans les deux cas.

• Si un changement de zone pour votre cluster a été déclenché par le contrôleur de récupération d’application (ARC), toutes les opérations de réparation ultérieures sont interrompues.

• Si votre groupe de nœuds comporte plus de cinq nœuds et que plus de 20 % des nœuds de votre groupe de nœuds sont dans un état non sain, les opérations de réparation sont interrompues.

Vous pouvez activer la réparation automatique des nœuds lors de la création ou de la modification d’un groupe de nœuds gérés.

• Lorsque vous utilisez la console Amazon EKS, cochez la case Activer la réparation automatique des nœuds pour le groupe de nœuds gérés. Pour de plus amples informations, veuillez consulter Création d’un groupe de nœuds gérés pour votre cluster.

• Lorsque vous utilisez la AWS CLI, ajoutez la eks update-nodegroup-configcommande --node-repair-config enabled=true to the eks create nodegroupor.

• Pour un exemple d'utilisation eksctl ClusterConfig d'un groupe de nœuds géré avec réparation automatique des nœuds, consultez 44-node-repair.yaml on. GitHub

Amazon EKS offre un contrôle plus granulaire sur le comportement de réparation automatique des nœuds grâce aux éléments suivants :

• maxUnhealthyNodeThresholdCount et maxUnhealthyNodeThresholdPercentage

  • Ces champs vous permettent de spécifier un seuil en nombre ou en pourcentage de nœuds défectueux, au-delà duquel les actions de réparation automatique des nœuds s’arrêtent. Cela permet de mieux contrôler la « portée » des réparations automatiques des nœuds.

  • Vous pouvez définir soit le nombre absolu, soit le pourcentage, mais pas les deux.

• maxParallelNodesRepairedCount et maxParallelNodesRepairedPercentage

  • Ces champs vous permettent de spécifier le nombre maximal de nœuds pouvant être réparés avec simultanéité ou en parallèle, exprimé en nombre ou en pourcentage de tous les nœuds défectueux. Cela vous offre un contrôle plus précis sur le rythme des remplacements de nœuds.

  • Comme pour le seuil de nœuds défectueux, vous pouvez définir soit le nombre absolu, soit le pourcentage, mais pas les deux.

• nodeRepairConfigOverrides

  • Il s’agit d’une structure complexe qui vous permet de définir des remplacements granulaires pour des actions de réparation spécifiques. Ces remplacements contrôlent l’action de réparation et le délai de réparation avant qu’un nœud ne soit considéré comme éligible à la réparation.

  • Les champs spécifiques de cette structure sont les suivants :

    • nodeMonitoringCondition : l’état non sain signalé par l’agent de surveillance des nœuds.

    • nodeUnhealthyReason : la raison pour laquelle l’agent de surveillance des nœuds a identifié le nœud comme non sain.

    • minRepairWaitTimeMins : le temps minimum (en minutes) pendant lequel l’état de réparation et la raison de la défaillance doivent persister avant que le nœud ne soit éligible à la réparation.

    • repairAction : l’action que le système de réparation doit effectuer lorsque les conditions ci-dessus sont remplies.

  • Si vous utilisez ce champ, vous devez spécifier tous les champs de la structure. Vous pouvez également fournir une liste de ces remplacements.

  • Les champs nodeMonitoringCondition et nodeUnhealthyReason sont des entrées de texte manuelles que vous définissez pour indiquer que vous voulez vous écarter du comportement par défaut du système.

  • Les champs minRepairWaitTimeMins et repairAction vous permettent de spécifier des écarts par rapport au comportement par défaut du système.

Problèmes d’état du nœud

Les tableaux suivants décrivent les problèmes d’état des nœuds que l’agent de surveillance des nœuds peut détecter. Il existe deux types de problèmes :

• Condition : problème terminal qui nécessite une action corrective, telle que le remplacement d’une instance ou un redémarrage. Lorsque la réparation automatique est activée, Amazon EKS effectue une action de réparation, soit en remplaçant le nœud, soit en le redémarrant. Pour de plus amples informations, veuillez consulter Conditions des nœuds.

• Événement : problème temporaire ou configuration sous-optimale du nœud. Aucune action de réparation automatique n’est effectuée. Pour de plus amples informations, veuillez consulter Événements des nœuds.

AcceleratedHardware problèmes de santé des nœuds

La condition de surveillance est AcceleratedHardwareReady pour les problèmes du tableau suivant qui ont une sévérité « Condition ».

Si la réparation automatique est activée, les actions de réparation répertoriées commencent 10 min après la détection du problème. Pour plus d’informations sur les erreurs XID, consultez Erreurs XID dans la Documentation sur le déploiement et la gestion des GPU NVIDIA. Pour plus d’informations sur les messages XID individuels, consultez Comprendre les messages XID dans la Documentation sur le déploiement et la gestion des GPU NVIDIA.

Name	Sévérité	Description
DCGMDiagnosticDéfaillance	Condition	Un cas de test de la suite de tests de diagnostic actif DCGM a échoué.
DCGMError	Condition	La connexion au processus hôte DCGM a été perdue ou n'a pas pu être établie.
DCGMFieldErreur [Code]	Événement	Le DCGM a détecté une dégradation du GPU grâce à un identifiant de champ.
DCGMHealthCode [Code]	Événement	Un bilan de santé du DCGM a échoué de manière non fatale.
DCGMHealthCode [Code]	Condition	Un bilan de santé du DCGM a échoué de manière fatale.
Neurone DMAError	Condition	Un moteur DMA a rencontré une erreur irrécupérable.
Erreur neuronale HBMUncorrectable	Condition	Une mémoire HBM a rencontré une erreur incorrigible et a produit des résultats incorrects.
Erreur neuronale NCUncorrectable	Condition	Une erreur mémoire incorrigible du cœur Neuron a été détectée.
Erreur neuronale SRAMUncorrectable	Condition	Une mémoire SRAM sur puce a rencontré une erreur de parité et a produit des résultats incorrects.
NvidiaDeviceCountMismatch	Événement	Le nombre de périphériques GPUs visibles via NVML ne correspond pas au nombre de périphériques NVIDIA présents sur le système de fichiers.
NvidiaDoubleBitError	Condition	Le pilote GPU a généré une erreur double bit.
Nvidia NCCLError	Événement	Une erreur de segmentation s'est produite dans la bibliothèque NVIDIA Collective Communications (libnccl).
NVLinkErreur Nvidia	Condition	NVLink des erreurs ont été signalées par le pilote du GPU.
PCIeErreur Nvidia	Événement	PCIe des rediffusions ont été déclenchées pour remédier à des erreurs de transmission.
NvidiaPageRetirement	Événement	Le pilote GPU a marqué une page mémoire pour mise hors service. Cela peut se produire si une seule erreur double bit ou deux erreurs simple bit sont détectées à la même adresse.
NvidiaPowerError	Événement	La consommation d'énergie GPUs a dépassé les seuils autorisés.
NvidiaThermalError	Événement	L'état thermique GPUs a dépassé les seuils autorisés.
Erreur NvidiaXid [Code]	Condition	Une erreur critique du processeur graphique s'est produite.
NvidiaXID[Code]Warning	Événement	Une erreur GPU non critique s'est produite.

ContainerRuntime problèmes de santé des nœuds

La condition de surveillance est ContainerRuntimeReady pour les problèmes du tableau suivant qui ont une sévérité « Condition ».

Name	Sévérité	Description
ContainerRuntimeFailed	Événement	L’exécution du conteneur n’a pas réussi à créer un conteneur, ce qui est probablement lié à des problèmes signalés s’ils se produisent de manière répétée.
DeprecatedContainerdConfiguration	Événement	Une image de conteneur utilisant le manifeste d'image obsolète version 2, schéma 1, a récemment été transférée sur le nœud via. containerd
KubeletFailed	Événement	Le kubelet est passé à l’état d’échec.
LivenessProbeFailures	Événement	Une défaillance de la sonde de vivacité a été détectée, ce qui peut indiquer des problèmes de code d’application ou des valeurs de délai d’expiration insuffisantes si cela se produit de manière répétée.
PodStuckTerminating	Condition	Un pod est ou était bloqué pendant une durée excessive, ce qui peut être dû à des erreurs CRI empêchant la progression de l’état du pod.
ReadinessProbeFailures	Événement	Une défaillance de la sonde de disponibilité a été détectée, ce qui peut indiquer des problèmes de code d’application ou des valeurs de délai d’expiration insuffisantes si cela se produit de manière répétée.
[Nom] RepeatedRestart	Événement	Une unité systemd redémarre fréquemment.
ServiceFailedToStart	Événement	Une unité systemd n’a pas pu démarrer.

Problèmes d’état du nœud du noyau

La condition de surveillance est KernelReady pour les problèmes du tableau suivant qui ont une sévérité « Condition ».

Name	Sévérité	Description
AppBlocked	Événement	La tâche a été bloquée pendant une longue période à partir de la planification, généralement en raison d’un blocage au niveau de l’entrée ou de la sortie.
AppCrash	Événement	Une application sur le nœud a planté.
ApproachingKernelPidMax	Événement	Le nombre de processus approche le nombre maximum de processus disponibles PIDs selon le kernel.pid_max paramètre actuel, après quoi aucun autre processus ne pourra être lancé.
ApproachingMaxOpenFiles	Événement	Le nombre de fichiers ouverts approche le nombre maximal de fichiers ouverts possibles selon les paramètres actuels du noyau, après quoi l’ouverture de nouveaux fichiers échouera.
ConntrackExceededKernel	Événement	Le suivi des connexions a dépassé le maximum pour le noyau et le système n’a pas pu établir de nouvelles connexions, ce qui peut entraîner une perte de paquets.
ExcessiveZombieProcesses	Événement	Les processus que le système ne peut pas entièrement récupérer s’accumulent en grand nombre, ce qui indique des problèmes d’application et peut conduire à atteindre les limites des processus du système.
ForkFailedOutOfPIDs	Condition	Un appel fork ou exec a échoué en raison d'un manque de processus IDs ou de mémoire du système, ce qui peut être dû à des processus zombies ou à un épuisement physique de la mémoire.
KernelBug	Événement	Un bogue du noyau a été détecté et signalé par le noyau Linux lui-même, bien que cela puisse parfois être causé par des nœuds avec une utilisation élevée du processeur ou de la mémoire, entraînant un retard dans le traitement des événements.
LargeEnvironment	Événement	Le nombre de variables d'environnement associées à ce processus est supérieur aux prévisions, ce qui peut être dû au fait que de nombreux services sont enableServiceLinks définis sur true, ce qui peut entraîner des problèmes de performances.
RapidCron	Événement	Une tâche cron s’exécute plus rapidement que toutes les cinq minutes sur ce nœud, ce qui peut avoir un impact sur les performances si la tâche consomme des ressources importantes.
SoftLockup	Événement	Le CPU s’est bloqué pendant un certain temps.

Problèmes d’état du nœud de réseau

La condition de surveillance est NetworkingReady pour les problèmes du tableau suivant qui ont une sévérité « Condition ».

Name	Sévérité	Description
BandwidthInExceeded	Événement	La file d’attente ou la suppression de paquets s’explique par le dépassement du maximum de bande passante agrégée entrante pour l’instance.
BandwidthOutExceeded	Événement	La file d’attente ou la suppression de paquets s’explique par le dépassement du maximum de bande passante agrégée sortante pour l’instance.
ConntrackExceeded	Événement	Le suivi des connexions a dépassé le maximum pour l’instance et le système n’a pas pu établir de nouvelles connexions, ce qui peut entraîner une perte de paquets.
IPAMDInconsistent État	Événement	L'état du point de contrôle IPAMD sur le disque ne reflète pas l'environnement d' IPs exécution du conteneur.
IPAMDNoIPs	Événement	Il n'y a plus d'adresses IP sur l'IPAMD.
IPAMDNotPrêt	Condition	IPAMD ne parvient pas à se connecter au serveur API.
IPAMDNotCourir	Condition	Le processus Amazon VPC CNI n'a pas été détecté comme étant en cours d'exécution.
IPAMDRepeatedlyRedémarrer	Événement	Le service IPAMD s’est redémarré plusieurs fois.
InterfaceNotRunning	Condition	Cette interface semble ne pas fonctionner ou il y a des problèmes de réseau.
InterfaceNotUp	Condition	Cette interface semble ne pas être active ou il y a des problèmes de réseau.
KubeProxyNotReady	Événement	Kube-proxy n’a pas réussi à surveiller ou à répertorier les ressources.
LinkLocalExceeded	Événement	Le système a supprimé des paquets car le PPS du trafic vers les services mandataires locaux a dépassé le maximum de l’interface réseau.
MACAddressPolicyMisconfigured	Événement	La valeur de la configuration du lien systemd-networkd est incorrecte. MACAddressPolicy
MissingDefaultRoutes	Événement	Il manque des règles de routage par défaut.
Manquant IPRoutes	Événement	Il manque des itinéraires pour Pod IPs.
Manquant IPRules	Événement	Il manque des règles pour Pod IPs.
MissingLoopbackInterface	Condition	L’interface de bouclage est manquante dans cette instance, ce qui entraîne l’échec des services dépendant de la connectivité locale.
NetworkSysctl	Événement	Les sysctl paramètres réseau de ce nœud sont potentiellement incorrects.
PPSExceeded	Événement	Des paquets ont été mis en file d’attente ou supprimés car le PPS bidirectionnel a dépassé le maximum pour l’instance.
PortConflict	Événement	Si un Pod utilise HostPort, il peut écrire des iptables règles qui remplacent les ports déjà liés de l'hôte, empêchant potentiellement l'accès du serveur API à. kubelet
UnexpectedRejectRule	Événement	Une DROP règle REJECT ou un élément inattendu a été détecté dans leiptables, bloquant potentiellement le trafic attendu.

Problèmes d’état du nœud de stockage

La condition de surveillance est StorageReady pour les problèmes du tableau suivant qui ont une sévérité « Condition ».

Name	Sévérité	Description
EBSInstanceIOPSExceeded	Événement	Le nombre maximal d'IOPS pour l'instance a été dépassé.
EBSInstanceThroughputExceeded	Événement	Le débit maximal de l'instance a été dépassé.
EBSVolumeIOPSExceeded	Événement	Le nombre maximal d'IOPS pour un volume EBS donné a été dépassé.
EBSVolumeThroughputExceeded	Événement	Le débit maximal pour un volume Amazon EBS spécifique a été dépassé.
EtcHostsMountFailed	Événement	Le montage du kubelet généré /etc/hosts a échoué en raison du /var/lib/kubelet/pods remontage des données utilisateur pendant le fonctionnement. kubelet-container
IODelays	Événement	Un retard d’entrée ou de sortie a été détecté dans un processus, ce qui peut indiquer un provisionnement d’entrée-sortie insuffisant s’il est excessif.
KubeletDiskUsageSlow	Événement	Le signale kubelet une utilisation lente du disque lors de la tentative d'accès au système de fichiers. Cela peut indiquer une insuffisance des entrées-sorties du disque ou des problèmes de système de fichiers.
XFSSmallAverageClusterSize	Événement	La taille moyenne du cluster XFS est faible, ce qui indique une fragmentation excessive de l'espace libre. Cela peut empêcher la création de fichiers malgré les inodes disponibles ou l'espace libre.