Come posso risolvere i problemi del mio nodo worker Amazon EKS che passa allo stato NotReady a causa di problemi PLEG?

Risoluzione

Quando i nodi worker del cluster Amazon EKS passano allo stato NotReady o Unknown, i carichi di lavoro pianificati su quel nodo vengono interrotti. Per risolvere il problema, procedi come segue:

Ottieni informazioni sul nodo worker eseguendo il comando riportato:

$ kubectl describe node node-name

Nell'output, controlla la sezione Conditions (Condizioni) per individuare la causa del problema.

Esempio:

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

I motivi più comuni per cui il PLEG non è integro sono i seguenti:

• Kubelet non può comunicare con il daemon Docker perché il daemon è occupato o morto. Ad esempio, il daemon Docker sul nodo worker EKS potrebbe essere danneggiato.
• Un problema di esaurimento della memoria (OOM) o di utilizzo della CPU a livello di istanza ha causato la mancata integrità del PLEG.
• Se il nodo worker ha un numero elevato di pod, i daemon kubelet e Docker potrebbero subire carichi di lavoro più elevati, causando errori relativi al PLEG. Potrebbero verificarsi carichi di lavoro più elevati anche se l'attività o la prontezza vengono verificate frequentemente.

Controllo dei log kubelet

Puoi controllare i log kubelet sull'istanza per identificare il motivo per cui il PLEG non è integro.

1.    Usa SSH per connetterti all'istanza ed esegui il comando riportato:

$ journalctl -u kubelet > kubelet.log

Se utilizzi l'AMI ottimizzata per Amazon EKS e SSH non è abilitato, puoi connetterti tramite SSM. Per ulteriori informazioni, consulta Connessione all'istanza Linux tramite Session Manager.

2.    Controlla gli eventi relativi a PLEG pubblicati da kubelet in questi log:

Esempio:

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    Controlla i log kubelet per verificare se sono presenti pod che non superano le verifiche di attività e prontezza. Questi messaggi di log hanno un aspetto simile ai seguenti:

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Usa questi log per identificare i pod che non funzionano. Per i pod identificati, controlla e assicurati che le verifiche siano configurate correttamente.

Monitoraggio dell'utilizzo delle risorse del nodo worker

Controlla se ci sono problemi a livello di istanza, ad esempio un esaurimento delle risorse dovuto a problemi di mancanza di memoria o all'elevato utilizzo della CPU.

Monitora il parametro di utilizzo della CPU per il nodo worker Amazon Elastic Compute Cloud (Amazon EC2) sottostante. Controlla questo parametro per vedere se si verificano picchi improvvisi o se l'utilizzo della CPU raggiunge il 100%.

Kubelet segnala che il nodo è sotto pressione quando raggiunge soglie di espulsione rigide o flessibili, indipendentemente dai periodi di tolleranza configurati. È possibile verificare le condizioni del nodo emettendo il seguente comando:

$ kubectl describe node <node_name>

Controlla se la condizione del nodo è indicata come MemoryPressure nell'output. In questi casi, l'istanza potrebbe bloccarsi a causa dell'indisponibilità delle risorse. Ciò potrebbe far sì che il processo non risponda.

Per mitigare i problemi dovuti alla mancanza di risorse, è consigliabile impostare limiti di utilizzo della CPU e della memoria per i pod.

Quando specifichi un limite di risorse per il tuo container, kubelet applica questi limiti. L'uso del container in esecuzione non può superare questi limiti. Ciò impedisce al pod di occupare più memoria del necessario, evitando così problemi di OOM. Per ulteriori informazioni, consulta Gestione delle risorse per pod e container sul sito Web di Kubernetes.

Inoltre, prendi in considerazione l'utilizzo di Container Insights per raccogliere, aggregare e riepilogare parametri e log dalle tue applicazioni e microservizi containerizzati. Per ulteriori informazioni, consulta Parametri di Amazon EKS e Kubernetes Container Insights. Per monitorare l'utilizzo delle risorse a livello di nodo, è possibile utilizzare node_cpu_utilization e node_memory_utilization. Puoi anche impostare allarmi per ricevere una notifica quando viene raggiunta una determinata soglia.

Monitoraggio delle prestazioni del volume Amazon EBS principale

PLEG potrebbe non essere integro a causa di problemi con il disco nel volume Amazon Elastic Block Store (Amazon EBS). In questo caso, i log kubelet hanno un aspetto simile ai seguenti:

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

Ciò accade quando le applicazioni che utilizzano i pod sull'istanza eseguono operazioni di I/O intensive sul disco.

Puoi monitorare l'utilizzo degli IOPS e la velocità di trasmissione effettiva del volume Amazon EBS utilizzando i parametri di Amazon CloudWatch per Amazon EBS.

Utilizza i seguenti parametri CloudWatch per monitorare la velocità di trasmissione effettiva e gli IOPS di un volume Amazon EBS:

• VolumeReadOps
• VolumeWriteOps
• VolumeReadBytes

Ad esempio, puoi calcolare l'IOPS medio in ops/s utilizzando la seguente formula:

((VolumeReadOps) + (VolumeWriteOps))/(periodo)

È possibile calcolare la velocità di trasmissione effettiva media in byte/s utilizzando la seguente formula:

((VolumeReadBytes) + (VolumeWriteBytes))/(periodo)

Per ulteriori informazioni, consulta Come posso usare i parametri di CloudWatch per calcolare la velocità di trasmissione effettiva media e il numero medio di IOPS forniti dal volume EBS?

Per risolvere questo problema, prendi in considerazione l'aumento delle dimensioni del disco o la modifica del tipo di volume EBS per ottenere una migliore velocità di trasmissione effettiva di I/O.

---