Enable node auto repair and investigate node health issues

L’integrità del nodo si riferisce allo stato operativo e alla capacità di un nodo di eseguire efficacemente i carichi di lavoro. Un nodo integro mantiene la connettività prevista, dispone di risorse sufficienti e può eseguire correttamente i pod senza interruzioni. Per informazioni su come ottenere dettagli sui nodi, consulta Visualizzazione dello stato di integrità dei nodi e Recuperare i log dei nodi per un nodo gestito usando kubectl e S3.

Per aiutare a mantenere i nodi integri, Amazon EKS offre l’agente di monitoraggio dei nodi e la riparazione automatica dei nodi.

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 legge automaticamente i log dei nodi per rilevare determinati problemi di integrità. Analizza i log dei nodi per rilevare i guasti e mostra varie informazioni sullo stato dei nodi worker. Sui nodi worker è applicato un NodeCondition dedicato per ciascuna categoria di problemi rilevati, come problemi di archiviazione e di rete. Le descrizioni dei problemi di salute rilevati sono disponibili nella dashboard di osservabilità. Per ulteriori informazioni, consulta Problemi di integrità dei nodi.

L’agente di monitoraggio dei nodi è incluso come funzionalità per tutti i cluster in modalità automatica Amazon EKS. Per altri tipi di cluster, è possibile aggiungere l’agente di monitoraggio come componente aggiuntivo di Amazon EKS. Per ulteriori informazioni, consulta Creare un componente aggiuntivo Amazon EKS.

Riparazione automatica del nodo

La riparazione automatica dei nodi è una funzionalità aggiuntiva che monitora continuamente lo stato dei nodi, reagendo automaticamente ai problemi rilevati e sostituendo i nodi quando possibile. Ciò aiuta la disponibilità complessiva del cluster con un intervento manuale minimo. Se un controllo dell’integrità ha esito negativo, il nodo è automaticamente isolato in modo che non siano pianificati nuovi pod sul nodo.

Di per sé, la riparazione automatica dei nodi può reagire alle condizioni Ready di kubelet e di tutti gli oggetti del nodo che sono eliminati manualmente. Se abbinato all’agente di monitoraggio dei nodi, la riparazione automatica dei nodi può reagire a più condizioni che altrimenti non sarebbero rilevate. Queste condizioni aggiuntive includono KernelReady, NetworkingReady e StorageReady.

Questo recupero automatico dei nodi risolve automaticamente i problemi intermittenti dei nodi, come la mancata adesione al cluster, i kubelet che non rispondono e l’aumento degli errori dell’acceleratore (dispositivo). La maggiore affidabilità aiuta a ridurre i tempi di inattività delle applicazioni e a migliorare le operazioni del cluster. La riparazione automatica dei nodi non è in grado di gestire determinati problemi segnalati come DiskPressure, MemoryPressure e PIDPressure. Amazon EKS attende 10 minuti prima di agire su AcceleratedHardwareReady NodeConditions e 30 minuti per tutte le altre condizioni.

Inoltre, i gruppi di nodi gestiti disabiliteranno automaticamente le riparazioni dei nodi per motivi di sicurezza in due scenari. Tutte le operazioni di riparazione precedentemente in corso continueranno per entrambe le situazioni.

• Se è stato attivato uno spostamento zonale per il cluster tramite Application Recovery Controller (ARC), tutte le operazioni di riparazione successive sono interrotte.

• Se il gruppo di nodi ha più di cinque nodi e più del 20% dei nodi del gruppo di nodi non sono integri, le operazioni di riparazione sono interrotte.

È possibile abilitare la riparazione automatica dei nodi durante la creazione o la modifica di un gruppo di nodi gestito.

• Quando si utilizza la console Amazon EKS, attivare la casella di controllo Abilita riparazione automatica dei nodi per il gruppo di nodi gestito. Per ulteriori informazioni, consulta Creare un gruppo di nodi gestiti per il cluster.

• Quando si utilizza la AWS CLI, --node-repair-config enabled=true aggiungere il comando eks create nodegroupo eks update-nodegroup-config.

• Per un esempio eksctl ClusterConfig che utilizza un gruppo di nodi gestito con riparazione automatica del nodo, vedi 44-node-repair.yaml on. GitHub

Amazon EKS offre un controllo più granulare sul comportamento di riparazione automatica del nodo attraverso quanto segue:

