In che modo è possibile risolvere i problemi più comuni relativi agli errori di aggiornamento dei gruppi di nodi Amazon EKS?

Breve descrizione

Quando avvii l'aggiornamento di un gruppo di nodi gestiti, Amazon EKS aggiorna automaticamente i tuoi nodi. 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.

Durante questo processo di aggiornamento potresti visualizzare uno dei seguenti errori. Segui i passaggi di risoluzione pertinenti per l'errore riscontrato. Per ulteriori informazioni sugli errori di aggiornamento, consulta la sezione Comportamento dell'aggiornamento del nodo gestito.

Risoluzione

L'aggiornamento non è riuscito a causa dell'errore PodEvictionFailure

L'errore seguente indica che un PodEvictionFailure sta bloccando l'aggiornamento:

"Messaggio di errore: Hai raggiunto il numero massimo di tentativi durante il tentativo di rimuovere i pod dai nodi nel gruppo di nodi".

Se i pod non lasciano il nodo entro 15 minuti e non è presente alcun flag per forzare l'operazione, la fase di aggiornamento fallisce con un errore PodEvictionFailure.

Un errore PodEvictionFailure potrebbe verificarsi per uno dei seguenti motivi:

PDB (budget di interruzione dei pod) aggressivo

Quando ci sono più PDB che puntano allo stesso pod, quest'ultimo si definisce PDB aggressivo.

PDB indica il numero di interruzioni che una classe di pod può tollerare in un determinato momento (o un "budget di errori"). Quando un'interruzione volontaria fa sì che i pod di un servizio scendano al di sotto del budget, l'operazione viene sospesa fino a quando non riesce a mantenere il budget. L'evento di drenaggio dei nodi si interrompe temporaneamente fino a quando non diventano disponibili altri pod. In questo modo avrai la certezza di non superare il budget rimuovendo i pod. Per ulteriori informazioni, consulta la sezione Disruptions sul sito Web di Kubernetes.

Per confermare un aggiornamento regolare dei gruppi di nodi gestiti, rimuovi temporaneamente i budget relativi alle interruzioni dei pod o utilizza l'opzione Forza per l'aggiornamento. Questa opzione non rispetta i budget per le interruzioni dei pod. Al contrario, forza il riavvio dei nodi e quindi l'implementazione degli aggiornamenti.

Nota: se l'app è un'applicazione basata su Quorum, l'opzione Forza potrebbe rendere l'applicazione temporaneamente non disponibile.

Per confermare che i PDB sono configurati nel cluster, esegui questo comando:

$ kubectl get pdb --all-namespaces

In alternativa, se hai attivato la registrazione degli audit nella console Amazon EKS, segui questi passaggi:

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

2. Nella scheda Registrazione, scegli Audit. Questa azione ti reindirizzerà alla console Amazon CloudWatch.

3. Nella console CloudWatch scegli Log. Quindi scegli Log Insights ed esegui la query seguente:

   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. Scegli Personalizza per individuare la data dell'aggiornamento. Se si verifica un errore di aggiornamento del gruppo di nodi a causa di un PDB aggressivo, il messaggio resposeObject.message descrive il motivo dell'errore di rimozione del pod.

5. Se l'errore è stato causato dal PDB, modificalo. Esegui il comando seguente, quindi aggiorna nuovamente il gruppo di nodi:

   $ kubectl edit pdb pdb_name;

Implementazione che tollera tutti i taint

Dopo che ogni pod è stato rimosso, il nodo diventa vuoto perché era stato contaminato nei passaggi precedenti. Tuttavia, se l'implementazione tollera ogni taint, è più probabile che il nodo non sia vuoto. Ciò porta a un fallimento della rimozione dei pod. Per ulteriori informazioni, consulta la sezione Taints and tolerations sul sito Web di Kubernetes.

L'aggiornamento non è riuscito a causa di una versione di rilascio non valida

Se hai una versione di rilascio non valida, potresti ricevere il seguente errore:

"Messaggio di errore: la versione di rilascio richiesta 1.xx non è valida per la versione 1.xx di Kubernetes".

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

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

Nota: sostituisci la versione 1.xx con la versione supportata dal piano di controllo di Amazon EKS.

L'aggiornamento non è riuscito perché il gruppo di nodi presenta problemi di integrità

Se il gruppo di nodi presenta problemi di integrità, un aggiornamento non riuscito restituisce l'errore seguente:

