**Aidez à améliorer cette page**
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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
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.
# Détectez les problèmes de santé des nœuds et activez la réparation automatique des nœuds
L'état de santé du nœud fait référence à l'état opérationnel et à la capacité d'un nœud Kubernetes à exécuter efficacement les charges de travail. Un nœud sain maintient la connectivité réseau attendue, dispose de ressources de calcul et de stockage suffisantes et peut exécuter des charges de travail sans interruption.
Pour aider à maintenir des nœuds sains dans les clusters EKS, EKS propose l'*agent de surveillance des nœuds* et la *réparation automatique des nœuds*. Ces fonctionnalités sont automatiquement activées avec le calcul en mode automatique d'EKS. Vous pouvez également utiliser la réparation automatique des nœuds avec les groupes de nœuds gérés par EKS et Karpenter, et vous pouvez utiliser l'agent de surveillance des nœuds EKS avec tous les types de calcul EKS, à l'exception de AWS Fargate. L'agent de surveillance des nœuds EKS et la réparation automatique des nœuds sont plus efficaces lorsqu'ils sont utilisés ensemble, mais ils peuvent également être utilisés individuellement dans les clusters EKS.
**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 EKS lit les journaux des nœuds pour détecter les problèmes de santé. Il analyse les journaux pour détecter les défaillances et affiche des informations sur l'état de santé des nœuds. Pour chaque catégorie de problèmes détectés, l'agent applique un nœud dédié `NodeCondition` aux nœuds de travail. Pour obtenir des informations détaillées sur les problèmes de santé des nœuds détectés par l'agent de surveillance des nœuds EKS, consultez[Détectez les problèmes de santé des nœuds avec l'agent de surveillance des nœuds EKS](node-health-nma.md).
Le calcul en mode automatique EKS inclut l'agent de surveillance des nœuds. Pour les autres types de calcul EKS, vous pouvez ajouter l'agent de surveillance des nœuds en tant que module complémentaire EKS ou vous pouvez le gérer à l'aide d'outils Kubernetes tels que Helm. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de surveillance des nœuds](node-health-nma.md#node-monitoring-agent-configure).
Avec l'agent de surveillance des nœuds EKS, les catégories suivantes de problèmes de santé des nœuds apparaissent sous forme de problèmes liés aux nœuds. Notez que `Ready``DiskPressure`, et `MemoryPressure` sont des conditions de nœud Kubernetes standard qui apparaissent même sans l'agent de surveillance des nœuds EKS.
| État du nœud | Description |
| --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indique si le matériel accéléré (GPU, Neuron) du nœud fonctionne correctement. |
| ContainerRuntimeReady | ContainerRuntimeReady indique si le moteur d'exécution du conteneur (containerd, etc.) fonctionne correctement et est capable d'exécuter des conteneurs. |
| DiskPressure | DiskPressure est une condition standard de Kubernetes indiquant que le nœud est soumis à une pression sur le disque (espace disque insuffisant ou E/S élevées). |
| KernelReady | KernelReady indique si le noyau fonctionne correctement sans erreur critique, panique ou épuisement des ressources. |
| MemoryPressure | MemoryPressure est une condition standard de Kubernetes indiquant que le nœud est soumis à une pression de mémoire (faible mémoire disponible). |
| NetworkingReady | NetworkingReady indique si la pile réseau du nœud fonctionne correctement (interfaces, routage, connectivité). |
| StorageReady | StorageReady indique si le sous-système de stockage du nœud fonctionne correctement (disques, systèmes de fichiers, E/S). |
| Prêt | Prêt est la condition standard de Kubernetes indiquant que le nœud est sain et prêt à accepter des pods. |
## Réparation automatique des nœuds
La réparation automatique des nœuds EKS surveille en permanence l'état des nœuds, réagit aux problèmes détectés et remplace ou redémarre les nœuds lorsque cela est possible. Cela améliore la fiabilité du cluster avec une intervention manuelle minimale et contribue à réduire les temps d'arrêt des applications.
À elle seule, la réparation automatique des nœuds EKS réagit aux `Ready` conditions du kubelet, à tous les objets de nœud supprimés manuellement et aux instances de groupes de nœuds gérés par EKS qui ne parviennent pas à rejoindre le cluster. Lorsque la réparation automatique des nœuds EKS est activée avec l'agent de surveillance des nœuds installé, la réparation automatique des nœuds EKS réagit aux conditions supplémentaires des nœuds : `AcceleratedHardwareReady` `ContainerRuntimeReady``KernelReady`,`NetworkingReady`,, et`StorageReady`.
La réparation automatique des nœuds EKS ne réagit pas à Kubernetes standard ni `PIDPressure` aux `DiskPressure` conditions `MemoryPressure` des nœuds. Ces conditions indiquent souvent des problèmes liés au comportement des applications, à la configuration de la charge de travail ou aux limites de ressources plutôt que des défaillances au niveau des nœuds, ce qui complique la détermination d'une action de réparation par défaut appropriée. Dans ces scénarios, les charges de travail sont soumises au comportement d'éviction par pression des [nœuds](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction) Kubernetes.
Pour plus d'informations sur la réparation automatique des nœuds EKS, consultez[Réparer automatiquement les nœuds dans les clusters EKS](node-repair.md).
**Topics**
# Détectez les problèmes de santé des nœuds avec l'agent de surveillance des nœuds EKS
Cette rubrique détaille les problèmes de santé des nœuds détectés par l'agent de surveillance des nœuds EKS, la manière dont ces problèmes apparaissent sous forme de conditions ou d'événements sur les nœuds, et comment configurer l'agent de surveillance des nœuds.
L'agent de surveillance des nœuds EKS peut être utilisé avec ou sans réparation automatique des nœuds EKS. Pour plus d'informations sur la réparation automatique des nœuds EKS, consultez[Réparer automatiquement les nœuds dans les clusters EKS](node-repair.md).
Le code source de l'agent de surveillance des nœuds EKS est publié GitHub dans le eks-node-monitoring-agent référentiel [aws/](https://github.com/aws/eks-node-monitoring-agent).
## 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](learn-status-conditions.md#status-node-conditions).
+ É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](learn-status-conditions.md#status-node-events).
## 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 ». Les événements et conditions décrits dans le tableau ci-dessous concernent les problèmes de santé des nœuds liés à NVIDIA et Neuron.
| Nom | Sévérité | Description | Action de réparation |
| --- | --- | --- | --- |
| DCGMDiagnosticDéfaillance | Condition | Un cas de test de la suite de tests de diagnostic actif DCGM a échoué. | Aucune |
| DCGMError | Condition | La connexion au processus hôte DCGM a été perdue ou n'a pas pu être établie. | Aucune |
| DCGMFieldErreur [Code] | Événement | Le DCGM a détecté une dégradation du GPU grâce à un identifiant de champ. | Aucune |
| DCGMHealthCode [Code] | Événement | Un bilan de santé du DCGM a échoué de manière non fatale. | Aucune |
| DCGMHealthCode [Code] | Condition | Un bilan de santé du DCGM a échoué de manière fatale. | Aucune |
| Neurone DMAError | Condition | Un moteur DMA a rencontré une erreur irrécupérable. | Remplacez |
| Erreur neuronale HBMUncorrectable | Condition | Une mémoire HBM a rencontré une erreur incorrigible et a produit des résultats incorrects. | Remplacez |
| Erreur neuronale NCUncorrectable | Condition | Une erreur mémoire incorrigible du cœur Neuron a été détectée. | Remplacez |
| Erreur neuronale SRAMUncorrectable | Condition | Une mémoire SRAM sur puce a rencontré une erreur de parité et a produit des résultats incorrects. | Remplacez |
| 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. | Aucune |
| NvidiaDoubleBitError | Condition | Le pilote GPU a généré une erreur double bit. | Remplacez |
| Nvidia NCCLError | Événement | Une erreur de segmentation s'est produite dans la bibliothèque NVIDIA Collective Communications (`libnccl`). | Aucune |
| NVLinkErreur Nvidia | Condition | NVLink des erreurs ont été signalées par le pilote du GPU. | Remplacez |
| PCIeErreur Nvidia | Événement | PCIe des rediffusions ont été déclenchées pour remédier à des erreurs de transmission. | Aucune |
| NvidiaPageRetirement | Event | 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. | Aucune |
| NvidiaPowerError | Event | La consommation d'énergie GPUs a dépassé les seuils autorisés. | Aucune |
| NvidiaThermalError | Event | L'état thermique GPUs a dépassé les seuils autorisés. | Aucune |
| Erreur NvidiaXid [Code] | Condition | Une erreur critique du processeur graphique s'est produite. | Remplacer ou redémarrer |
| NvidiaXID[Code]Warning | Événement | Une erreur GPU non critique s'est produite. | Aucune |
## Codes d'erreur NVIDIA XID
L'agent de surveillance des nœuds détecte les erreurs NVIDIA XID dans les journaux du noyau du GPU. Les erreurs XID se répartissent en deux catégories :
+ **Codes XID connus** : erreurs critiques qui définissent la condition d'un nœud (`AcceleratedHardwareReady=False`) et déclenchent une réparation automatique lorsqu'ils sont activés. La raison pour laquelle le format du code est`NvidiaXID[Code]Error`. Les codes XID bien connus détectés par l'agent de surveillance des nœuds EKS ne représentent peut-être pas la liste complète des codes XID NVIDIA nécessitant des actions de réparation.
+ **Codes XID inconnus** : enregistrés uniquement en tant qu'événements Kubernetes. Ils ne déclenchent pas la réparation auto. La raison pour laquelle le format du code est`NvidiaXID[Code]Warning`. Pour rechercher des erreurs XID inconnues, consultez les journaux de votre noyau avec`dmesg | grep -i nvrm`.
Pour plus d’informations sur les erreurs XID, consultez [Erreurs XID](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) 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](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) dans la *Documentation sur le déploiement et la gestion des GPU NVIDIA*.
Le tableau suivant répertorie les codes XID connus, leur signification et l'action de réparation des nœuds par défaut si elle est activée.
| Code XID | Description | Action de réparation |
| --- | --- | --- |
| 13 | Exception relative au moteur graphique : une erreur du moteur graphique du processeur graphique s'est produite, généralement en raison de problèmes logiciels ou de bogues du pilote. | Redémarrer |
| 31 | Erreur de page de mémoire du processeur graphique : une application a tenté d'accéder à la mémoire du processeur graphique qui n'est ni mappée ni accessible. | Redémarrer |
| 48 | Erreur ECC double bit — Une erreur double bit non corrigible s'est produite dans la mémoire du GPU, indiquant une dégradation matérielle potentielle. | Redémarrer |
| 63 | Événement de remappage de la mémoire du GPU : le pilote du GPU a remappé une partie de la mémoire du GPU en raison d'erreurs détectées. Cela est souvent récupérable. | Redémarrer |
| 64 | Échec du remappage de la mémoire du processeur graphique : le processeur graphique n'a pas pu remapper la mémoire défectueuse, ce qui indique des problèmes matériels. | Redémarrer |
| 74 | NVLink Erreur — Une erreur s'est produite lors de l' NVLink interconnexion haut débit entre GPUs. | Remplacez |
| 79 | Le GPU est tombé du bus — Le GPU n'est plus accessible via PCIe, ce qui indique généralement une panne matérielle ou un problème d'alimentation. | Remplacez |
| 94 | Erreur de mémoire contenue : une erreur de mémoire s'est produite mais elle est restée confinée et n'a pas affecté les autres applications. | Redémarrer |
| 95 | Erreur de mémoire non confinée : une erreur de mémoire s'est produite et peut avoir affecté d'autres applications ou la mémoire du système. | Redémarrer |
| 119 | Délai d'expiration du GSP RPC : le délai de communication avec le processeur du système GPU a expiré, probablement en raison de problèmes liés au microprogramme. | Remplacez |
| 120 | Erreur GSP — Une erreur s'est produite dans le processeur du système GPU. | Remplacez |
| 121 | Erreur C2C — Une erreur s'est produite sur l' chip-to-chipinterconnexion (utilisée en GPUs multipuce). | Remplacez |
| 140 | Erreur ECC non récupérée — Une erreur ECC a échappé au confinement et a peut-être endommagé les données. | Remplacez |
Pour afficher l'état actuel du nœud lié à l'état du GPU, exécutez la commande suivante.
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
Pour afficher les événements liés au XID sur votre cluster, exécutez l'une des commandes suivantes.
```
kubectl get events | grep -i "NvidiaXID"
```
## 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 ».
| Nom | Sévérité | Description | Action de réparation |
| --- | --- | --- | --- |
| 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. | Aucune |
| DeprecatedContainerdConfiguration | Event | 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` | Aucune |
| KubeletFailed | Event | Le kubelet est passé à l’état d’échec. | Aucune |
| LivenessProbeFailures | Event | 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. | Aucune |
| 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. | Remplacez |
| 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. | Aucune |
| [Nom] RepeatedRestart | Événement | Une unité systemd redémarre fréquemment. | Aucune |
| ServiceFailedToStart | Event | Une unité systemd n’a pas pu démarrer. | Aucune |
## 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 ».
| Nom | Sévérité | Description | Action de réparation |
| --- | --- | --- | --- |
| 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. | Aucune |
| AppCrash | Event | Une application sur le nœud a planté. | Aucune |
| ApproachingKernelPidMax | Event | 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é. | Aucune |
| ApproachingMaxOpenFiles | Event | 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. | Aucune |
| ConntrackExceededKernel | Event | 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. | Aucune |
| ExcessiveZombieProcesses | Event | 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. | Aucune |
| 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. | Remplacez |
| 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. | Aucune |
| LargeEnvironment | Event | 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. | Aucune |
| RapidCron | Event | 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. | Aucune |
| SoftLockup | Event | Le CPU s’est bloqué pendant un certain temps. | Aucune |
## 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 ».
| Nom | Sévérité | Description | Action de réparation |
| --- | --- | --- | --- |
| 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. | Aucune |
| BandwidthOutExceeded | Event | 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. | Aucune |
| ConntrackExceeded | Event | 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. | Aucune |
| EFAErrorMétrique | Événement | Les indicateurs du pilote EFA indiquent qu'il existe une interface présentant une dégradation des performances. | Aucune |
| 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. | Aucune |
| IPAMDNoIPs | Event | Il n'y a plus d'adresses IP sur l'IPAMD. | Aucune |
| IPAMDNotPrêt | Condition | IPAMD ne parvient pas à se connecter au serveur API. | Remplacez |
| IPAMDNotCourir | Condition | Le processus Amazon VPC CNI n'a pas été détecté comme étant en cours d'exécution. | Remplacez |
| IPAMDRepeatedlyRedémarrer | Événement | Le service IPAMD s’est redémarré plusieurs fois. | Aucune |
| InterfaceNotRunning | Condition | Cette interface semble ne pas fonctionner ou il y a des problèmes de réseau. | Remplacez |
| InterfaceNotUp | Condition | Cette interface semble ne pas être active ou il y a des problèmes de réseau. | Remplacez |
| KubeProxyNotReady | Événement | Kube-proxy n’a pas réussi à surveiller ou à répertorier les ressources. | Aucune |
| LinkLocalExceeded | Event | 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. | Aucune |
| MACAddressPolicyMisconfigured | Event | La valeur de la configuration du lien systemd-networkd est incorrecte. `MACAddressPolicy` | Aucune |
| MissingDefaultRoutes | Event | Il manque des règles de routage par défaut. | Aucune |
| Manquant IPRoutes | Événement | Il manque des itinéraires pour Pod IPs. | Aucune |
| Manquant IPRules | Événement | Il manque des règles pour Pod IPs. | Aucune |
| 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. | Remplacez |
| NetworkSysctl | Événement | Les `sysctl` paramètres réseau de ce nœud sont potentiellement incorrects. | Aucune |
| PPSExceeded | Event | Des paquets ont été mis en file d’attente ou supprimés car le PPS bidirectionnel a dépassé le maximum pour l’instance. | Aucune |
| PortConflict | Event | 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` | Aucune |
| UnexpectedRejectRule | Event | Une `DROP` règle `REJECT` ou un élément inattendu a été détecté dans le`iptables`, bloquant potentiellement le trafic attendu. | Aucune |
## 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 ».
| Nom | Sévérité | Description | Action de réparation |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | Événement | Le nombre maximal d'IOPS pour l'instance a été dépassé. | Aucune |
| EBSInstanceThroughputExceeded | Event | Le débit maximal de l'instance a été dépassé. | Aucune |
| EBSVolumeIOPSExceeded | Event | Le nombre maximal d'IOPS pour un volume EBS donné a été dépassé. | Aucune |
| EBSVolumeThroughputExceeded | Event | Le débit maximal pour un volume Amazon EBS spécifique a été dépassé. | Aucune |
| EtcHostsMountFailed | Event | 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` | Aucune |
| IODelays | Event | 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. | Aucune |
| KubeletDiskUsageSlow | Event | 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. | Aucune |
| XFSSmallAverageClusterSize | Event | 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. | Aucune |
## Configuration de l'agent de surveillance des nœuds
L'agent de surveillance des nœuds EKS est déployé en tant que DaemonSet. Lorsque vous le déployez en tant que module complémentaire EKS, vous pouvez personnaliser l'installation avec les valeurs de configuration suivantes. Pour les configurations par défaut, reportez-vous au [diagramme Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) de l'agent de surveillance des nœuds EKS.
| Option de configuration | Description |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | Demande de ressources CPU pour l'agent de surveillance. |
| `monitoringAgent.resources.requests.memory` | Demande de ressource mémoire pour l'agent de surveillance. |
| `monitoringAgent.resources.limits.cpu` | Limite de ressources du processeur pour l'agent de surveillance. |
| `monitoringAgent.resources.limits.memory` | Limite de ressources de mémoire pour l'agent de surveillance. |
| `monitoringAgent.tolerations` | Tolérances pour la planification de l'agent de surveillance sur les nœuds contaminés. |
| `monitoringAgent.additionalArgs` | Arguments de ligne de commande supplémentaires à transmettre à l'agent de surveillance. |
**Note**
Vous pouvez configurer `hostname-override` et `verbosity` comme `monitoringAgent.additionalArgs` pour les modules complémentaires EKS ou l'installation de Helm. Vous ne pouvez actuellement pas personnaliser l'agent de surveillance des nœuds `probe-address` (`8002`) ou `metrics-address` (`8003`) via des arguments supplémentaires avec les modules complémentaires EKS ou l'installation de Helm.
L'agent de surveillance des nœuds inclut un composant serveur NVIDIA DCGM (Data Center GPU Manager) (`nv-hostengine`) pour surveiller NVIDIA GPUs. Ce composant s'exécute uniquement sur les nœuds qui sont des types d'instances de GPU NVIDIA, comme indiqué `nodeAffinity` dans le [graphique Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) de l'agent. Vous ne pouvez pas utiliser une installation NVIDIA DCGM existante avec l'agent de surveillance des nœuds EKS. Veuillez nous faire part de vos commentaires sur le [GitHub numéro \$12763](https://github.com/aws/containers-roadmap/issues/2763) de la feuille de route EKS si vous avez besoin de cette fonctionnalité.
Lorsque vous déployez l'agent de surveillance des nœuds EKS en tant que module complémentaire EKS, vous pouvez personnaliser l'installation NVIDIA DCGM avec les valeurs de configuration suivantes.
| Option de configuration | Description |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | Demande de ressource CPU pour l'agent DCGM. |
| `dcgmAgent.resources.requests.memory` | Demande de ressource mémoire pour l'agent DCGM. |
| `dcgmAgent.resources.limits.cpu` | Limite de ressources du processeur pour l'agent DCGM. |
| `dcgmAgent.resources.limits.memory` | Limite de ressources de mémoire pour l'agent DCGM. |
| `dcgmAgent.tolerations` | Tolérances pour la planification de l'agent DCGM sur des nœuds contaminés. |
Vous pouvez utiliser les commandes AWS CLI suivantes pour obtenir des informations utiles sur les versions et le schéma du module complémentaire EKS de l'agent de surveillance des nœuds EKS.
Téléchargez la dernière version du module complémentaire d'agent pour votre version de Kubernetes. `1.35`Remplacez-le par votre version de Kubernetes.
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
Obtenez le schéma des modules complémentaires d'agent pris en charge dans les modules complémentaires EKS. `v1.5.1-eksbuild.1`Remplacez-le par la version de votre agent.
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# Réparer automatiquement les nœuds dans les clusters EKS
Cette rubrique décrit le comportement de réparation automatique des nœuds EKS et explique comment le configurer pour répondre à vos besoins. La réparation automatique des nœuds EKS est activée par défaut en mode automatique EKS et peut être utilisée avec les groupes de nœuds gérés par EKS et Karpenter.
Les actions de réparation automatique des nœuds EKS par défaut sont résumées dans le tableau ci-dessous et s'appliquent au comportement du mode automatique EKS, des groupes de nœuds gérés par EKS et de Karpenter. Lorsque vous utilisez le mode automatique d'EKS ou Karpenter, toutes les actions de `AcceleratedHardwareReady` réparation le sont`Replace`, et seuls les groupes de nœuds gérés par EKS sont pris `Reboot` en charge en tant qu'action de réparation.
Pour obtenir une liste détaillée des problèmes de santé des nœuds détectés par l'agent de surveillance des nœuds EKS et des actions de réparation des nœuds correspondantes, consultez[Détectez les problèmes de santé des nœuds avec l'agent de surveillance des nœuds EKS](node-health-nma.md).
| État du nœud | Description | Réparation après | Action (s) de réparation |
| --- | --- | --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indique si le matériel accéléré (GPU, Neuron) du nœud fonctionne correctement. | 10 m | Remplacer ou redémarrer |
| ContainerRuntimeReady | ContainerRuntimeReady indique si le moteur d'exécution du conteneur (containerd, etc.) fonctionne correctement et est capable d'exécuter des conteneurs. | 30 m | Remplacez |
| DiskPressure | DiskPressure est une condition standard de Kubernetes indiquant que le nœud est soumis à une pression sur le disque (espace disque insuffisant ou E/S élevées). | N/A | Aucune |
| KernelReady | KernelReady indique si le noyau fonctionne correctement sans erreur critique, panique ou épuisement des ressources. | 30 m | Remplacez |
| MemoryPressure | MemoryPressure est une condition standard de Kubernetes indiquant que le nœud est soumis à une pression de mémoire (faible mémoire disponible). | N/A | Aucune |
| NetworkingReady | NetworkingReady indique si la pile réseau du nœud fonctionne correctement (interfaces, routage, connectivité). | 30 m | Remplacez |
| StorageReady | StorageReady indique si le sous-système de stockage du nœud fonctionne correctement (disques, systèmes de fichiers, E/S). | 30 m | Remplacez |
| Prêt | Prêt est la condition standard de Kubernetes indiquant que le nœud est sain et prêt à accepter des pods. | 30 m | Remplacez |
Les actions de réparation automatique des nœuds EKS sont désactivées par défaut dans les scénarios suivants. Les actions de réparation des nœuds en cours se poursuivent dans chaque scénario. Découvrez [Configurer la réparation automatique des nœuds](#configure-node-repair) comment remplacer ces paramètres par défaut.
**Groupes de nœuds gérés par EKS**
+ Le groupe de nœuds compte plus de cinq nœuds et plus de 20 % des nœuds du groupe de nœuds ne fonctionnent pas correctement.
+ Un changement de zone pour votre cluster se déclenche via l'Application Recovery Controller (ARC).
**Mode automatique EKS et Karpenter**
+ Plus de 20 % des nœuds du NodePool sont en mauvais état.
+ En mode autonome NodeClaims, 20 % des nœuds du cluster ne fonctionnent pas correctement.
## Configurer la réparation automatique des nœuds
La réparation automatique des nœuds ne peut pas être configurée lors de l'utilisation du mode automatique EKS et elle est toujours activée avec les mêmes paramètres par défaut que Karpenter.
### Karpenter
Pour utiliser la réparation automatique des nœuds avec Karpenter, activez le portail `NodeRepair=true` des fonctionnalités. Vous pouvez activer les portes de fonctionnalités via l'option `--feature-gates` CLI ou la variable d'`FEATURE_GATES`environnement dans le déploiement de Karpenter. Pour en savoir plus, veuillez consulter la documentation [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair).
### Groupes de nœuds gérés
Vous pouvez activer la réparation automatique des nœuds lors de la création de nouveaux groupes de nœuds gérés par EKS ou en mettant à jour les groupes de nœuds gérés par EKS existants.
+ **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](create-managed-node-group.md).
+ ** AWS CLI** — Ajoutez `--node-repair-config enabled=true` à la [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html)commande [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)ou.
+ **eksctl** [— Configure`managedNodeGroups.nodeRepairConfig.enabled: true`, voir l'exemple dans le eksctl. GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml)
Lorsque vous utilisez des groupes de nœuds gérés par EKS, vous pouvez contrôler le comportement de réparation automatique des nœuds à l'aide des paramètres suivants.
Pour contrôler le moment où la réparation automatique des nœuds cesse d'agir, définissez un seuil basé sur le nombre de nœuds défectueux dans le groupe de nœuds. Définissez le nombre absolu ou le pourcentage, mais pas les deux.
| Paramètre | Description |
| --- | --- |
| `maxUnhealthyNodeThresholdCount` | Nombre absolu de nœuds défectueux au-dessus duquel la réparation automatique des nœuds s'arrête. Utilisez-le pour limiter l'étendue des réparations. |
| `maxUnhealthyNodeThresholdPercentage` | Pourcentage de nœuds défectueux au-dessus duquel la réparation automatique des nœuds s'arrête (0 à 100). |
Pour contrôler le nombre de nœuds réparés simultanément, vous pouvez configurer le parallélisme de réparation. Comme pour le seuil de nœuds défectueux, définissez le nombre absolu ou le pourcentage, mais pas les deux.
| Paramètre | Description |
| --- | --- |
| `maxParallelNodesRepairedCount` | Le nombre maximum de nœuds à réparer simultanément. |
| `maxParallelNodesRepairedPercentage` | Pourcentage maximal de nœuds défectueux à réparer simultanément (0 à 100). |
Avec`nodeRepairConfigOverrides`, vous pouvez personnaliser le comportement de réparation en fonction de conditions spécifiques. Utilisez-le lorsque vous avez besoin de différentes actions de réparation ou de temps d'attente pour différents types de problèmes.
Chaque dérogation nécessite tous les champs suivants :
| Champ | Description |
| --- | --- |
| `nodeMonitoringCondition` | Type de condition du nœud signalé par l'agent de surveillance du nœud. Par exemple :`AcceleratedHardwareReady`,`NetworkingReady`,`StorageReady`,`KernelReady`. |
| `nodeUnhealthyReason` | Le code de raison spécifique de l'état insalubre. Par exemple `NvidiaXID31Error`, `IPAMDNotRunning`. |
| `minRepairWaitTimeMins` | Durée minimale, en minutes, pendant laquelle la condition doit persister avant que le nœud puisse être réparé. Utilisez-le pour éviter de réparer les nœuds pour des problèmes temporaires. |
| `repairAction` | L'action à entreprendre lorsque les conditions sont réunies. Valeurs valides : `Replace` (arrêt et remplacement du nœud), `Reboot` (redémarrage du nœud) ou `NoAction` (aucune action de réparation). |
L'exemple de AWS CLI suivant crée un groupe de nœuds avec des paramètres de réparation personnalisés.
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--node-role arn:aws:iam::111122223333:role/NodeRole \
--subnets subnet-0123456789abcdef0 \
--node-repair-config '{
"enabled": true,
"maxUnhealthyNodeThresholdPercentage": 10,
"maxParallelNodesRepairedCount": 3,
"nodeRepairConfigOverrides": [
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID64Error",
"minRepairWaitTimeMins": 5,
"repairAction": "Replace"
},
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID31Error",
"minRepairWaitTimeMins": 15,
"repairAction": "NoAction"
}
]
}'
```
Cette configuration effectue les opérations suivantes :
+ Permet la réparation automatique des nœuds
+ Arrête les actions de réparation lorsque plus de 10 % des nœuds ne sont pas sains
+ Répare jusqu'à 3 nœuds à la fois
+ Annule les erreurs XID 64 (échec du remappage de la mémoire du GPU) pour remplacer le nœud au bout de 5 minutes. La valeur par défaut est le redémarrage au bout de 10 minutes.
+ Annule les erreurs XID 31 (erreur de page de mémoire du GPU) pour ne rien faire. La valeur par défaut est le redémarrage au bout de 10 minutes.
# Afficher l’état de vos nœuds
Cette rubrique explique les outils et les méthodes disponibles pour surveiller l’état des nœuds dans les clusters Amazon EKS. Les informations couvrent les conditions des nœuds, les événements et les cas de détection qui vous aident à identifier et à diagnostiquer les problèmes au niveau des nœuds. Utilisez les commandes et les modèles décrits ici pour inspecter les ressources d’état des nœuds, interpréter les conditions d’état et analyser les événements des nœuds à des fins de dépannage opérationnel.
Vous pouvez obtenir certaines informations sur l’état des nœuds à l’aide des commandes Kubernetes pour tous les nœuds. Si vous utilisez l’agent de surveillance des nœuds via le mode automatique Amazon EKS ou le module complémentaire géré par Amazon EKS, vous obtiendrez une plus grande variété de signaux de nœuds pour vous aider à résoudre les problèmes. Les descriptions des problèmes d’état détectés par l’agent de surveillance des nœuds sont également disponibles dans le tableau de bord d’observabilité. Pour de plus amples informations, veuillez consulter [Détectez les problèmes de santé des nœuds avec l'agent de surveillance des nœuds EKS](node-health-nma.md).
## Conditions des nœuds
Les conditions des nœuds représentent des problèmes terminaux nécessitant des mesures correctives telles que le remplacement ou le redémarrage d’une instance.
**Pour obtenir les conditions de tous les nœuds :**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**Pour obtenir les conditions détaillées d’un nœud spécifique :**
```
kubectl describe node node-name
```
**Exemple de sortie de condition d’un nœud en bon état :**
```
- lastHeartbeatTime: "2024-11-21T19:07:40Z"
lastTransitionTime: "2024-11-08T03:57:40Z"
message: Monitoring for the Networking system is active
reason: NetworkingIsReady
status: "True"
type: NetworkingReady
```
**Exemple de condition d’un nœud en mauvais état présentant un problème de réseau :**
```
- lastHeartbeatTime: "2024-11-21T19:12:29Z"
lastTransitionTime: "2024-11-08T17:04:17Z"
message: IPAM-D has failed to connect to API Server which could be an issue with
IPTable rules or any other network configuration.
reason: IPAMDNotReady
status: "False"
type: NetworkingReady
```
## Événements des nœuds
Les événements des nœuds indiquent des problèmes temporaires ou des configurations sous-optimales.
**Pour obtenir tous les événements signalés par l’agent de surveillance des nœuds :**
Lorsque l’agent de surveillance des nœuds est disponible, vous pouvez exécuter la commande suivante.
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
Exemple de sortie :
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**Pour obtenir les événements de tous les nœuds**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**Pour obtenir les événements d’un nœud spécifique**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**Pour surveiller les événements en temps réel**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**Exemple de sortie d’événement :**
```
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure
5m Normal NodeReady Node/node-1 Node became ready
```
## Commandes de dépannage courantes
```
# Get comprehensive node status
kubectl get node node-name -o yaml
# Watch node status changes
kubectl get nodes -w
# Get node metrics
kubectl top node
```
# Extraction des journaux d’un nœud géré à l’aide de kubectl et S3
Découvrez comment extraire les journaux d’un nœud géré Amazon EKS disposant de l’agent de surveillance des nœuds.
## Conditions préalables
Vérifiez que vous avez les éléments suivants :
+ Un cluster Amazon EKS existant avec l’agent de surveillance des nœuds installé. Pour de plus amples informations, veuillez consulter [Détectez les problèmes de santé des nœuds et activez la réparation automatique des nœuds](node-health.md).
+ L’outil en ligne de commande `kubectl` installé et configuré pour communiquer avec votre cluster.
+ La AWS CLI s'est installée et s'est connectée avec des autorisations suffisantes pour créer des compartiments et des objets S3.
+ Une version récente de Python 3 installée
+ Le AWS SDK pour Python 3, Boto 3, est installé.
## Étape 1 : créer un compartiment S3 de destination (facultatif)
Si vous ne disposez pas encore d’un compartiment S3 pour stocker les journaux, créez-en un. Utilisez la commande AWS CLI suivante. Le compartiment utilise par défaut la liste de contrôle d’accès `private`. *bucket-name*Remplacez-le par le nom de compartiment unique que vous avez choisi.
```
aws s3api create-bucket --bucket
```
## Étape 2 : créer une URL S3 pré-signée pour HTTP PUT
Amazon EKS renvoie les journaux du nœud par une opération HTTP PUT vers l’URL que vous indiquez. Dans ce tutoriel, nous allons générer une URL HTTP PUT S3 pré-signée.
Les journaux seront renvoyés sous la forme d’une archive gzip, avec l’extension `.tar.gz`.
**Note**
Vous devez utiliser l' AWS API ou un SDK pour créer l'URL de téléchargement S3 pré-signée afin qu'EKS télécharge le fichier journal. Vous ne pouvez pas créer d'URL de téléchargement S3 pré-signée à l'aide de la AWS CLI.
1. Déterminez où vous souhaitez stocker les journaux dans le compartiment. Par exemple, vous pouvez utiliser *2024-11-12/logs1.tar.gz* comme clé.
1. Enregistrez le code Python suivant dans le fichier *presign-upload.py*. Remplacez ** et **. La clé doit se terminer par `.tar.gz`.
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. Exécutez le script avec
```
python presign-upload.py
```
1. Notez le résultat de l’URL. Utilisez cette valeur à l’étape suivante comme *http-put-destination*.
Pour plus d'informations, consultez [Générer une URL présignée pour télécharger un fichier](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) dans la documentation du SDK AWS Boto3 pour Python.
## Étape 3 : Création d'une NodeDiagnostic ressource
Identifiez le nom du nœud à partir duquel vous souhaitez collecter les journaux.
Créez un manifeste `NodeDiagnostic` qui utilise le nom du nœud comme nom de la ressource et fournissant une destination URL HTTP PUT.
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
Appliquez le fichier manifeste à votre cluster.
```
kubectl apply -f nodediagnostic.yaml
```
Vous pouvez vérifier l’état de la collecte en décrivant la ressource `NodeDiagnostic` :
+ Un état `Success` ou `SuccessWithErrors` indique que la tâche est terminée et que les journaux ont été téléversés vers la destination indiquée (l’état `SuccessWithErrors` indique que certains journaux peuvent être manquants)
+ Si l’état est Échec, vérifiez que l’URL de téléversement est bien formée et qu’elle n’a pas expiré.
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## Étape 4 : télécharger des journaux depuis S3
Attendez environ une minute avant d’essayer de télécharger les journaux. Utilisez ensuite la CLI S3 pour télécharger les journaux.
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## Étape 5 : Nettoyer les NodeDiagnostic ressources
+ Les ressources `NodeDiagnostic` ne sont pas supprimées automatiquement. Vous devez les supprimer manuellement après avoir récupéré les artefacts de vos journaux
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## NodeDiagnostic `node`Destination
À partir de la version `v1.6.0` de l'agent de surveillance des nœuds, il existe une option permettant de définir la destination de collecte de journaux sur`node`. L'utilisation de cette destination entraînera la collecte et la persistance temporaire des journaux sur le nœud pour une collecte ultérieure. Outre cette fonctionnalité, le GitHub référentiel de l'agent de surveillance des nœuds contient un `kubectl` plugin que vous pouvez installer pour faciliter les interactions et la collecte des journaux. Pour plus d'informations, consultez la [documentation du `kubectl ekslogs` plugin](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).
## Exemple d'utilisation
```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs
# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs
# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l =
```