Come posso risolvere il problema dei nodi che non riescono a unirsi ai cluster Amazon EKS Anywhere?

Breve descrizione

Prima di intraprendere la procedura di risoluzione, verifica che la configurazione soddisfi i seguenti requisiti:

• Hai una macchina con accesso amministratore per eseguire le operazioni relative al ciclo di vita del cluster.
• La macchina con accesso amministratore, il piano di controllo (control-plane) e i nodi worker si trovano nella stessa rete di livello 2.
• La rete supporta DHCP.
  Nota: è consigliabile configurare la rete in modo da escludere indirizzi IP specifici per il piano di controllo (control-plane) e i nodi worker.
• Hai riservato indirizzi IP statici per l'endpoint del piano di controllo (control plane) e altri nodi del cluster e hai escluso gli indirizzi IP statici dall'intervallo DHCP.
• Il server dispone di almeno due vCPU, 8 GB di RAM e 25 GB di spazio di archiviazione per ogni nodo.
• L'interfaccia di rete elastica supporta un Preboot eXecution Environment (PXE).
• Hai VMware vSphere 7 o 8 e VMware vCenter Server.
• Hai la capacità di implementare 6-10 macchine virtuali (VM). Inoltre, stai eseguendo un servizio DHCP nella rete VM primaria per il cluster del carico di lavoro.
• La rete vSphere consente l'accesso a vCenter Server e hai riservato ed escluso gli indirizzi IP necessari dal DHCP.

Risoluzione

Errore di registrazione del nodo

Ricevi il seguente messaggio di errore quando non applichi la mappa di configurazione di AWS IAM Authenticator per Kubernetes (ConfigMap aws-auth) a un cluster:

"Unable to register node with API server err=Unauthorized."

Nota: la mappa di configurazione fornisce le autorizzazioni RBAC (Role-Based Access Control) system:bootstrappers e system:nodes per la registrazione dei nodi nel cluster.

Per risolvere un errore di registrazione del nodo, aggiungi il ruolo AWS Identity and Access Management (AWS IAM) alla ConfigMap aws-auth.

Errore Unauthorized

Ricevi un messaggio di errore "unauthorized" quando elimini un gruppo di nodi gestito e la voce del ruolo del nodo viene successivamente eliminata dalla ConfigMap aws-auth. Puoi identificare questo errore quando esamini le richieste API di kubelet al server API nei log di kubelet.

Per risolvere un errore Unauthorized, aggiungi nuovamente il ruolo IAM alla ConfigMap aws-auth.

Errori di dipendenza di kubelet

Errore del file CA

Ricevi il seguente messaggio di errore quando un nodo non riesce a recuperare il file dell'autorità di certificazione (CA) da un cluster o viene eseguito lo script /etc/eks/bootstrap.sh:

"Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory."

Per risolvere un errore di dipendenza di kubelet, completa i seguenti passaggi:

1. Controlla nello stream /var/log/cloud-init-output.log dei log di avvio del cloud se è presente il seguente messaggio di errore:
   "Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291"

2. Esegui il seguente comando curl -vk per verificare di poter raggiungere l'endpoint API di Amazon EKS:

   curl -vk https://eks.us-east-1.amazonaws.com/

3. Elimina l'endpoint di Amazon EKS.

Se non riesci a raggiungere l'endpoint, intraprendi le seguenti azioni:

• Per gli endpoint privati, inserisci il nodo nello stesso cloud privato virtuale (VPC) o nella stessa rete connessa. Gli endpoint privati non sono accessibili al pubblico.
• Configura i gruppi di sicurezza, le tabelle di routing e la lista di controllo degli accessi alla rete (ACL) per gli endpoint pubblici. I gruppi di sicurezza, le tabelle di routing e le ACL devono consentire tutti il traffico HTTPS (TCP 443) in uscita verso l'endpoint di Amazon EKS. Per ulteriori informazioni, consulta Considerazioni su VPC e sottorete.
• Per i nodi in sottoreti private, assicurati di disporre di un gateway NAT o di un endpoint VPC per l'accesso a Internet in uscita.
• Imposta enableDnsHostnames e enableDnsSupport su true nel VPC.
• Assicurati che il set di opzioni DHCP includa AmazonProvidedDNS.

Errori di convalida

Ricevi il seguente messaggio di errore di convalida quando Kubernetes non riesce a trovare la risorsa del piano di controllo (control-plane) "kubeadmcontrolplanes.controlplane.cluster.x-k8s.io" nel cluster del carico di lavoro:

"Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'..."

Per risolvere un errore di convalida, completa i seguenti passaggi:

1. Accedi al nodo del piano di controllo (control-plane) in cui è in esecuzione il processo kubeadm.

2. Esegui questo comando journalctl per ottenere informazioni sulla risoluzione dei problemi dai log del servizio kubelet:

   journalctl -u kubelet -f

3. Nell'output del log, identifica il componente del cluster che causa l'errore di convalida.

