Come posso risolvere i problemi più comuni relativi agli errori di aggiornamento del gruppo di nodi Amazon EKS?

Breve descrizione

Le versioni più recenti di Amazon EKS includono anche le nuove versioni delle AMI Amazon per gli aggiornamenti del gruppo di nodi. I clienti con un carico di lavoro implementato su più gruppi di nodi devono affrontare la sfida di aggiornarli per restare al passo con il ciclo di rilascio.

Quando avvii un aggiornamento del gruppo di nodi gestito, Amazon EKS li aggiorna automaticamente per te. Se utilizzi un'AMI ottimizzata per Amazon EKS, quest'ultimo applica automaticamente le patch di sicurezza e gli aggiornamenti del sistema operativo più recenti ai tuoi nodi come parte dell'ultima versione di rilascio dell'AMI. Per implementare l'aggiornamento, il Dimensionamento automatico AWS avvia i nodi in ogni zona di disponibilità in cui questi ultimi sono presenti all'interno del gruppo di nodi. Questo servizio riequilibra anche la zona di disponibilità. La fase di avvio ha esito positivo poiché i nodi esistenti vengono svuotati una sola volta. La fase di dimensionamento riduce la dimensione massima del gruppo con scalabilità automatica e la dimensione desiderata di una unità per tornare ai valori antecedenti all'aggiornamento. Per ulteriori informazioni, consulta "Fase di dimensionamento" in Comportamento dell'aggiornamento del nodo gestito.

Risoluzione

Durante il processo di aggiornamento, potresti riscontrare alcuni dei seguenti errori che richiedono operazioni di mitigazione specifiche. Conoscere questi problemi in anticipo consente di ridurre al minimo i tempi di inattività. Consulta Comportamento dell'aggiornamento del nodo gestito per ulteriori informazioni sugli errori di aggiornamento.

Aggiornamento non riuscito a causa dell'errore PodEvictionFailure

Error message : Reached max retries while trying to evict pods from nodes in node group.

Questo errore indica che l'aggiornamento è bloccato da PodEvictionFailure. Se i pod non escono dal nodo entro 15 minuti e non è presente alcun contrassegno per forzare il processo, la fase di aggiornamento non va a buon fine e viene generato un errore PodEvictionFailure.

I motivi dell'errore PodEvictionFailure nella fase di aggiornamento sono i seguenti:

Budget di interruzione dei pod (PDB) aggressivo

Il PDB aggressivo è definito sul pod quando sono presenti più PDB che puntano allo stesso pod.

Il PDB indica il numero di interruzioni che possono essere tollerate in un dato momento per una classe di pod (un budget di errori). Ogni volta che un'interruzione volontaria fa scendere i pod di un servizio al di sotto del budget, l'operazione va in pausa finché non riesce a mantenere il budget. L'evento di svuotamento dei nodi si arresta temporaneamente finché non diventano disponibili altri pod, in modo che il budget non venga superato espellendo i pod. Per ulteriori informazioni, consulta Disruptions (Interruzioni) sul sito Web di Kubernetes.

Per confermare un aggiornamento regolare del gruppo di nodi gestito, devi rimuovere temporaneamente i budget relativi alle interruzioni dei pod o utilizzare l'opzione per forzare l'aggiornamento. Questa opzione non rispetta i budget di interruzione dei pod. Questa opzione implementa invece gli aggiornamenti forzando il riavvio dei nodi.

Nota: se l'app è basata su Quorum, l'opzione per forzare il processo può rendere l'applicazione temporaneamente non disponibile.

Esegui il comando seguente per confermare che i PDB sono configurati nel tuo cluster:

$ kubectl get pdb --all-namespaces

Oppure, se hai attivato la registrazione di log dell'audit nella console Amazon EKS, segui questi passaggi:

1.    Nella scheda Clusters (Cluster), scegli il cluster desiderato (ad esempio, rpam-eks-qa2-control-plane) dall'elenco.

2.    Nella scheda Logging (Registrazione di log), scegli Audit. Questa opzione ti reindirizza alla console Amazon CloudWatch.

3.    Nella console CloudWatch, scegli Logs (Log). Quindi, scegli Log Insights (Approfondimenti sui file di log) ed esegui la seguente query:

fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter ispresent(requestURI)
| filter objectRef.subresource = "eviction" 
| display @logStream, requestURI, responseObject.message
| stats count(*) as retry by requestURI, responseObject.message

4.    Seleziona Custom (Personalizzato) in alto a destra per verificare la data dell'aggiornamento. Se si verifica un errore di aggiornamento del gruppo di nodi a causa di un PDB aggressivo, responseObject.message descrive il motivo dell'errore nell'espulsione del pod.

5.    Se il PDB ha causato l'errore, modificalo utilizzando il seguente comando. Quindi, aggiorna nuovamente il gruppo di nodi:

$ kubectl edit pdb pdb_name;

Implementazione che tollera tutti i taint

Dopo che ogni pod è stato espulso, il nodo si svuota perché gli è stato applicato un taint nei passaggi precedenti. Tuttavia, se l'implementazione tollera ogni taint è più probabile che il nodo non sia vuoto, con conseguente errore nell'espulsione del pod. Per ulteriori informazioni, consulta Taints and tolerations (Taint e tolleranze) sul sito Web di Kubernetes.

Aggiornamento non riuscito a causa di una versione di rilascio non valida

Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.

Per risolvere questo problema, esegui nuovamente il comando di aggiornamento. Questo comando aggiorna i gruppi di nodi alla stessa versione Kubernetes del piano di controllo (control-plane):

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

Nota: sostituisci la versione 1.xx con quella supportata dal piano di controllo (control-plane) Amazon EKS.

Aggiornamento non riuscito perché il gruppo di nodi presenta problemi di integrità

Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]

Questo errore si verifica se hai modificato manualmente il gruppo con scalabilità automatica del gruppo di nodi per utilizzare una versione diversa del relativo modello di avvio di Amazon Elastic Compute Cloud (Amazon EC2). Oppure, potresti aver eliminato la versione del modello associata al gruppo di nodi. Il gruppo di nodi EKS utilizza un modello di avvio predefinito che è in conflitto con quello del gruppo con scalabilità automatica. Questo modello di avvio fa sì che EKS mostri il gruppo di nodi come degradato.

Se non hai ancora eliminato il modello di avvio, ripristina manualmente la versione di tale modello del gruppo con scalabilità automatica alla versione appropriata. Questa operazione rende lo stato del gruppo di nodi integro e attivo. Ora puoi riavviare il processo di aggiornamento.

---