Abilita la riparazione automatica dei nodi e analizza i problemi di integrità dei nodi - Amazon EKS
Agente di monitoraggio del nodoRiparazione automatica del nodoProblemi di integrità dei nodi

Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Abilita la riparazione automatica dei nodi e analizza i problemi di integrità dei nodi

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

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.

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

Nome Gravità Descrizione

ForkFailedOutOfPID

Condizione

Una chiamata fork o exec non è riuscita per via dell’esaurimento degli ID di processo o della memoria del sistema, il che può essere causato da processi zombie o dall’esaurimento della memoria fisica.

AppBlocked

Evento

L’attività è stata bloccata per un lungo periodo di tempo dalla pianificazione, in genere a causa del blocco in ingresso o in uscita.

AppCrash

Evento

Un’applicazione sul nodo si è bloccata.

ApproachingKernelPidMax

Evento

Il numero di processi si avvicina al numero massimo di PID disponibili per l’attuale impostazione kernel.pid_max, dopodiché non è possibile avviare altri processi.

ApproachingMaxOpenFiles

Evento

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

Evento

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

Evento

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.

KernelBug

Evento

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

Evento

Il numero di variabili di ambiente per questo processo è maggiore del previsto, il che potenzialmente è causato da molti servizi con enableServiceLinks impostato su vero, che possono causare problemi prestazionali.

RapidCron

Evento

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

Evento

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

Nome Gravità Descrizione

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.

IPAMDNotReady

Condizione

IPAMD non riesce a connettersi al server API.

IPAMDNotRunning

Condizione

Il processo aws-k8s-agent non è stato rilevato in esecuzione.

MissingLoopbackInterface

Condizione

L’interfaccia di loopback non è presente in questa istanza, il che causa l’interruzione dei servizi a seconda della connettività locale.

BandwidthInExceeded

Evento

I pacchetti accodati o rilasciati perché la larghezza di banda aggregata in ingresso ha superato il valore massimo per l’istanza.

BandwidthOutExceeded

Evento

I pacchetti sono stati accodati o rilasciati perché la larghezza di banda aggregata in uscita ha superato il valore massimo per l’istanza.

ConntrackExceeded

Evento

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.

IPAMDNoIPs

Evento

IPAM-D ha esaurito gli indirizzi IP.

IPAMDRepeatedlyRestart

Evento

Si sono verificati più riavvii del servizio IPAMD.

KubeProxyNotReady

Evento

Kube-proxy non è riuscito a controllare o elencare le risorse.

LinkLocalExceeded

Evento

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.

MissingDefaultRoutes

Evento

Mancano le regole di routing predefinite.

MissingIPRules, MissingIPRoutes

Evento

Nella tabella di routing mancano le regole di routing per i seguenti IP dei pod.

NetworkSysctl

Evento

Le impostazioni sysctl di rete di questo nodo sono potenzialmente errate.

PortConflict

Evento

Se un pod utilizza hostPort, può scrivere regole iptables che sostituiscono le porte già occupate dell’host, impedendo potenzialmente l’accesso al server API a kubelet.

PPSExceeded

Evento

I pacchetti sono stati accodati o rilasciati perché il PPS bidirezionale ha superato il valore massimo per l’istanza.

UnexpectedRejectRule

Evento

È stata rilevata una regola REJECT o DROP imprevista in iptables, che potrebbe bloccare il traffico previsto.

Problemi di integrità dei nodi neuronali

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

Nome Gravità Descrizione

NeuronDMAError

Condizione

Un motore DMA ha rilevato un errore irreversibile.

NeuronHBMUncorrectableError

Condizione

Un HBM ha riscontrato un errore non correggibile e ha prodotto risultati errati.

NeuronNCUncorrectableError

Condizione

È stato rilevato un errore di memoria non correggibile di Neuron Core.

NeuronSRAMUncorrectableError

Condizione

Una SRAM su chip ha rilevato un errore di parità e ha prodotto risultati errati.

Problemi di integrità dei nodi NVIDIA

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.

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

Nome Gravità Descrizione Azione di riparazione

NvidiaDoubleBitError

Condizione

Un errore a doppio bit è stato prodotto dal driver della GPU.

Replace (Sostituisci)

NvidiaNVLinkError

Condizione

Gli errori NVLink sono stati segnalati dal driver della GPU.

