Come posso modificare lo stato dei nodi da NotReady o Unknown a Ready?

Breve descrizione

Non è possibile pianificare i pod su un nodo con stato NotReady o Unknow. I pod possono essere pianificati solo su un nodo con stato Ready.

La risoluzione seguente riguarda i nodi con stato NotReady o Unknown.

Se lo stato del nodo è MemoryPressure, DiskPressure o PIDPressure, è necessario gestire le risorse per consentire la pianificazione di pod aggiuntivi sul nodo.

Se lo stato del nodo è NetworkUnavailable , è necessario configurare correttamente la rete sul nodo. Per ulteriori informazioni, consulta lo stato del nodo sul sito Web di Kubernetes.

Nota: per informazioni sulla gestione delle espulsioni dai pod e dei limiti di risorse, consulta Node-pressure eviction sul sito Web di Kubernetes.

Risoluzione

Controlla i pod aws-node e kube-proxy per determinare perché lo stato dei nodi è NotReady

Un nodo con stato NotReady non è disponibile per la programmazione dei pod.

Il gruppo di nodi gestito potrebbe rimuovere la policy Container Network Interface (CNI) dal nome della risorsa Amazon (ARN) del ruolo di nodo per migliorare il livello di sicurezza. La mancanza della policy CNI fa sì che i nodi passino allo stato ** NotReady**. Per risolvere questo problema, segui le linee guida per configurare IAM Roles for Service Accounts (IRSA) per aws-node DaemonSet.

1. Per verificare lo stato dei pod aws-node e kube-proxy, esegui il seguente comando:

   $ kubectl get pods -n kube-system -o wide

   L'output è simile al seguente:

   $ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
   aws-node-qvqr2                    1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
   kube-proxy-292b4                  1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

2. Rivedi l'output. Se lo stato del nodo è normale, lo stato dei pod aws-node e kube-proxy dovrebbero essere Running.
   Se non è elencato alcun pod aws-node o kube-proxy, vai al passaggio 3. I pod aws-node e kube-proxy sono gestiti da un DaemonSet. Ciò significa che ogni nodo del cluster deve avere un nodo aws-node e un pod kube-proxy in esecuzione sullo stesso. Per ulteriori informazioni, consulta DaemonSet sul sito Web di Kubernetes.

   Se lo stato di uno dei pod è diverso da Running, esegui il seguente comando:

   $ kubectl describe pod yourPodName -n kube-system

   Per ottenere informazioni aggiuntive dai log dei pod aws-node e kube-proxy, esegui il seguente comando:

   $ kubectl logs yourPodName -n kube-system

   I log e gli eventi dell'output descrittivo possono mostrare perché i pod non sono nello stato Running. Affinché un nodo passi allo stato Ready, sia il pod aws-node che quello kube-proxy devono essere nello stato Running su quel nodo.

3. Se i pod aws-node e kube-proxy non compaiono nell'output del comando, esegui i seguenti comandi:

   $ kubectl describe daemonset aws-node -n kube-system
   $ kubectl describe daemonset kube-proxy -n kube-system

4. Cerca nell'output il motivo per cui i pod non possono essere avviati:

   Nota: puoi anche cercare nei log del piano di controllo (control-plane) di Amazon EKS informazioni sul motivo per cui i pod non possono essere programmati.

5. Verifica che le versioni di aws-node e kube-proxy siano compatibili con la versione del cluster in base alle linee guida di AWS. Ad esempio, esegui i seguenti comandi per controllare le versioni dei pod:

   $ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

   Nota: per aggiornare la versione aws-node consulta Working with the Amazon VPC CNI plugin for Kubernetes Amazon EKS add-on. Per aggiornare la versione kube-proxy segui il passaggio 4 in Update the Kubernetes version for your Amazon EKS cluster.

In alcuni scenari, il nodo può avere lo stato Unknown. Ciò significa che il kubelet sul nodo non può comunicare lo stato corretto del nodo al piano di controllo (control-plane).

Per risolvere i problemi relativi ai nodi con stato Unknown completa i passaggi nelle seguenti sezioni.

Verificare la configurazione di rete tra i nodi e il piano di controllo (control-plane)

1. Verifica che non ci siano regole della lista di controllo degli accessi (ACL) sulle sottoreti che bloccano il traffico tra il piano di controllo (control-plane) di Amazon EKS e i nodi worker.

2. Verifica che i gruppi di sicurezza del piano di controllo (control-plane) e dei nodi soddisfino i requisiti minimi in entrata e in uscita.

3. (Facoltativo) Se i nodi sono configurati per utilizzare un proxy, verifica che il proxy consenta il traffico verso gli endpoint del server API.

4. Per verificare che il nodo abbia accesso al server API, esegui il seguente comando netcat dall'interno del nodo worker:

   $ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

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

5. Verifica che le tabelle di routing siano configurate in modo da consentire la comunicazione con l'endpoint del server API. Questa operazione può essere eseguita mediante un gateway Internet oppure un gateway NAT. Se il cluster utilizza la rete PrivateOnly, verifica che gli endpoint VPC siano correttamente configurati.

Controlla lo stato del kubelet

1. Utilizza SSH per connetterti al nodo worker interessato.

2. Per verificare i log di kubelet, esegui il seguente comando:

   $ journalctl -u kubelet > kubelet.log

   Nota: il file kubelet.log contiene informazioni sulle operazioni di kubelet che possono aiutarti a trovare la causa principale del problema di stato del nodo.

3. Qualora i log non forniscano informazioni sull'origine del problema, esegui il comando seguente. Il comando controlla lo stato del kubelet sul nodo worker:

   $ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet
      Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/kubelet.service.d
              └─10-eksclt.al2.conf
      Active: inactive (dead) since Wed 2023-12-04 08:57:33 UTC; 40s ago

   Se lo stato del kubelet non è Running, esegui il seguente comando per riavviare il kubelet:

   $ sudo systemctl restart kubelet

Controlla che l'endpoint dell'API Amazon EC2 sia raggiungibile

1. Utilizza SSH per connetterti a uno dei nodi worker.
2. Per controllare se l'endpoint API Amazon Elastic Compute Cloud (Amazon EC2) della tua regione AWS è raggiungibile, esegui il seguente comando:

   $ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

   Nota: sostituisci us-east-1 con la regione AWS in cui si trova il nodo worker.

Controlla il profilo dell'istanza del nodo worker e la ConfigMap

1. Verifica che il profilo dell'istanza del nodo worker disponga dei criteri consigliati.
2. Verifica che il ruolo dell'istanza del nodo worker sia nella ConfigMap aws-auth. Per controllare la ConfigMap, esegui il seguente comando:

   $ kubectl get cm aws-auth -n kube-system -o yaml

   La ConfigMap dovrebbe avere una voce per il ruolo AWS Identity and Access Management (IAM) dell'istanza del nodo worker. Ad esempio:

   apiVersion: v1kind: 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