"Messaggio di errore: Il gruppo di nodi presenta un problema di integrità diverso da [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]"

Ciò indica che il gruppo con dimensionamento automatico del gruppo di nodi non riesce a trovare la versione prevista del modello di lancio di Amazon Elastic Compute Cloud (Amazon EC2). Questo errore si verifica se modifichi o elimini manualmente la versione del modello associato al gruppo di nodi. Ciò fa sì che EKS mostri il gruppo di nodi come degradato.

Se non hai eliminato il modello di avvio, modifica manualmente la versione del modello di avvio del gruppo con dimensionamento automatico riportandola alla versione appropriata. Questa azione riporta il gruppo di nodi allo stato integro e attivo, e consente di riavviare il processo di aggiornamento.

L'aggiornamento non è riuscito perché i nuovi nodi non entrano a far parte del gruppo di nodi

Questo problema si verifica se i nuovi nodi del gruppo di nodi non possono entrare a far parte del cluster. Di conseguenza, il gruppo di nodi viene ripristinato alla versione precedente. In questo caso potresti visualizzare l'errore seguente:

"NodeCreationFailure
Impossibile procedere con il processo di aggiornamento, perché i nuovi nodi non entrano a far parte del gruppo di nodi ng-backend"

Esistono diversi motivi per cui i nodi aggiornati non possono entrare a far parte del cluster:

È stata modificata una regola del gruppo di sicurezza utilizzata dal gruppo di nodi esistente

Verifica che le regole in uscita del gruppo di sicurezza del nodo consentano la porta 443 al gruppo di sicurezza del cluster.

Il gruppo di sicurezza del cluster non consente il traffico proveniente dal gruppo di sicurezza del nodo

Verifica che le regole in entrata del gruppo di sicurezza del cluster consentano la porta 443 dal gruppo di sicurezza del nodo. Per ulteriori informazioni, consulta la sezione Considerazioni e requisiti relativi al gruppo di sicurezza Amazon EKS.

Hai creato il tuo gruppo di nodi con un modello di avvio personalizzato

Se stai aggiornando un modello di avvio personalizzato, la nuova versione del modello deve contenere i dati utente corretti. Inoltre, se utilizzi un'AMI personalizzata, assicurati di aver configurato correttamente l'AMI per entrare a far parte del cluster.

Per risolvere i problemi relativi al modello di avvio, crea un nuovo gruppo di nodi con lo stesso modello di avvio. Assicurati che il modello utilizzi la versione più recente dell'AMI personalizzata. Quindi verifica se il nodo entra correttamente a far parte del cluster. Se il nodo non si unisce al cluster, connettiti all'istanza del nodo con SSH e controlla i log di Kubelet.

Mancano le autorizzazioni IAM

Verifica se il ruolo AWS Identity and Access Management (IAM) per il gruppo di nodi dispone delle autorizzazioni necessarie.

Le ACL negano il traffico

La lista di controllo degli accessi (ACL) della sottorete di un nodo potrebbe negare il traffico in uscita per la porta 443 o il traffico in entrata per una porta effimera. Assicurati di consentire queste regole per la sottorete del nodo.

Allo stesso modo, l'ACL della sottorete di un cluster potrebbe negare il traffico in entrata per la porta 443. Assicurati di consentire questo traffico per le sottoreti del tuo cluster.

I nuovi nodi non riescono ad aggiungere un plug-in

Un plug-in CNI di Amazon Virtual Private Cloud (Amazon VPC) o un componente aggiuntivo kube-proxy potrebbe non apparire sui nuovi nodi. Per ulteriori informazioni, consulta Come posso risolvere i problemi relativi a Kubelet o ai plug-in CNI per Amazon EKS?

Una sottorete presenta problemi di connettività

La sottorete in cui Amazon EKS crea i nodi potrebbe non avere collegamento con gli endpoint necessari. Questi endpoint potrebbero includere Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) o Amazon EC2. La connettività potrebbe fallire tramite Internet o gli endpoint VPC. Per gli endpoint VPC, controlla i gruppi di sicurezza dei nodi e degli endpoint per assicurarti che consentano il traffico richiesto. Se utilizzi un gateway NAT o un gateway Internet, verifica che la regola di routing sia corretta nella tabella di routing della sottorete. Inoltre, verifica che esista il gateway NAT o il gateway Internet corrispondente.