• maxUnhealthyNodeThresholdCount e maxUnhealthyNodeThresholdPercentage

  • Questi campi consentono di specificare una soglia di conteggio o percentuale di nodi non integri, oltre la quale le azioni di riparazione automatica dei nodi saranno interrotte. Ciò fornisce un maggiore controllo sul “raggio di impatto” delle riparazioni automatiche dei nodi.

  • È possibile impostare il conteggio assoluto o la percentuale assoluta, ma non entrambi.

• maxParallelNodesRepairedCount e maxParallelNodesRepairedPercentage

  • Tali campi consentono di specificare il numero massimo di nodi che possono essere riparati contemporaneamente o in parallelo, espresso come conteggio o percentuale di tutti i nodi non integri. In questo modo è possibile controllare in modo più preciso il ritmo delle sostituzioni dei nodi.

  • Come per la soglia non integra, è possibile impostare il conteggio assoluto o la percentuale assoluta, ma non entrambi.

• nodeRepairConfigOverrides

  • Si tratta di una struttura complessa che consente di impostare sostituzioni granulari per azioni di riparazione specifiche. Tali sostituzioni controllano l’azione di riparazione e il tempo di ritardo della riparazione prima che un nodo sia considerato idoneo per la riparazione.

  • I campi specifici di tale struttura sono:

    • nodeMonitoringCondition: la condizione non integra segnalata dall’agente di monitoraggio dei nodi.

    • nodeUnhealthyReason: il motivo per cui l’agente di monitoraggio di nodi ha identificato il nodo come non integro.

    • minRepairWaitTimeMins: il tempo minimo (in minuti) in cui la condizione di riparazione e il motivo non integro devono persistere prima che il nodo sia idoneo alla riparazione.

    • repairAction: l’azione che il sistema di riparazione deve intraprendere quando sono soddisfatte le condizioni di cui sopra.

  • Se si utilizza questo campo, è necessario specificare tutti i campi della struttura. È anche possibile fornire un elenco di tali sostituzioni.

  • nodeMonitoringCondition e nodeUnhealthyReason sono input di testo manuali che si impostano per indicare che si desidera deviare dal comportamento predefinito del sistema.

  • I campi minRepairWaitTimeMins e repairAction consentono di specificare le deviazioni dal comportamento predefinito del sistema.

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.

• 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.

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”.

Se la riparazione automatica è abilitata, le azioni di riparazione elencate iniziano 10 minuti dopo il rilevamento del problema. Per ulteriori informazioni sugli errori XID, consulta Errori Xid nella Documentazione di implementazione e gestione delle GPU NVIDIA. Per ulteriori informazioni sui singoli messaggi XID, consulta Comprensione dei messaggi Xid nella Documentazione di implementazione e gestione delle GPU NVIDIA.

Name	Gravità	Description
DCGMDiagnosticFallimento	Condizione	Un caso di test della suite di test della diagnostica attiva DCGM non è riuscito.
DCGMError	Condizione	La connessione al processo host DCGM è stata interrotta o non è stato possibile stabilirla.
DCGMFieldErrore [Codice]	Event	DCGM ha rilevato una degradazione della GPU tramite un identificatore di campo.
DCGMHealthCodice [Codice]	Event	Un controllo sanitario DCGM non è riuscito in modo non fatale.
DCGMHealthCodice [Codice]	Condizione	Un controllo sanitario DCGM non è riuscito in modo fatale.
Un neurone DMAError	Condizione	Un motore DMA ha rilevato un errore irreversibile.
Errore HBMUncorrectable neuronale	Condizione	Un HBM ha riscontrato un errore non correggibile e ha prodotto risultati errati.
Errore NCUncorrectable neuronale	Condizione	È stato rilevato un errore di memoria non correggibile di Neuron Core.
Errore SRAMUncorrectable neuronale	Condizione	Una SRAM su chip ha rilevato un errore di parità e ha prodotto risultati errati.
NvidiaDeviceCountMismatch	Event	Il numero di dispositivi GPUs visibili tramite NVML non è coerente con il numero di dispositivi NVIDIA sul file system.
NvidiaDoubleBitError	Condizione	Un errore a doppio bit è stato prodotto dal driver della GPU.
Nvidia NCCLError	Event	Si è verificato un errore di sicurezza nella libreria NVIDIA Collective Communications (). libnccl
Errore Nvidia NVLink	Condizione	NVLink gli errori sono stati segnalati dal driver della GPU.
Errore Nvidia PCIe	Event	PCIe i replay sono stati attivati per ripristinare gli errori di trasmissione.
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.
NvidiaPowerError	Event	L'utilizzo dell'energia ha GPUs superato le soglie consentite.
NvidiaThermalError	Event	Stato termico del superamento delle soglie consentite GPUs .
Errore nvidiaXID [Code]	Condizione	Si è verificato un errore critico della GPU.
NvidiaXID[Code]Warning	Event	Si è verificato un errore non critico della GPU.

