**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi
Lo stato del nodo si riferisce allo stato operativo e alla capacità di un nodo Kubernetes di eseguire efficacemente i carichi di lavoro. Un nodo integro mantiene la connettività di rete prevista, dispone di risorse di elaborazione e archiviazione sufficienti e può eseguire con successo i carichi di lavoro senza interruzioni.
*Per aiutare a mantenere i nodi integri nei cluster EKS, EKS offre l'*agente di monitoraggio dei nodi* e la riparazione automatica dei nodi.* Queste funzionalità vengono abilitate automaticamente con EKS Auto Mode Compute. È inoltre possibile utilizzare la riparazione automatica dei nodi con i gruppi di nodi gestiti da EKS e Karpenter e utilizzare l'agente di monitoraggio dei nodi EKS con qualsiasi tipo di elaborazione EKS ad eccezione di Fargate. AWS L'agente di monitoraggio dei nodi EKS e la riparazione automatica dei nodi sono più efficaci se usati insieme, ma possono anche essere usati singolarmente nei cluster EKS.
**Importante**
L’*agente di monitoraggio dei nodi* e la *riparazione automatica dei nodi* sono disponibili solo su Linux. Queste funzionalità non sono disponibili su Windows.
## Agente di monitoraggio del nodo
L'agente di monitoraggio dei nodi EKS legge i log dei nodi per rilevare problemi di salute. Analizza i log per rilevare i guasti e fornisce informazioni sullo stato di salute dei nodi. Per ogni categoria di problemi rilevati, l'agente ne applica uno dedicato `NodeCondition` ai nodi di lavoro. Per informazioni dettagliate sui problemi di integrità dei nodi rilevati dall'agente di monitoraggio dei nodi EKS, vedere[Rileva i problemi di integrità dei nodi con l'agente di monitoraggio dei nodi EKS](node-health-nma.md).
Il calcolo in modalità automatica di EKS include l'agente di monitoraggio dei nodi. Per altri tipi di elaborazione EKS, puoi aggiungere l'agente di monitoraggio dei nodi come componente aggiuntivo EKS o gestirlo con strumenti Kubernetes come Helm. Per ulteriori informazioni, consulta [Configura l'agente di monitoraggio del nodo](node-health-nma.md#node-monitoring-agent-configure).
Con l'agente di monitoraggio dei nodi EKS, le seguenti categorie di problemi di integrità dei nodi vengono evidenziate come condizioni del nodo. Nota, `Ready``DiskPressure`, e `MemoryPressure` sono condizioni standard dei nodi Kubernetes che vengono rilevate anche senza l'agente di monitoraggio dei nodi EKS.
| Condizione del nodo | Description |
| --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indica se l'hardware accelerato (GPU, Neuron) sul nodo funziona correttamente. |
| ContainerRuntimeReady | ContainerRuntimeReady indica se il runtime del contenitore (containerd, ecc.) funziona correttamente ed è in grado di eseguire contenitori. |
| DiskPressure | DiskPressure è una condizione standard di Kubernetes che indica che il nodo sta subendo una pressione sul disco (spazio su disco insufficiente o I/O elevato). |
| KernelReady | KernelReady indica se il kernel funziona correttamente senza errori critici, attacchi di panico o esaurimento delle risorse. |
| MemoryPressure | MemoryPressure è una condizione standard di Kubernetes che indica che il nodo sta subendo una pressione della memoria (memoria disponibile insufficiente). |
| NetworkingReady | NetworkingReady indica se lo stack di rete del nodo funziona correttamente (interfacce, routing, connettività). |
| StorageReady | StorageReady indica se il sottosistema di archiviazione del nodo funziona correttamente (dischi, file system, I/O). |
| Pronto | Ready è la condizione standard di Kubernetes che indica che il nodo è integro e pronto ad accettare i pod. |
## Riparazione automatica dei nodi
La riparazione automatica dei nodi EKS monitora continuamente lo stato dei nodi, reagisce ai problemi rilevati e sostituisce o riavvia i nodi quando possibile. Ciò migliora l'affidabilità del cluster con un intervento manuale minimo e aiuta a ridurre i tempi di inattività delle applicazioni.
Di per sé, la riparazione automatica dei nodi EKS reagisce alle `Ready` condizioni del kubelet, a tutti gli oggetti del nodo eliminati manualmente e alle istanze del gruppo di nodi gestite da EKS che non riescono a unirsi al cluster. Quando la riparazione automatica dei nodi EKS è abilitata con l'agente di monitoraggio dei nodi installato, la riparazione automatica dei nodi EKS reagisce a condizioni aggiuntive del nodo:`AcceleratedHardwareReady`,,, `ContainerRuntimeReady` e. `KernelReady` `NetworkingReady` `StorageReady`
La riparazione automatica dei nodi EKS non reagisce a Kubernetes `DiskPressure` standard o alle condizioni dei nodi. `MemoryPressure` `PIDPressure` Queste condizioni spesso indicano problemi relativi al comportamento dell'applicazione, alla configurazione del carico di lavoro o ai limiti delle risorse piuttosto che errori a livello di nodo, il che rende difficile determinare un'azione di riparazione predefinita appropriata. [In questi scenari, i carichi di lavoro sono soggetti al comportamento di eliminazione della pressione dei nodi Kubernetes.](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction)
Per ulteriori informazioni sulla riparazione automatica dei nodi EKS, consulta. [Ripara automaticamente i nodi nei cluster EKS](node-repair.md)
**Topics**
# Rileva i problemi di integrità dei nodi con l'agente di monitoraggio dei nodi EKS
Questo argomento descrive in dettaglio i problemi di integrità dei nodi rilevati dall'agente di monitoraggio dei nodi EKS, come tali problemi vengono rilevati sotto forma di condizioni o eventi del nodo e come configurare l'agente di monitoraggio dei nodi.
L'agente di monitoraggio dei nodi EKS può essere utilizzato con o senza la riparazione automatica dei nodi EKS. Per ulteriori informazioni sulla riparazione automatica dei nodi EKS, vedere[Ripara automaticamente i nodi nei cluster EKS](node-repair.md).
Il codice sorgente dell'agente di monitoraggio dei nodi EKS è pubblicato GitHub nel repository [aws/ eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent).
## Problemi di integrità dei nodi
Le tabelle seguenti descrivono i problemi di integrità dei nodi che possono essere rilevati dall’agente di monitoraggio dei nodi. Esistono due tipi di problemi:
+ Condizione: un problema del terminale che richiede un’azione di riparazione come la sostituzione o il riavvio dell’istanza. Quando la riparazione automatica è abilitata, Amazon EKS eseguirà un’azione di riparazione, sostituendo o riavviando il nodo. Per ulteriori informazioni, consulta [Condizioni dei nodi](learn-status-conditions.md#status-node-conditions).
+ Evento: un problema temporaneo o una configurazione non ottimale del nodo. Non sarà effettuata alcuna operazione di riparazione automatica. Per ulteriori informazioni, consulta [Eventi dei nodi](learn-status-conditions.md#status-node-events).
## AcceleratedHardware problemi di salute dei nodi
La condizione di monitoraggio riguarda `AcceleratedHardwareReady` per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”. Gli eventi e le condizioni nella tabella seguente riguardano i problemi di salute dei nodi relativi a NVIDIA e Neuron.
| Name | Gravità | Description | Azione di riparazione |
| --- | --- | --- | --- |
| DCGMDiagnosticFallimento | Condizione | Un caso di test della suite di test della diagnostica attiva DCGM non è riuscito. | Nessuno |
| DCGMError | Condizione | La connessione al processo host DCGM è stata interrotta o non è stato possibile stabilirla. | Nessuno |
| DCGMFieldErrore [Codice] | Event | DCGM ha rilevato un deterioramento della GPU tramite un identificatore di campo. | Nessuno |
| DCGMHealthCodice [Codice] | Event | Un controllo sanitario DCGM non è riuscito in modo non fatale. | Nessuno |
| DCGMHealthCodice [Codice] | Condizione | Un controllo sanitario DCGM non è riuscito in modo fatale. | Nessuno |
| Un neurone DMAError | Condizione | Un motore DMA ha rilevato un errore irreversibile. | Replace (Sostituisci) |
| Errore HBMUncorrectable neuronale | Condizione | Un HBM ha riscontrato un errore non correggibile e ha prodotto risultati errati. | Replace (Sostituisci) |
| Errore NCUncorrectable neuronale | Condizione | È stato rilevato un errore di memoria non correggibile di Neuron Core. | Replace (Sostituisci) |
| Errore SRAMUncorrectable neuronale | Condizione | Una SRAM su chip ha rilevato un errore di parità e ha prodotto risultati errati. | Replace (Sostituisci) |
| NvidiaDeviceCountMismatch | Event | Il numero di dispositivi GPUs visibili tramite NVML non è coerente con il numero di dispositivi NVIDIA sul file system. | Nessuno |
| NvidiaDoubleBitError | Condizione | Un errore a doppio bit è stato prodotto dal driver della GPU. | Replace (Sostituisci) |
| Nvidia NCCLError | Event | Si è verificato un errore di sicurezza nella libreria NVIDIA Collective Communications (). `libnccl` | Nessuno |
| Errore Nvidia NVLink | Condizione | NVLink gli errori sono stati segnalati dal driver della GPU. | Replace (Sostituisci) |
| Errore Nvidia PCIe | Event | PCIe i replay sono stati attivati per ripristinare gli errori di trasmissione. | Nessuno |
| NvidiaPageRetirement | Event | Il driver della GPU ha contrassegnato una pagina di memoria come ritirata. Ciò può verificarsi se si riscontra un singolo errore a doppio bit o due errori a singolo bit nello stesso indirizzo. | Nessuno |
| NvidiaPowerError | Event | L'utilizzo dell'energia ha GPUs superato le soglie consentite. | Nessuno |
| NvidiaThermalError | Event | Stato termico del superamento delle soglie consentite GPUs . | Nessuno |
| Errore nvidiaXID [Code] | Condizione | Si è verificato un errore critico della GPU. | Sostituisci o riavvia |
| NvidiaXID[Code]Warning | Event | Si è verificato un errore non critico della GPU. | Nessuno |
## Codici di errore NVIDIA XID
L'agente di monitoraggio dei nodi rileva gli errori NVIDIA XID dai log del kernel della GPU. Gli errori XID si dividono in due categorie:
+ **Codici XID noti**: errori critici che impostano una condizione del nodo (`AcceleratedHardwareReady=False`) e attivano la riparazione automatica quando abilitati. Il formato del codice motivo è`NvidiaXID[Code]Error`. I noti codici XID rilevati dall'agente di monitoraggio dei nodi EKS potrebbero non rappresentare l'elenco completo dei codici XID NVIDIA che richiedono azioni di riparazione.
+ **Codici XID sconosciuti**: registrati solo come eventi Kubernetes. Questi non attivano la riparazione dell'auto. Il formato del codice motivo è`NvidiaXID[Code]Warning`. Per verificare gli errori XID sconosciuti, controllate i log del kernel con. `dmesg | grep -i nvrm`
Per ulteriori informazioni sugli errori XID, consulta [Errori Xid](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) nella *Documentazione di implementazione e gestione delle GPU NVIDIA*. Per ulteriori informazioni sui singoli messaggi XID, consulta [Comprensione dei messaggi Xid](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) nella *Documentazione di implementazione e gestione delle GPU NVIDIA*.
La tabella seguente elenca i codici XID più diffusi, il loro significato e l'azione di riparazione dei nodi predefinita, se abilitata.
| Codice XID | Description | Azione di riparazione |
| --- | --- | --- |
| 13 | Eccezione del motore grafico: si è verificato un errore del motore grafico della GPU, in genere causato da problemi software o bug del driver. | Riavvio |
| 31 | Errore nella pagina di memoria della GPU: un'applicazione ha tentato di accedere alla memoria della GPU che non è mappata o accessibile. | Riavvio |
| 48 | Errore ECC a doppio bit: si è verificato un errore a doppio bit non correggibile nella memoria della GPU, che indica un potenziale degrado dell'hardware. | Riavvio |
| 63 | Evento di rimappatura della memoria GPU: il driver GPU ha rimappato una parte della memoria GPU a causa di errori rilevati. Questo problema è spesso recuperabile. | Riavviare |
| 64 | Errore di rimappatura della memoria della GPU: la GPU non è riuscita a rimappare la memoria difettosa, il che indica problemi hardware. | Riavvio |
| 74 | NVLink Errore: si è verificato un errore nell' NVLink interconnessione ad alta velocità tra. GPUs | Replace (Sostituisci) |
| 79 | La GPU è caduta dal bus: la GPU non è più accessibile tramite PCIe, il che in genere indica un guasto hardware o un problema di alimentazione. | Replace (Sostituisci) |
| 94 | Errore di memoria contenuta: si è verificato un errore di memoria ma era contenuto e non ha influito sulle altre applicazioni. | Riavvio |
| 95 | Errore di memoria non contenuta: si è verificato un errore di memoria che potrebbe aver influito su altre applicazioni o sulla memoria di sistema. | Riavvio |
| 119 | Timeout GSP RPC: la comunicazione con il processore di sistema GPU è scaduta, probabilmente a causa di problemi del firmware. | Replace (Sostituisci) |
| 120 | Errore GSP: si è verificato un errore nel processore di sistema GPU. | Replace (Sostituisci) |
| 121 | Errore C2C: si è verificato un errore nell' chip-to-chipinterconnessione (utilizzata in multi-die). GPUs | Replace (Sostituisci) |
| 140 | Errore ECC non recuperato: un errore ECC è sfuggito al contenimento e potrebbe aver danneggiato i dati. | Replace (Sostituisci) |
Per visualizzare le condizioni correnti del nodo relative allo stato della GPU, esegui il comando seguente.
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
Per visualizzare gli eventi relativi a XID sul tuo cluster, esegui uno dei seguenti comandi.
```
kubectl get events | grep -i "NvidiaXID"
```
## ContainerRuntime problemi di salute dei nodi
La condizione di monitoraggio riguarda `ContainerRuntimeReady` per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”.
| Name | Gravità | Description | Azione di riparazione |
| --- | --- | --- | --- |
| ContainerRuntimeFailed | Event | Il runtime del container non è riuscito a creare un container, probabilmente correlato a eventuali problemi segnalati se si verificano ripetutamente. | Nessuno |
| DeprecatedContainerdConfiguration | Event | Un'immagine del contenitore che utilizza il manifesto dell'immagine obsoleta versione 2, schema 1, è stata recentemente inserita nel nodo. `containerd` | Nessuno |
| KubeletFailed | Event | Il kubelet è entrato in uno stato di errore. | Nessuno |
| LivenessProbeFailures | Event | È stato rilevato un errore della sonda liveness, che potrebbe indicare problemi nel codice dell’applicazione o nei valori di timeout insufficienti se si verificano ripetutamente. | Nessuno |
| PodStuckTerminating | Condizione | Un pod è o è rimasto bloccato nella terminazione per un periodo di tempo eccessivo, il che può essere causato da errori CRI che impediscono la progressione dello stato del pod. | Replace (Sostituisci) |
| ReadinessProbeFailures | Event | È stato rilevato un errore della sonda di preparazione, che potrebbe indicare problemi nel codice dell’applicazione o nei valori di timeout insufficienti se si verificano ripetutamente. | Nessuno |
| [Nome] RepeatedRestart | Event | Un'unità systemd si riavvia frequentemente. | Nessuno |
| ServiceFailedToStart | Event | Impossibile avviare un’unità systemd. | Nessuno |
## Problemi di integrità dei nodi del kernel
La condizione di monitoraggio riguarda `KernelReady` per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”.
| Name | Gravità | Description | Azione di riparazione |
| --- | --- | --- | --- |
| AppBlocked | Event | L’attività è stata bloccata per un lungo periodo di tempo dalla pianificazione, in genere a causa del blocco in ingresso o in uscita. | Nessuno |
| AppCrash | Event | Un’applicazione sul nodo si è bloccata. | Nessuno |
| ApproachingKernelPidMax | Event | Il numero di processi si sta avvicinando al numero massimo di PIDs processi disponibili per l'`kernel.pid_max`impostazione corrente, dopo di che non è possibile avviare altri processi. | Nessuno |
| ApproachingMaxOpenFiles | Event | Il numero di file aperti è simile al numero massimo di file aperti possibili date le impostazioni correnti del kernel, dopodiché l’apertura di nuovi file avrà esito negativo. | Nessuno |
| ConntrackExceededKernel | Event | Il rilevamento delle connessioni ha superato il valore massimo per il kernel e non è stato possibile stabilire nuove connessioni, il che può causare la perdita di pacchetti. | Nessuno |
| ExcessiveZombieProcesses | Event | I processi che non possono essere recuperati completamente si accumulano in gran numero, il che indica problemi di applicazione e può portare al raggiungimento dei limiti dei processi di sistema. | Nessuno |
| ForkFailedOutOfPIDs | Condizione | Una chiamata fork o exec non è riuscita a causa dell'esaurimento del processo IDs o della memoria del sistema, che può essere causato da processi zombi o dall'esaurimento della memoria fisica. | Replace (Sostituisci) |
| KernelBug | Event | Un bug del kernel è stato rilevato e segnalato dal kernel Linux stesso, sebbene a volte ciò può essere causato da nodi con un elevato utilizzo della CPU o della memoria, con conseguente ritardo nell’elaborazione degli eventi. | Nessuno |
| LargeEnvironment | Event | Il numero di variabili di ambiente per questo processo è maggiore del previsto, potenzialmente causato da molti servizi `enableServiceLinks` impostati su true, il che può causare problemi di prestazioni. | Nessuno |
| RapidCron | Event | Un cron job è eseguito più velocemente di ogni cinque minuti su questo nodo, il che può influire sulle prestazioni se il processo consuma risorse significative. | Nessuno |
| SoftLockup | Event | La CPU si è bloccata per un periodo di tempo specificato. | Nessuno |
## Problemi di integrità dei nodi di rete
La condizione di monitoraggio riguarda `NetworkingReady` per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”.
| Name | Gravità | Description | Azione di riparazione |
| --- | --- | --- | --- |
| BandwidthInExceeded | Event | I pacchetti accodati o rilasciati perché la larghezza di banda aggregata in ingresso ha superato il valore massimo per l’istanza. | Nessuno |
| BandwidthOutExceeded | Event | I pacchetti sono stati accodati o rilasciati perché la larghezza di banda aggregata in uscita ha superato il valore massimo per l’istanza. | Nessuno |
| ConntrackExceeded | Event | Il rilevamento delle connessioni ha superato il valore massimo per l’istanza e non è stato possibile stabilire nuove connessioni, il che può determinare la perdita di pacchetti. | Nessuno |
| EFAErrorParametro | Event | Le metriche dei driver EFA mostrano che esiste un'interfaccia con la riduzione delle prestazioni. | Nessuno |
| IPAMDInconsistentStato | Event | Lo stato del checkpoint IPAMD su disco non riflette il runtime del contenitore. IPs | Nessuno |
| IPAMDNoIPs | Event | IPAMD ha esaurito gli indirizzi IP. | Nessuno |
| IPAMDNotPronto | Condizione | IPAMD non riesce a connettersi al server API. | Replace (Sostituisci) |
| IPAMDNotCorrere | Condizione | Il processo CNI di Amazon VPC non è stato trovato in esecuzione. | Replace (Sostituisci) |
| IPAMDRepeatedlyRiavvia | Event | Si sono verificati più riavvii del servizio IPAMD. | Nessuno |
| InterfaceNotRunning | Condizione | Questa interfaccia sembra non essere in esecuzione o ci sono problemi di rete. | Replace (Sostituisci) |
| InterfaceNotUp | Condizione | Questa interfaccia sembra non essere avviata o ci sono problemi di rete. | Replace (Sostituisci) |
| KubeProxyNotReady | Event | Kube-proxy non è riuscito a controllare o elencare le risorse. | Nessuno |
| LinkLocalExceeded | Event | I pacchetti sono stati accodati o rilasciati perché il PPS del traffico verso i servizi proxy locali ha superato il valore massimo per l’interfaccia di rete. | Nessuno |
| MACAddressPolicyMisconfigured | Event | La configurazione del link systemd-networkd ha un valore errato. `MACAddressPolicy` | Nessuno |
| MissingDefaultRoutes | Event | Mancano le regole di routing predefinite. | Nessuno |
| Mancante IPRoutes | Event | Mancano alcune rotte per Pod IPs. | Nessuno |
| Mancante IPRules | Event | Mancano delle regole per Pod IPs. | Nessuno |
| MissingLoopbackInterface | Condizione | L’interfaccia di loopback non è presente in questa istanza, il che causa l’interruzione dei servizi a seconda della connettività locale. | Replace (Sostituisci) |
| NetworkSysctl | Event | Le `sysctl` impostazioni di rete di questo nodo sono potenzialmente errate. | Nessuno |
| PPSExceeded | Event | I pacchetti sono stati accodati o rilasciati perché il PPS bidirezionale ha superato il valore massimo per l’istanza. | Nessuno |
| PortConflict | Event | Se un Pod utilizza HostPort, può scrivere `iptables` regole che sovrascrivono le porte già associate dell'host, impedendo potenzialmente l'accesso al server API. `kubelet` | Nessuno |
| UnexpectedRejectRule | Event | È stata rilevata una `DROP` regola `REJECT` o imprevista nel traffico `iptables` previsto che potrebbe bloccare. | Nessuno |
## Problemi di integrità dei nodi di storage
La condizione di monitoraggio riguarda `StorageReady` per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”.
| Name | Gravità | Description | Azione di riparazione |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | Event | È stato superato il numero massimo di IOPS per l'istanza. | Nessuno |
| EBSInstanceThroughputExceeded | Event | Il throughput massimo per l'istanza è stato superato. | Nessuno |
| EBSVolumeIOPSExceeded | Event | È stato superato il numero massimo di IOPS per un determinato volume EBS. | Nessuno |
| EBSVolumeThroughputExceeded | Event | È stato superato il throughput massimo per un determinato volume Amazon EBS. | Nessuno |
| EtcHostsMountFailed | Event | Il montaggio del kubelet generato `/etc/hosts` non è riuscito a causa del rimontaggio dei dati utente durante il funzionamento. `/var/lib/kubelet/pods` `kubelet-container` | Nessuno |
| IODelays | Event | Ritardo di ingresso o uscita rilevato in un processo, che potrebbe indicare un approvvigionamento input-output insufficiente, se eccessivo. | Nessuno |
| KubeletDiskUsageSlow | Event | Segnala `kubelet` un utilizzo lento del disco durante il tentativo di accesso al filesystem. Ciò potrebbe indicare problemi di input-output del disco o problemi di file system insufficienti. | Nessuno |
| XFSSmallAverageClusterSize | Event | La dimensione media del cluster XFS è piccola, il che indica un'eccessiva frammentazione dello spazio libero. Ciò può impedire la creazione di file nonostante gli inode disponibili o lo spazio libero. | Nessuno |
## Configura l'agente di monitoraggio del nodo
L'agente di monitoraggio dei nodi EKS viene distribuito come DaemonSet. Quando lo distribuisci come componente aggiuntivo EKS, puoi personalizzare l'installazione con i seguenti valori di configurazione. [Per le configurazioni predefinite, fate riferimento alla tabella Helm dell'agente di monitoraggio dei nodi EKS.](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)
| Opzione di configurazione | Description |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | Richiesta di risorse CPU per l'agente di monitoraggio. |
| `monitoringAgent.resources.requests.memory` | Richiesta di risorse di memoria per l'agente di monitoraggio. |
| `monitoringAgent.resources.limits.cpu` | Limite di risorse della CPU per l'agente di monitoraggio. |
| `monitoringAgent.resources.limits.memory` | Limite di risorse di memoria per l'agente di monitoraggio. |
| `monitoringAgent.tolerations` | Tolleranze per la pianificazione dell'agente di monitoraggio sui nodi contaminati. |
| `monitoringAgent.additionalArgs` | Argomenti aggiuntivi della riga di comando da passare all'agente di monitoraggio. |
**Nota**
È possibile configurare `hostname-override` e `verbosity` utilizzare i componenti aggiuntivi EKS o l'installazione di Helm. `monitoringAgent.additionalArgs` Al momento non è possibile personalizzare l'agente di monitoraggio del nodo `probe-address` (`8002`) o `metrics-address` (`8003`) tramite args aggiuntivi con componenti aggiuntivi EKS o l'installazione di Helm.
L'agente di monitoraggio del nodo include un componente server NVIDIA DCGM (Data Center GPU Manager) () per il monitoraggio di NVIDIA. `nv-hostengine` GPUs [Questo componente funziona solo su nodi che sono tipi di istanze GPU NVIDIA, come mostrato nel grafico Helm dell'`nodeAffinity`agente.](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) Non è possibile utilizzare un'installazione NVIDIA DCGM esistente con l'agente di monitoraggio dei nodi EKS. Se hai bisogno di questa funzionalità, fornisci un feedback sul [GitHub numero](https://github.com/aws/containers-roadmap/issues/2763) \$12763 della roadmap EKS.
Quando si implementa l'agente di monitoraggio dei nodi EKS come componente aggiuntivo EKS, è possibile personalizzare l'installazione NVIDIA DCGM con i seguenti valori di configurazione.
| Opzione di configurazione | Description |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | Richiesta di risorse CPU per l'agente DCGM. |
| `dcgmAgent.resources.requests.memory` | Richiesta di risorse di memoria per l'agente DCGM. |
| `dcgmAgent.resources.limits.cpu` | Limite di risorse CPU per l'agente DCGM. |
| `dcgmAgent.resources.limits.memory` | Limite di risorse di memoria per l'agente DCGM. |
| `dcgmAgent.tolerations` | Tolleranze per la pianificazione dell'agente DCGM sui nodi contaminati. |
È possibile utilizzare i seguenti comandi AWS CLI per ottenere informazioni utili sulle versioni e sullo schema del componente aggiuntivo EKS dell'agente di monitoraggio dei nodi EKS.
Scarica l'ultima versione del componente aggiuntivo dell'agente per la tua versione di Kubernetes. Sostituiscila `1.35` con la tua versione di Kubernetes.
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
Scarica lo schema del componente aggiuntivo dell'agente supportato nei componenti aggiuntivi EKS. Sostituiscilo `v1.5.1-eksbuild.1` con la tua versione per agenti.
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# Ripara automaticamente i nodi nei cluster EKS
Questo argomento descrive in dettaglio il comportamento di riparazione automatica dei nodi EKS e come configurarlo per soddisfare le vostre esigenze. La riparazione automatica dei nodi EKS è abilitata di default nella modalità automatica EKS e può essere utilizzata con i gruppi di nodi gestiti da EKS e Karpenter.
Le azioni di riparazione automatica dei nodi EKS predefinite sono riassunte nella tabella seguente e si applicano al comportamento di EKS Auto Mode, dei gruppi di nodi gestiti da EKS e Karpenter. Quando si utilizza EKS Auto Mode o Karpenter`Replace`, tutte le azioni di `AcceleratedHardwareReady` riparazione sono supportate e solo i gruppi di nodi gestiti da EKS sono `Reboot` supportate come azioni di riparazione.
Per un elenco dettagliato dei problemi di salute dei nodi rilevati dall'agente di monitoraggio dei nodi EKS e le relative azioni di riparazione dei nodi, vedere. [Rileva i problemi di integrità dei nodi con l'agente di monitoraggio dei nodi EKS](node-health-nma.md)
| Condizione del nodo | Description | Riparazione dopo | Azioni di riparazione |
| --- | --- | --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indica se l'hardware accelerato (GPU, Neuron) sul nodo funziona correttamente. | 10 m | Sostituisci o riavvia |
| ContainerRuntimeReady | ContainerRuntimeReady indica se il runtime del contenitore (containerd, ecc.) funziona correttamente ed è in grado di eseguire contenitori. | 30 m | Replace (Sostituisci) |
| DiskPressure | DiskPressure è una condizione standard di Kubernetes che indica che il nodo sta subendo una pressione sul disco (spazio su disco insufficiente o I/O elevato). | N/D | Nessuno |
| KernelReady | KernelReady indica se il kernel funziona correttamente senza errori critici, attacchi di panico o esaurimento delle risorse. | 30 m | Replace (Sostituisci) |
| MemoryPressure | MemoryPressure è una condizione standard di Kubernetes che indica che il nodo sta subendo una pressione della memoria (memoria disponibile insufficiente). | N/D | Nessuno |
| NetworkingReady | NetworkingReady indica se lo stack di rete del nodo funziona correttamente (interfacce, routing, connettività). | 30 m | Replace (Sostituisci) |
| StorageReady | StorageReady indica se il sottosistema di archiviazione del nodo funziona correttamente (dischi, file system, I/O). | 30 m | Replace (Sostituisci) |
| Pronto | Ready è la condizione standard di Kubernetes che indica che il nodo è integro e pronto ad accettare i pod. | 30 m | Replace (Sostituisci) |
Le azioni di riparazione automatica dei nodi EKS sono disabilitate per impostazione predefinita nei seguenti scenari. Le azioni di riparazione dei nodi in corso continuano in ogni scenario. Scopri [Configura la riparazione automatica dei nodi](#configure-node-repair) come sovrascrivere queste impostazioni predefinite.
**Gruppi di nodi gestiti da EKS**
+ Il gruppo di nodi ha più di cinque nodi e più del 20% dei nodi del gruppo di nodi non è integro.
+ Lo spostamento zonale del cluster viene attivato tramite l'Application Recovery Controller (ARC).
**EKS Auto Mode e Karpenter**
+ Oltre il 20% dei nodi presenti non NodePool sono sani.
+ In modalità standalone NodeClaims, il 20% dei nodi del cluster non è integro.
## Configura la riparazione automatica dei nodi
La riparazione automatica dei nodi non può essere configurata quando si utilizza la modalità automatica EKS ed è sempre abilitata con le stesse impostazioni predefinite di Karpenter.
### Karpenter
Per utilizzare la riparazione automatica dei nodi con Karpenter, abilita il feature gate. `NodeRepair=true` È possibile abilitare i feature gate tramite l'opzione `--feature-gates` CLI o la variabile di `FEATURE_GATES` ambiente nella distribuzione di Karpenter. Per ulteriori informazioni, consulta la [documentazione di Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair).
### Gruppi di nodi gestiti
È possibile abilitare la riparazione automatica dei nodi durante la creazione di nuovi gruppi di nodi gestiti EKS o aggiornando i gruppi di nodi gestiti EKS esistenti.
+ **Console Amazon EKS**: seleziona la casella di controllo **Abilita riparazione automatica del nodo** per il gruppo di nodi gestito. Per ulteriori informazioni, consulta [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).
+ ** AWS CLI**: aggiungi `--node-repair-config enabled=true` al comando [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)or [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).
+ **eksctl** [— Configure`managedNodeGroups.nodeRepairConfig.enabled: true`, vedi l'esempio in eksctl. GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml)
Quando si utilizzano i gruppi di nodi gestiti da EKS, è possibile controllare il comportamento di riparazione automatica dei nodi con le seguenti impostazioni.
Per controllare quando la riparazione automatica del nodo smette di agire, imposta una soglia basata sul numero di nodi non integri nel gruppo di nodi. Imposta il conteggio assoluto o la percentuale, ma non entrambi.
| Impostazione | Description |
| --- | --- |
| `maxUnhealthyNodeThresholdCount` | Il numero assoluto di nodi non integri al di sopra dei quali si interrompe la riparazione automatica del nodo. Utilizzatelo per limitare l'ambito delle riparazioni. |
| `maxUnhealthyNodeThresholdPercentage` | La percentuale di nodi non integri al di sopra della quale si interrompe la riparazione automatica del nodo (0-100). |
Per controllare quanti nodi vengono riparati contemporaneamente, puoi configurare il parallelismo di riparazione. Come per la soglia dei nodi non integri, imposta il conteggio assoluto o la percentuale, ma non entrambi.
| Impostazione | Description |
| --- | --- |
| `maxParallelNodesRepairedCount` | Il numero massimo di nodi da riparare contemporaneamente. |
| `maxParallelNodesRepairedPercentage` | La percentuale massima di nodi non integri da riparare contemporaneamente (0-100). |
Con`nodeRepairConfigOverrides`, è possibile personalizzare il comportamento di riparazione per condizioni specifiche. Utilizzalo quando hai bisogno di diverse azioni di riparazione o tempi di attesa per diversi tipi di problemi.
Ogni override richiede tutti i seguenti campi:
| Campo | Description |
| --- | --- |
| `nodeMonitoringCondition` | Il tipo di condizione del nodo riportato dall'agente di monitoraggio del nodo. Ad esempio:`AcceleratedHardwareReady`,`NetworkingReady`,`StorageReady`,`KernelReady`. |
| `nodeUnhealthyReason` | Il codice causale specifico della condizione non salutare. Ad esempio, `NvidiaXID31Error`, `IPAMDNotRunning`. |
| `minRepairWaitTimeMins` | Il tempo minimo, in minuti, in cui la condizione deve persistere prima che il nodo diventi idoneo alla riparazione. Usalo per evitare di riparare i nodi per problemi temporanei. |
| `repairAction` | L'azione da intraprendere quando le condizioni sono soddisfatte. Valori validi: `Replace` (terminare e sostituire il nodo), `Reboot` (riavviare il nodo) o `NoAction` (nessuna azione di riparazione). |
L'esempio AWS CLI seguente crea un gruppo di nodi con impostazioni di riparazione personalizzate.
```
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"
}
]
}'
```
Questa configurazione esegue le seguenti operazioni:
+ Abilita la riparazione automatica del nodo
+ Interrompe le azioni di riparazione quando più del 10% dei nodi non è integro
+ Ripara fino a 3 nodi alla volta
+ Sostituisce gli errori XID 64 (errore di rimappatura della memoria GPU) per sostituire il nodo dopo 5 minuti. L'impostazione predefinita è il riavvio dopo 10 minuti.
+ Sostituisce gli errori XID 31 (errore della pagina di memoria della GPU) per non intraprendere alcuna azione. L'impostazione predefinita è il riavvio dopo 10 minuti.
# Visualizzazione dello stato di integrità dei nodi
Questo argomento spiega gli strumenti e i metodi disponibili per monitorare lo stato di integrità dei nodi nei cluster Amazon EKS. Le informazioni riguardano le condizioni dei nodi, gli eventi e i casi di rilevamento che aiutano a identificare e diagnosticare problemi a livello di nodo. Utilizza i comandi e gli schemi descritti qui per ispezionare le risorse dello stato dei nodi, interpretare le condizioni dello stato e analizzare gli eventi dei nodi per la risoluzione dei problemi operativi.
Puoi ottenere alcune informazioni sullo stato dei nodi con i comandi Kubernetes per tutti i nodi. E se utilizzi l’agente di monitoraggio dei nodi tramite la modalità automatica di Amazon EKS o il componente aggiuntivo gestito Amazon EKS, otterrai una più ampia varietà di segnali di nodo per aiutarti a risolvere i problemi. Le descrizioni dei problemi di integrità rilevati dall’agente di monitoraggio dei nodi sono disponibili anche nella dashboard di osservabilità. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi con l'agente di monitoraggio dei nodi EKS](node-health-nma.md).
## Condizioni dei nodi
Le condizioni dei nodi rappresentano problemi terminali che richiedono azioni di riparazione come la sostituzione o il riavvio dell’istanza.
**Per ottenere le condizioni per tutti i nodi:**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**Per ottenere condizioni dettagliate per un nodo specifico**
```
kubectl describe node node-name
```
**Esempio di output delle condizioni di un nodo integro:**
```
- 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
```
**Esempio di condizione di un nodo non integro con un problema di rete:**
```
- 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
```
## Eventi dei nodi
Gli eventi dei nodi indicano problemi temporanei o configurazioni non ottimali.
**Per ottenere tutti gli eventi segnalati dall’agente di monitoraggio dei nodi**
Quando l’agente di monitoraggio dei nodi è disponibile, puoi eseguire il comando seguente.
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
Output di esempio:
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**Per ottenere eventi per tutti i nodi**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**Per ottenere eventi per un nodo specifico**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**Per osservare gli eventi in tempo reale**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**Esempio di output di un evento:**
```
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
```
## Comandi per la risoluzione dei problemi comuni
```
# 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
```
# Recuperare i log dei nodi per un nodo gestito usando kubectl e S3
Scopri come recuperare i log dei nodi per un nodo gestito di Amazon EKS che dispone dell’agente di monitoraggio dei nodi.
## Prerequisiti
Verifica di disporre di quanto segue:
+ Un cluster Amazon EKS esistente con agente di monitoraggio dei nodi. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).
+ Lo strumento di riga di comando `kubectl` installato e configurato per comunicare con il cluster.
+ La AWS CLI è stata installata e ha effettuato l'accesso con autorizzazioni sufficienti per creare bucket e oggetti S3.
+ Una versione recente di Python 3 installata
+ L' AWS SDK per Python 3, Boto 3, è installato.
## Fase 1: Creare di una destinazione bucket S3 (facoltativo)
Se non disponi già di un bucket S3 in cui archiviare i log, creane uno. Usa il seguente comando AWS CLI. Per impostazione predefinita, il bucket è l’elenco di controllo degli accessi `private`. Sostituisci *bucket-name* con il nome univoco del bucket scelto.
```
aws s3api create-bucket --bucket
```
## Fase 2: Creare un URL S3 prefirmato per HTTP Put
Amazon EKS restituisce i log dei nodi eseguendo un’operazione HTTP PUT su un URL specificato. In questo tutorial, genereremo un URL PUT HTTP S3 prefirmato.
I log verranno restituiti come gzip tarball, con l’estensione `.tar.gz`.
**Nota**
È necessario utilizzare l' AWS API o un SDK per creare l'URL di caricamento S3 prefirmato per consentire a EKS di caricare il file di registro. Non puoi creare un URL di caricamento S3 prefirmato utilizzando la CLI AWS .
1. Determina in che punto del bucket desideri archiviare i log. Ad esempio, puoi usare *2024-11-12/logs1.tar.gz* come chiave.
1. Salva il seguente codice Python sul file *presign-upload.py*. Sostituisci ** e **. La chiave deve terminare con `.tar.gz`.
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. Esegui lo script con
```
python presign-upload.py
```
1. Annota l’output dell’URL. Usa questo valore nella fase successiva come *http-put-destination*.
Per ulteriori informazioni, consulta [Generare un URL predefinito per caricare un file nella documentazione](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) AWS Boto3 SDK per Python.
## Fase 3: Creare una risorsa NodeDiagnostic
Identifica il nome del nodo da cui si desidera raccogliere i log.
Crea un manifesto `NodeDiagnostic` che utilizzi il nome del nodo come nome della risorsa e fornire una destinazione URL PUT HTTP.
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
Applica il file manifesto al cluster.
```
kubectl apply -f nodediagnostic.yaml
```
Puoi controllare lo stato della raccolta descrivendo la risorsa `NodeDiagnostic`:
+ Uno stato di `Success` o `SuccessWithErrors` indica che l’attività è stata completata e i log sono stati caricati nella destinazione fornita (`SuccessWithErrors` indica che alcuni log potrebbero mancare).
+ Se lo stato è Failure, conferma che l’URL di caricamento è ben formato e non è scaduto.
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## Fase 4: Scaricare log da S3
Attendi circa un minuto prima di tentare di scaricare i log. Quindi, usa la CLI di S3 per scaricare i log.
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## Fase 5: Pulizia della NodeDiagnostic risorsa
+ Le risorse `NodeDiagnostic` non vengono eliminate automaticamente. Devi eliminarle in autonomia dopo aver ottenuto gli artefatti del log.
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## NodeDiagnostic `node`Destinazione
A partire dalla versione `v1.6.0` di Node Monitoring Agent, è disponibile un'opzione su cui impostare la destinazione della raccolta dei log`node`. L'utilizzo di questa destinazione porterà alla raccolta e alla persistenza temporanea dei log sul nodo per la raccolta successiva. Oltre a questa funzionalità, all'interno del GitHub repository di Node Monitoring Agent è presente un `kubectl` plug-in che è possibile installare per facilitare l'interazione e la raccolta dei log. Per ulteriori informazioni, consulta [la documentazione del `kubectl ekslogs` plugin](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).
## Esempio di utilizzo
```
# 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 =
```