Agent de surveillance de nœuds Réparation automatique de nœuds Problèmes d’intégrité des nœuds

Activer la réparation automatique des nœuds et étudier les problèmes d’intégrité de ces derniers

La santé 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 bonne santé 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 de nœuds

L’agent de surveillance des nœuds journalise automatiquement les journaux des nœuds afin de détecter certains problèmes de santé. 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 de santé détectés sont disponibles dans le tableau de bord d’observabilité. Pour de plus amples informations, consultez Problèmes d’intégrité des nœuds.

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, consultez 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, consultez Création d’un groupe de nœuds gérés pour votre cluster.
Lorsque vous utilisez l’AWS CLI, ajoutez --node-repair-config enabled=true à la commande eks create nodegroup ou eks update-nodegroup-config.
Pour obtenir un exemple de eksctl ClusterConfig utilisant un groupe de nœuds gérés avec réparation automatique des nœuds, consultez 44-node-repair.yaml sur 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 and 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 and 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’intégrité des nœuds

Les tableaux suivants décrivent les problèmes de santé 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, consultez 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, consultez Événements des nœuds.

Problèmes de santé 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 ».

Nom	Sévérité	Description
ForkFailedOutOfPID	Condition	Un appel fork ou exec a échoué en raison d’un manque d’identifiants de processus ou de mémoire dans le système, ce qui peut être causé par des processus zombies ou un épuisement de la mémoire physique.
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 maximal de PID disponibles selon le paramètre kernel.pid_max actuel, après quoi aucun autre processus ne peut ê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.
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 pour ce processus est plus important que prévu, ce qui peut être dû au fait que de nombreux services ont enableServiceLinks défini 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 de santé du nœud réseau

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

Nom	Sévérité	Description
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.
IPAMDNotReady	Condition	IPAMD ne parvient pas à se connecter au serveur API.
IPAMDNotRunning	Condition	Le processus `aws-k8s-agent` n’a pas été trouvé en cours d’exécution.
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.
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.
IPAMDNoIPs	Événement	IPAM-D est à court d’adresses IP.
IPAMDRepeatedlyRestart	Événement	Le service IPAMD s’est redémarré plusieurs fois.
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.
MissingDefaultRoutes	Événement	Il manque des règles de routage par défaut.
MissingIPRules, MissingIPRoutes	Événement	Il manque des règles de routage pour les adresses IP des pods suivants dans la table de routage.
NetworkSysctl	Événement	Les paramètres sysctl réseau de ce nœud sont potentiellement incorrects.
PortConflict	Événement	Si un pod utilise hostPort, il peut écrire des règlesiptables qui remplacent les ports déjà liés à l’hôte, ce qui peut empêcher l’accès du serveur API à `kubelet`.
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.
UnexpectedRejectRule	Événement	Une règle `REJECT` ou `DROP` inattendue a été trouvée dans lesiptables, ce qui peut bloquer le trafic attendu.

Problèmes de santé des nœuds Neuron

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

Nom	Sévérité	Description
NeuronDMAError	Condition	Un moteur DMA a rencontré une erreur irrécupérable.
NeuronHBMUncorrectableError	Condition	Une mémoire HBM a rencontré une erreur incorrigible et a produit des résultats incorrects.
NeuronNCUncorrectableError	Condition	Une erreur mémoire incorrigible du cœur Neuron a été détectée.
NeuronSRAMUncorrectableError	Condition	Une mémoire SRAM sur puce a rencontré une erreur de parité et a produit des résultats incorrects.

Problèmes de santé des nœuds NVIDIA

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.

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

Nom	Sévérité	Description	Action de réparation
NvidiaDoubleBitError	Condition	Le pilote GPU a généré une erreur double bit.	Remplacez
NvidiaNVLinkError	Condition	Le pilote GPU a signalé des erreurs NVLink.	Remplacez
NvidiaXID13Error	Condition	Le moteur graphique a déclenché une exception.	Redémarrer
NvidiaXID31Error	Condition	Des problèmes matériels sont suspectés.	Redémarrer
NvidiaXID48Error	Condition	Des erreurs ECC double bit sont signalées par le pilote.	Redémarrer
NvidiaXID63Error	Condition	Il y a un retrait de page ou un remappage de ligne.	Redémarrer
NvidiaXID64Error	Condition	Des échecs se produisent lors de la tentative de mettre hors service d’une page ou de remappage d’un nœud.	Redémarrer
NvidiaXID74Error	Condition	Il y a un problème avec la connexion entre le GPU et un autre GPU ou NVSwitch via NVLink. Cela peut indiquer une défaillance matérielle de la liaison elle-même ou un problème avec le périphérique à l’extrémité distante de la liaison.	Remplacez
NvidiaXID79Error	Condition	Le pilote GPU a tenté d’accéder au GPU via sa connexion PCI Express et a constaté que le GPU n’était pas accessible.	Remplacez
NvidiaXID94Error	Condition	Il y a des erreurs de mémoire ECC.	Redémarrer
NvidiaXID95Error	Condition	Il y a des erreurs de mémoire ECC.	Redémarrer
NvidiaXID119Error	Condition	Le GSP a dépassé le délai de réponse aux demandes RPC provenant d’autres bits du pilote.	Remplacez
NvidiaXID120Error	Condition	Le GSP a répondu dans les délais, mais avec une erreur.	Remplacez
NvidiaXID121Error	Condition	C2C est une interconnexion de puces. Elle permet le partage de mémoire entre les processeurs, les accélérateurs, etc.	Remplacez
NvidiaXID140Error	Condition	Le pilote GPU a peut-être détecté des erreurs incorrigibles dans la mémoire GPU, de telle sorte qu’il n’a pas pu marquer les pages pour la mise hors ligne dynamique ou le remappage des lignes.	Remplacez
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.	Aucun
NvidiaXID[Code]Warning	Événement	Toute occurrence de XID autre que ceux définis dans cette liste entraîne cet événement.	Aucun
DCGMError	Condition	La connexion au processus hôte Data Center GPU Manager (DCGM) a été perdue ou n’a pas pu être établie.	Aucun
DCGMDiagnosticError	Condition	Un problème s’est produit lors de l’exécution des diagnostics actifs DCGM.	Aucun
DCGMDiagnosticFailure	Condition	Un cas de test de la suite de tests de diagnostic actif DCGM a échoué.	Aucun

Problèmes de santé des nœuds d’exécution

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

Nom	Sévérité	Description
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.
%sRepeatedRestart	Événement	Redémarrage de tout service systemd sur le nœud (formaté en utilisant le nom de l’unité avec la casse de titre).
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.
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.
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.
ServiceFailedToStart	Événement	Une unité systemd n’a pas pu démarrer.

Problèmes de santé 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 ».

Nom	Sévérité	Description
XFSSmallAverageClusterSize	Condition	La taille moyenne du cluster XFS est petite, ce qui indique une fragmentation excessive de l’espace libre qui peut empêcher la création de fichiers malgré la disponibilité d’inodes ou d’espace libre.
EtcHostsMountFailed	Événement	Le montage du kubelet a généré `/etc/hosts` a échoué en raison du remontage des données utilisateur `/var/lib/kubelet/pods` pendant le fonctionnement du conteneur kubelet.
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	Kubelet signale une utilisation lente du disque lors de la tentative d’accès au système de fichiers, ce qui peut indiquer un problème d’entrée-sortie du disque ou du système de fichiers.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Builds personnalisés

Afficher l’état de santé des nœuds