In che modo posso risolvere i problemi legati a eksctl con i cluster e i gruppi di nodi Amazon EKS?

Breve descrizione

Di seguito sono riportati i problemi comuni che potresti riscontrare utilizzando eksctl per creare o gestire un cluster o un gruppo di nodi Amazon EKS:

• Non sai come creare un cluster con eksctl. Consulta la Guida introduttiva ad Amazon EKS - eksctl e la sezione eksctl della pagina Creazione di un cluster Amazon EKS.
• Non sai come specificare le opzioni di bootstrap di kubelet per i gruppi di nodi gestiti. Segui i passaggi elencati in Opzioni di bootstrap di kubelet nella sezione Risoluzione.
• Non sai come cambiare il tipo di istanza di un gruppo di nodi esistente. È necessario creare un nuovo gruppo di nodi. Consulta la sezione Migrazione a un nuovo gruppo di nodi e Nodegroup immutability (Immutabilità del gruppo di nodi) dal sito Web eskctl.
• Hai raggiunto il numero massimo di risorse AWS. Controlla le tue risorse per vedere se riesci a eliminare quelle che non stai utilizzando. Se hai bisogno di più capacità, consulta la sezione Richiesta di aumento della quota.
• È possibile avviare istanze del piano di controllo (control-plane) in una zona di disponibilità con capacità limitata. Consulta la pagina How do I resolve cluster creation errors in Amazon EKS? (In che modo posso risolvere gli errori di creazione dei cluster in Amazon EKS?)
• I tuoi nodi non riescono a passare allo stato Pronto. Segui i passaggi elencati in Risoluzione dei problemi di timeout delle operazioni nella sezione Risoluzione.
• I valori di esportazione non esistono per il cluster. Segui i passaggi elencati in Creazione del gruppo di nodi nelle sottoreti private nella sezione Risoluzione.
• È stato utilizzato un tipo di istanza non supportato per creare un cluster o un gruppo di nodi. Segui i passaggi elencati in Verifica se il tipo di istanza è supportato nella sezione Risoluzione.

Risoluzione

Opzioni di bootstrap di kubelet

Per impostazione predefinita, eksctl crea uno script di bootstrap e lo aggiunge al modello di avvio che i nodi (worker) eseguono durante il processo di bootstrap. Per specificare le tue opzioni di bootstrap di kubelet, utilizza la specifica overrideBootstrapCommand per sovrascrivere lo script di bootstrap eksctl. Utilizza la specifica overrideBootstrapCommand per gruppi di nodi gestiti e autogestiti.

Specifiche del file di configurazione:

managedNodeGroups:
  name: custom-ng
  ami: ami-0e124de4755b2734d
  securityGroups:
    attachIDs: ["sg-1234"]
  maxPodsPerNode: 80
  ssh:
    allow: true
  volumeSize: 100
  volumeName: /dev/xvda
  volumeEncrypted: true
  disableIMDSv1: true
  overrideBootstrapCommand: |
  #!/bin/bash
  /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

N.B.: è possibile utilizzare overrideBootstrapCommand solo quando si utilizza un'AMI personalizzata. Se non si specifica un ID AMI, la creazione del cluster non riesce.

Non è stato specificato un ID AMI personalizzato

Se non specifichi un ID AMI personalizzato quando crei gruppi di nodi gestiti, per impostazione predefinita Amazon EKS utilizza un'AMI ottimizzata per Amazon EKS e uno script di bootstrap. Per utilizzare un'AMI ottimizzata per Amazon EKS con dati utente personalizzati per specificare i parametri di bootstrap, specifica l'ID AMI nella configurazione del gruppo di nodi gestiti.

Per ottenere l'ID AMI più recente per l'AMI ottimizzata per Amazon EKS più recente, esegui il seguente comando:

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id --region Region --query "Parameter.Value" --output text

N.B.: sostituisci il campo Regione con la tua Regione AWS.

Risoluzione dei problemi di timeout delle operazioni

Se durante la creazione di un nodo viene visualizzato il seguente errore, il tuo gruppo di nodi potrebbe avere problemi di timeout:

waiting for at least 1 node(s) to become ready in "nodegroup"

Quando crei un gruppo di nodi EKS con eksctl, la CLI eksctl si connette al server API per controllare continuamente lo stato del nodo Kubernetes. La CLI attende che i nodi passino allo stato Pronto e alla fine scade se i nodi non riescono a spostarsi.

Di seguito sono riportati i motivi per cui i nodi non riescono a passare allo stato Pronto:

• Il kubelet non può comunicare o autenticarsi con l'endpoint del server API EKS durante il processo di bootstrap.
• I pod aws-node e kube-proxy non sono in stato In esecuzione.
• I dati utente del nodo (worker) Amazon Elastic Compute Cloud (Amazon EC2) non sono stati eseguiti correttamente.

Il kubelet non è in grado di comunicare con l'endpoint del server API EKS

Se il kubelet non è in grado di comunicare con l'endpoint del server API EKS durante il processo di bootstrap, allora recupera l'endpoint del server API EKS.

Esegui il comando seguente sul tuo nodo (worker):

curl -k https://123456DC0A12EC12DE0C12BC312FCC1A.yl4.us-east-1.eks.amazonaws.com
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

Il comando precedente dovrebbe restituire il codice di stato HTTP 403. In caso di timeout del comando, potrebbe verificarsi un problema di connettività di rete tra il server API EKS e i nodi (worker).

Per risolvere il problema di connettività, completare una delle seguenti operazioni relative al tuo caso d'uso:

