Come posso risolvere gli errori di creazione di gruppi di nodi gestiti da Amazon EKS?

Ultimo aggiornamento: 03/06/2022

La creazione del gruppo di nodi gestito dal Servizio di Kubernetes elastico Amazon (Amazon EKS) non è riuscita. I nodi non possono unirsi al cluster e ho ricevuto un errore simile al seguente:

"Instances failed to join the kubernetes cluster" ("Le istanze non sono riuscite a unirsi al cluster kubernetes").

Breve descrizione

Per risolvere gli errori di creazione dei gruppi di nodi gestiti da Amazon EKS, segui questi passaggi:

  • Usa il runbook di automazione AWS Systems Manager per identificare i problemi più comuni.
  • Verifica i requisiti di traffico del gruppo di sicurezza dei nodi worker.
  • Verifica le autorizzazioni Identity and Access Management (IAM) del nodo worker.
  • Verifica che il Cloud privato virtuale Amazon (Amazon VPC) per il tuo cluster supporti un nome host e una risoluzione DNS.
  • Aggiorna la ConfigMap aws-auth con il NodeInstanceRole dei nodi worker.
  • Imposta i tag per i nodi worker.
  • Conferma che le sottoreti Amazon VPC per il nodo worker abbiano indirizzi IP disponibili.
  • Conferma che i nodi worker possano raggiungere l'endpoint del server API per il tuo cluster.
  • Verifica che gli endpoint API di Cloud a calcolo elastico Amazon (Amazon EC2), Registro di container elastico Amazon (Amazon ECR) e Amazon Simple Storage Service (Amazon S3) possano raggiungere la tua regione AWS.

Risoluzione

Nota: se ricevi messaggi di errore durante l'esecuzione dei comandi dell'Interfaccia della linea di comando AWS (AWS CLI), assicurati di utilizzare la versione più recente di AWS CLI.

Utilizzo del runbook di automazione Systems Manager per identificare i problemi comuni

Utilizza il runbook AWSSupport-TroubleshootEKSWorkerNode per individuare problemi comuni che impediscono ai nodi worker di unirsi al cluster.

Importante: affinché l'automazione funzioni, i nodi worker devono avere l'autorizzazione per accedere a Systems Manager e su di essi deve essere in esecuzione Systems Manager. Per concedere l'autorizzazione, collega la policy gestita da AWS AmazonSSMManagedInstanceCore al ruolo IAM che corrisponde al tuo profilo dell'istanza EC2. Questa è la configurazione predefinita per i gruppi di nodi gestiti da EKS creati tramite eksctl.

  1. Apri il runbook.
  2. Controlla che la regione AWS nella Console di gestione AWS sia impostata sulla stessa regione del tuo cluster.
    Nota: consulta la sezione Dettagli documento del runbook per maggiori informazioni sul runbook.
  3. Nella sezione Input parameters (Parametri di input), specifica il nome del cluster nel campo ClusterName e l'ID istanza nel campo WorkerID.
  4. (Facoltativo) Nel campo AutomationAssumeRole, specifica il ruolo IAM per consentire a Systems Manager di eseguire operazioni. Se non specificato, le autorizzazioni IAM dell'entità IAM corrente vengono utilizzate per eseguire le operazioni nel runbook.
  5. Scegli Execute (Esegui).
  6. Controlla la sezione Outputs (Output) per scoprire perché il tuo nodo worker non si unisce al cluster e i passaggi che puoi adottare per risolverlo.

Verifica i requisiti di traffico del gruppo di sicurezza dei nodi worker

Verifica che il gruppo di sicurezza del piano di controllo e il gruppo di sicurezza del nodo worker siano configurati con le impostazioni consigliate per il traffico in entrata e in uscita. Per impostazione predefinita, Amazon EKS applica il gruppo di sicurezza del cluster alle istanze nel gruppo di nodi per facilitare la comunicazione tra i nodi e il piano di controllo. Se specifichi gruppi di sicurezza personalizzati nel modello di avvio per il gruppo di nodi gestito, Amazon EKS non aggiunge il gruppo di sicurezza del cluster.

Verifica le autorizzazioni IAM dei nodi worker

Assicurati che al ruolo dell'istanza IAM associato al nodo worker siano collegate le policy AmazonEKSWorkerNodePolicy e AmazonEC2ContainerRegistryReadOnly.