Errore del token di bootstrap

Un errore del token di bootstrap è causato da un bug nella versione 1.0.2 dei cluster Amazon EKS Anywhere. Per ulteriori informazioni, consulta bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster (I token di bootstrap possono scadere prima di poter essere utilizzati se l'ora del cluster di bootstrap è sufficientemente indietro rispetto a quella del cluster del carico di lavoro) sul sito web GitHub.

Per risolvere il problema, consulta Fix to enable bootstrap secret rotation if the secret itself missing (Come abilitare la rotazione del segreto di bootstrap se manca il segreto stesso) sul sito web GitHub.

Errore del segreto del token di bootstrap mancante

Quando esegui il comando eksctl anywhere upgrade cluster -f cluster.yaml, puoi ricevere un messaggio di errore. L'errore si verifica perché manca il segreto di un token di bootstrap per un bug nel flusso di lavoro. Il bug blocca i nuovi nodi che tentano di unirsi al cluster.

Per risolvere il problema, completa i seguenti passaggi:

1. Elimina manualmente la nuova macchina a cui è stato assegnato il provisioning per aggiornare il token di bootstrap.
2. Quando il cluster è integro, esegui il backup della Cluster API (CAPI) di Kubernetes e sposta i componenti della CAPI nel cluster di gestione. Per istruzioni, consulta Cluster upgrade fails with management components on bootstrap cluster (L'aggiornamento del cluster non riesce con i componenti di gestione nel cluster di bootstrap).

Errori interni

Quando il servizio di convalida del webhook presenta problemi di connettività, ricevi il seguente messaggio di errore interno:

"Error from server (InternalError): Internal error occurred: failed calling webhook..."

Per risolvere un errore interno, procedi nel seguente modo:

1. Esegui questo comando kubectl get pods per individuare il pod eks-controller-manager:

   kubectl get pods -n kube-system | grep eks-controller-manager

2. Esegui questo comando kubectl logs per visualizzare i log del pod:

   kubectl logs eksa-controller-manager-pod-name -n kube-system

   Nota: sostituisci eksa-controller-manager-pod-name con il nome del tuo pod eksa-controller-manager.

3. Utilizza le informazioni contenute nell'output del log per risolvere il problema.

Quando scade il processo di elezione del leader nel piano di controllo (control-plane) di Kubernetes, ricevi il seguente messaggio di errore interno:

"Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}..."

Puoi inoltre ricevere questo messaggio di errore quando il processo di elezione del leader non riesce a rinnovare il contratto di locazione a causa di un blocco delle risorse in etcd.

Le cause principali dell'errore includono ritardi di rete, indisponibilità di etcd o problemi di conflitto relativi alle risorse.

Per risolvere il, elimina il pod eksa-controller-manager. Un pod sostitutivo si avvia e passa allo stato In esecuzione.

Nota: gli errori interni possono verificarsi nelle versioni 1.21 o precedenti dei cluster Amazon EKS Anywhere. Per evitare questo tipo di errore, è consigliabile aggiornare il cluster alla versione più recente di Kubernetes.

Errore del PLEG

Quando il generatore di eventi del ciclo di vita dei pod (Pod Lifecycle Event Generator, PLEG) presenta un problema, ricevi il seguente messaggio di errore:

"PLEG is not healthy: pleg was last seen active."

Per risolvere il problema, intraprendi le seguenti azioni:

• Verifica e risolvi la latenza o i timeout di runtime del container, ad esempio peggioramento delle prestazioni, deadlock o bug, che si verificano durante le richieste remote.
• Evita troppi pod in esecuzione per le risorse host o troppi pod in esecuzione su host con specifiche elevate.
• Risolvi i problemi relativi alle risorse nel nodo.

Per ulteriori informazioni sul generatore di eventi del ciclo di vita dei pod, consulta Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes (Generatore di eventi del ciclo di vita dei pod: cause dell'errore "PLEG is not healthy" in Kubernetes) sul sito web Red Hat Developer.

Errore NotReady, SchedulingDisabled

Quando uno dei nodi del cluster Amazon EKS Anywhere è nello stato NotReady,SchedulingDisabled, si verifica un errore. Questo perché la macchina fisica su cui era in esecuzione la macchina virtuale vSphere non esiste più. Il cluster si blocca nella fase di dimensionamento e i nuovi nodi non riescono ad avviarsi.

Per risolvere un errore di stato NotReady, SchedulingDisabled, completa i seguenti passaggi:

1. Rimuovi il finalizzatore della macchina.
2. Esegui questo comando kubectl delete node per eliminare il nodo di Amazon EKS in sospeso e avviare un nuovo nodo:

   kubectl delete node your_node_name

   Nota: sostituisci your_node_name con il nome del nodo che desideri eliminare.

Informazioni correlate

What is EKS Anywhere? (Cos'è EKS Anywhere?)

Rete runtime container non pronta