ContainerRuntime problemi di integrità del nodo

La condizione di monitoraggio riguarda ContainerRuntimeReady per i problemi riportati nella tabella seguente con una gravità pari a “Condizione”.

Name	Gravità	Description
ContainerRuntimeFailed	Event	Il runtime del container non è riuscito a creare un container, probabilmente correlato a eventuali problemi segnalati se si verificano ripetutamente.
DeprecatedContainerdConfiguration	Event	Un'immagine del contenitore che utilizza la versione obsoleta del manifesto di immagini 2, schema 1, è stata recentemente inserita nel nodo. containerd
KubeletFailed	Event	Il kubelet è entrato in uno stato di errore.
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.
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.
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.
[Nome] RepeatedRestart	Event	Un'unità systemd si riavvia frequentemente.
ServiceFailedToStart	Event	Impossibile avviare un’unità systemd.

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
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.
AppCrash	Event	Un’applicazione sul nodo si è bloccata.
ApproachingKernelPidMax	Event	Il numero di processi si sta avvicinando al numero massimo di PIDs processi disponibili per l'kernel.pid_maximpostazione corrente, dopo di che non è possibile avviare altri processi.
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.
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.
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.
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.
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.
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.
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.
SoftLockup	Event	La CPU si è bloccata per un periodo di tempo specificato.

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
BandwidthInExceeded	Event	I pacchetti accodati o rilasciati perché la larghezza di banda aggregata in ingresso ha superato il valore massimo per l’istanza.
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.
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.
IPAMDInconsistentStato	Event	Lo stato del checkpoint IPAMD su disco non riflette il runtime IPs del contenitore.
IPAMDNoIPs	Event	IPAMD ha esaurito gli indirizzi IP.
IPAMDNotPronto	Condizione	IPAMD non riesce a connettersi al server API.
IPAMDNotCorrere	Condizione	Il processo CNI di Amazon VPC non è stato trovato in esecuzione.
IPAMDRepeatedlyRiavvia	Event	Si sono verificati più riavvii del servizio IPAMD.
InterfaceNotRunning	Condizione	Questa interfaccia sembra non essere in esecuzione o ci sono problemi di rete.
InterfaceNotUp	Condizione	Questa interfaccia sembra non essere avviata o ci sono problemi di rete.
KubeProxyNotReady	Event	Kube-proxy non è riuscito a controllare o elencare le risorse.
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.
MACAddressPolicyMisconfigured	Event	La configurazione del link systemd-networkd ha un valore errato. MACAddressPolicy
MissingDefaultRoutes	Event	Mancano le regole di routing predefinite.
Mancante IPRoutes	Event	Mancano alcune rotte per Pod IPs.
Mancante IPRules	Event	Mancano delle regole per Pod IPs.
MissingLoopbackInterface	Condizione	L’interfaccia di loopback non è presente in questa istanza, il che causa l’interruzione dei servizi a seconda della connettività locale.
NetworkSysctl	Event	Le sysctl impostazioni di rete di questo nodo sono potenzialmente errate.
PPSExceeded	Event	I pacchetti sono stati accodati o rilasciati perché il PPS bidirezionale ha superato il valore massimo per l’istanza.
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
UnexpectedRejectRule	Event	È stata rilevata una DROP regola REJECT o imprevista nel traffico iptables previsto che potrebbe bloccare.

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
EBSInstanceIOPSExceeded	Event	È stato superato il numero massimo di IOPS per l'istanza.
EBSInstanceThroughputExceeded	Event	Il throughput massimo per l'istanza è stato superato.
EBSVolumeIOPSExceeded	Event	È stato superato il numero massimo di IOPS per un determinato volume EBS.
EBSVolumeThroughputExceeded	Event	È stato superato il throughput massimo per un determinato volume Amazon EBS.
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
IODelays	Event	Ritardo di ingresso o uscita rilevato in un processo, che potrebbe indicare un approvvigionamento input-output insufficiente, se eccessivo.
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.
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.