• Se i nodi (worker) si trovano in una sottorete privata, verifica che l'endpoint del server API EKS sia in modalità Privato o Accesso pubblico e privato.
• Se l'endpoint del server API EKS è impostato su Privato, è necessario applicare determinate regole per la zona ospitata privata per indirizzare il traffico al server API. Gli attributi enableDnsHostnames ed enableDnsSupport di Amazon Virtual Private Cloud (Amazon VPC) devono essere impostati sul valore Vero. Inoltre, le opzioni DHCP impostate per Amazon VPC devono includere AmazonProvideDNS nel suo elenco di domini.
• Se è stato creato il gruppo di nodi in sottoreti pubbliche, assicurati che l'attributo di indirizzamento pubblico IPv4 delle sottoreti sia impostato su Vero. Se non si imposta l'attributo su Vero, ai nodi (worker) non viene assegnato un indirizzo IP pubblico e non possono accedere a Internet.
• Verifica se il gruppo di sicurezza del cluster Amazon EKS permette richieste di ingresso alla porta 443 dal gruppo di sicurezza del nodo (worker).

Il kubelet non può autenticarsi con l'endpoint del server API EKS

Se il kubelet non è in grado di autenticarsi con l'endpoint del server API EKS durante il processo di bootstrap, completa i seguenti passaggi.

1.    Esegui il seguente comando per verificare che il nodo (worker) abbia accesso all'endpoint STS:

telnet sts.region.amazonaws.com 443

N.B.: sostituisci il campo Regione con la tua Regione AWS.

2.    Assicurati che il ruolo AWS Identity and Access Management (IAM) del nodo di lavoro sia stato aggiunto a aws-auth ConfigMap.

Ad esempio:

apiVersion:v1 kind:ConfigMap metadata:name:aws-auth namespace:kube-system data:mapRoles:|
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

N.B.: per i gruppi di nodi di Microsoft Windows, è necessario aggiungere un ulteriore gruppo RBAC eks:kube-proxy-windows nella sezione mapRoles per il ruolo IAM del gruppo di nodi.

I pod aws-node e kube-proxy non sono nello stato In esecuzione

Per verificare che i pod aws-node e kube-proxy siano in stato In esecuzione, esegui il seguente comando:

kubectl get pods -n kube-system

Se il pod aws-node è in stato Errore, controlla la connessione tra il nodo (worker) e l'endpoint Amazon EC2:

ec2.region.amazonaws.com

N.B.: sostituisci il campo Regione con la tua Regione AWS.

Verifica che le policy gestite da AWS AmazonEKSWorkerNodePolicy e AmazonEC2ContainerRegistryReadOnly siano attribuite al ruolo IAM del gruppo di nodi.

Se i nodi si trovano in una sottorete privata, bisogna configurare gli endpoint VPC di Amazon ECR per permettere l'estrazione di immagini da Amazon Elastic Container Registry (Amazon ECR).

Se utilizzi IRSA per il tuo CNI Amazon VPC, allega la policy gestita AWS di AmazonEKS_CNI_Policy al ruolo IAM utilizzato dai pod di aws-node. È inoltre necessario allegare la policy al ruolo IAM del gruppo di nodi senza IRSA.

I dati utente del nodo (worker) EC2 non sono stati eseguiti correttamente

Per verificare se si sono verificati errori durante l'esecuzione dei dati utente, rivedere i registri di cloud-init alla voce /var/log/cloud-init.log e /var/log/cloud-init-output.log.

Per ulteriori informazioni, esegui lo script EKS Logs Collector sui nodi worker.

Creazione del gruppo di nodi nelle sottoreti private

Se durante la creazione di un gruppo di nodi viene visualizzato il seguente errore, crea il gruppo di nodi in sottoreti private:

No export named eksctl--cluster::SubnetsPublic found. Rollack requested by user

Se hai creato il cluster Amazon EKS con reti PrivateOnly, AWS CloudFormation non è in grado di creare sottoreti pubbliche. Ciò significa che i valori di esportazione non esisteranno per le sottoreti pubbliche. Se non esistono valori di esportazione per il cluster, la creazione del gruppo di nodi non andrà a buon fine.

Per risolvere questo problema, puoi includere il flag --node-private-networking quando usi il comando eksctl in linea. È inoltre possibile utilizzare la specifica privateNetworking: vero all'interno della configurazione del gruppo di nodi per richiedere la creazione di gruppi di nodi in sottoreti private.

Aggiorna la tua versione eksctl o specifica la Regione AWS corretta

Se viene visualizzato il seguente errore, controlla la tua Regione AWS:

no eksctl-managed CloudFormation stacks found for "cluster-name"

Se utilizzi una versione di eksctl precedente alla 0.40.0, puoi visualizzare o gestire solo le risorse di Amazon EKS create con eksctl. Per gestire le risorse che non sono state create con eksctl, aggiorna eksctl alla versione 0.40.0 o successiva. Per informazioni sui comandi che è possibile eseguire per i cluster che non sono stati creati con eksctl, consulta la sezione Cluster non creati con eksctl (nel sito web eksctl).

Inoltre, le pile CloudFormation gestite da eksctl non vengono trovate se si specifica una Regione AWS errata. Per risolvere il problema, assicurati di specificare la regione corretta in cui si trovano le risorse Amazon EKS.

Verifica se il tipo di istanza è supportato

Se hai utilizzato un tipo di istanza non supportato per creare un cluster o un nodo, viene visualizzato il seguente errore:

You must use a valid fully-formed launch template. The requested configuration is currently not supported. Please check the documentation for supported configurations'

Per verificare se il tuo tipo di istanza o altre configurazioni sono supportate in una Regione AWS specifica, esegui il seguente comando:

aws ec2 describe-instance-type-offerings --region Region --query 'InstanceTypeOfferings[*].{InstanceType:InstanceType}'

N.B.: sostituisci il campo Regione con la tua Regione AWS.

---