Nota: devi collegare la policy gestita da Amazon AmazonEKS_CNI_Policy a un ruolo IAM. Puoi collegarlo al ruolo dell'istanza del nodo. Tuttavia, è consigliabile collegare la policy a un ruolo associato all'account del servizio Kubernetes aws-node nello spazio dei nomi kube-system. Per maggiori informazioni, consulta la sezione Configurazione del plug-in CNI di Amazon VPC per l'utilizzo dei ruoli IAM per gli account di servizio.

Verifica che l'Amazon VPC per il tuo cluster supporti un nome host e una risoluzione DNS

Dopo avere configurato l'accesso privato per il tuo endpoint cluster EKS, devi attivare un nome host DNS e una risoluzione DNS per il tuo Amazon VPC. Quando attivi l'accesso privato all'endpoint, Amazon EKS crea per te una zona ospitata privata di Amazon Route 53. Quindi, Amazon EKS la associa all'Amazon VPC del tuo cluster. Per ulteriori informazioni, consulta la sezione Controllo degli accessi agli endpoint del cluster di Amazon EKS.

Aggiorna la ConfigMap aws-auth con il NodeInstanceRole dei tuoi nodi worker

Verifica che la ConfigMap aws-auth sia configurata correttamente con il ruolo IAM dei nodi worker, non con il profilo dell'istanza.

Imposta i tag per i tuoi nodi worker

Per la proprietà Tag dei nodi worker, imposta key (chiave) su Kubernetes.io/cluster/clusterName e value (valore) su owned.

Verifica che le sottoreti Amazon VPC per il nodo worker abbiano indirizzi IP disponibili

Se Amazon VPC sta esaurendo gli indirizzi IP, puoi associare un CIDR secondario al tuo Amazon VPC esistente. Per maggiori informazioni, consulta la sezione Aumento degli indirizzi IP disponibili per Amazon VPC.

Verifica che i tuoi nodi worker di Amazon EKS possano raggiungere l'endpoint del server API per il tuo cluster

Puoi avviare nodi worker in qualsiasi sottorete all'interno del tuo cluster VPC o sottorete in peering se esiste un percorso Internet attraverso i seguenti gateway:

  • NAT
  • Internet
  • Transit

Se i tuoi nodi worker vengono avviati in una rete privata con limitazioni, conferma che i nodi possano raggiungere l'endpoint del server API Amazon EKS. Per ulteriori informazioni, consulta i requisiti per eseguire Amazon EKS in un cluster privato senza accesso a Internet in uscita.

Nota: se i nodi si trovano in una sottorete privata supportata da un gateway NAT, è consigliabile creare il gateway NAT in una sottorete pubblica.

Se non utilizzi endpoint AWS PrivateLink, verifica l'accesso agli endpoint API tramite un server proxy per i seguenti servizi AWS:

  • Amazon EC2
  • Amazon ECR
  • Amazon S3

Per verificare che il nodo worker abbia accesso al server API, connettiti al tuo nodo worker utilizzando SSH ed esegui il seguente comando netcat:

nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443

Nota: sostituisci 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com con il tuo endpoint del server API.

Controlla i registri di kubelet mentre sei ancora connesso alla tua istanza:

journalctl -f -u kubelet

Se i registri di kubelet non forniscono informazioni sull'origine del problema, esegui il seguente comando per verificare lo stato di kubelet sul nodo worker:

sudo systemctl status kubelet

Raccogli i registri di Amazon EKS e del sistema operativo per ulteriori informazioni utili alla risoluzione dei problemi.

Verifica che gli endpoint delle API Amazon EC2, Amazon ECR e Amazon S3 siano in grado di raggiungere la tua regione AWS

Utilizza SSH per connetterti a uno dei nodi worker, quindi esegui i seguenti comandi per ciascun servizio:

$ nc -vz ec2.region.amazonaws.com 443
$ nc -vz ecr.region.amazonaws.com 443
$ nc -vz s3.region.amazonaws.com 443

Nota: sostituisci region con la regione AWS per il tuo nodo worker.

Configura i dati utente per il nodo worker

Per i modelli di avvio di gruppi di nodi gestiti con un'AMI specificata, è necessario fornire comandi di bootstrap affinché i nodi worker si uniscano al cluster. Amazon EKS non unisce le informazioni di bootstrap di default nei dati utente. Per ulteriori informazioni, consulta le sezioni Presentazione del modello di avvio e del supporto per l'AMI personalizzata nei gruppi di nodi gestiti da Amazon EKS e Specifica di un'AMI.

Esempio di modello di avvio con comandi bootstrap:

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments}

Nota: sostituisci ${ClusterName} con il nome del tuo cluster Amazon EKS. Sostituisci ${BootstrapArguments} con valori di bootstrap aggiuntivi, se necessario.