Replace (Sostituisci)

NvidiaXID13Error

Condizione

Vi è un’eccezione al motore grafico.

Riavvio

NvidiaXID31Error

Condizione

Si sospetta che vi siano problemi hardware.

Riavvio

NvidiaXID48Error

Condizione

Gli errori ECC a doppio bit sono segnalati dal driver.

Riavvio

NvidiaXID63Error

Condizione

Vi è un ritiro della pagina o una rimappatura delle righe.

Riavvio

NvidiaXID64Error

Condizione

Vi sono errori nel tentativo di ritirare una pagina o di eseguire una rimappatura dei nodi.

Riavvio

NvidiaXID74Error

Condizione

Vi è un problema con la connessione dalla GPU a un’altra GPU o NVSwitch tramite NVLink. Ciò può indicare un guasto hardware del collegamento stesso o può indicare un problema con il dispositivo all’estremità remota del collegamento.

Replace (Sostituisci)

NvidiaXID79Error

Condizione

Il driver della GPU ha tentato di accedere alla GPU tramite la connessione PCI Express e ha rilevato che la GPU non è accessibile.

Replace (Sostituisci)

NvidiaXID94Error

Condizione

Vi sono errori di memoria ECC.

Riavvio

NvidiaXID95Error

Condizione

Vi sono errori di memoria ECC.

Riavvio

NvidiaXID119Error

Condizione

Il GSP è scaduto per rispondere alle richieste RPC provenienti da altri bit del driver.

Replace (Sostituisci)

NvidiaXID120Error

Condizione

Il GSP ha risposto in tempo, ma con un errore.

Replace (Sostituisci)

NvidiaXID121Error

Condizione

C2C è l’interconnessione del chip. Consente la condivisione della memoria tra CPU, acceleratori e altro.

Replace (Sostituisci)

NvidiaXID140Error

Condizione

È possibile che il driver della GPU abbia rilevato errori non correggibili nella memoria della GPU, tali da interrompere la capacità del driver GPU di contrassegnare le pagine per l’offlining dinamico delle pagine o la rimappatura delle righe.

Replace (Sostituisci)

NvidiaPageRetirement

Evento

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

NvidiaXID[Code]Warning

Evento

Qualsiasi occorrenza di XID diversa da quelle definite in questo elenco determina questo evento.

Nessuno

DCGMError

Condizione

La connessione al processo host del sistema di gestione della GPU dei data center (DCGM) è stata interrotta o non è stato possibile stabilirla.

Nessuno

DCGMDiagnosticError

Condizione

Si è verificato un problema durante l’esecuzione della diagnostica attiva DCGM.

Nessuno

DCGMDiagnosticFailure

Condizione

Un caso di test della suite di test della diagnostica attiva DCGM non è riuscito.

Nessuno

Problemi di integrità del nodo di runtime

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

Nome Gravità Descrizione

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.

%sRepeatedRestart

Evento

Riavvio di qualsiasi servizio systemd sul nodo (formattato utilizzando il nome dell’unità con la maiuscola nel titolo).

ContainerRuntimeFailed

Evento

Il runtime del container non è riuscito a creare un container, probabilmente correlato a eventuali problemi segnalati se si verificano ripetutamente.

KubeletFailed

Evento

Il kubelet è entrato in uno stato di errore.

LivenessProbeFailures

Evento

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

ReadinessProbeFailures

Evento

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

ServiceFailedToStart

Evento

Impossibile avviare un’unità systemd.

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

Nome Gravità Descrizione

XFSSmallAverageClusterSize

Condizione

La dimensione media del cluster XFS è piccola, il che indica un’eccessiva frammentazione dello spazio libero che può impedire la creazione di file nonostante gli inode o lo spazio libero disponibili.

EtcHostsMountFailed

Evento

Il montaggio del kubelet generato /etc/hosts non è riuscito a causa del rimontaggio dei dati utente /var/lib/kubelet/pods durante il funzionamento del kubelet-container.

IODelays

Evento

Ritardo di ingresso o uscita rilevato in un processo, che potrebbe indicare un approvvigionamento input-output insufficiente, se eccessivo.

KubeletDiskUsageSlow

Evento

Kubelet sta segnalando un utilizzo lento del disco durante il tentativo di accedere al filesystem, il che potrebbe indicare problemi di input-output del disco insufficienti o del filesystem.