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

7 minuti di lettura
0

I miei nodi di lavoro Amazon Elastic Kubernetes Service (Amazon EKS) hanno lo stato Non pronto o Sconosciuto. Desidero ripristinare lo stato Pronto per i miei nodi di lavoro.

Breve descrizione

Non puoi pianificare i pod su un nodo con stato NotReady o Unknow. Puoi pianificare i pod solo su un nodo con lo stato Pronto.

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

Se il nodo è nello stato MemoryPressure, ** DiskPressure** o PIDPressure, è necessario gestire le risorse per consentire la pianificazione di pod aggiuntivi sul nodo. Se il nodo è nello stato 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 degli sfratti 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 vedere perché i nodi sono in stato NotReady

Un nodo con stato NotReady non è disponibile per la pianificazione dell'attivazione dei pod.

Il gruppo di nodi gestito ha smesso di associare la policy Container Network Interface (CNI) all'Amazon Resource Name (ARN) del ruolo di nodo per migliorare il livello di sicurezza. Questo fa sì che i nodi passino allo stato NotReady a causa della mancanza di una policy CNI.

  1. Per vedere se il pod aws-node è in stato di errore, esegui il seguente comando:
$ kubectl get pods -n kube-system -o wide

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 tuoi pod aws-node e kube-proxy, esegui il seguente comando:
$ kubectl get pods -n kube-system -o wide
  1. Controlla lo stato dei pod aws-node e kube-proxy esaminando l'output del passaggio 1.

**Nota:**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 su di esso. Se non è elencato alcun pod aws-node o kube-proxy, vai al passaggio 4. Per ulteriori informazioni, consulta DaemonSet sul sito Web di Kubernetes.

Se lo stato del tuo nodo è normale, i tuoi pod ** aws-node** e kube-proxy dovrebbero essere in stato In esecuzione. Ad esempio:

$ kubectl get pods -n kube-system -o wide
NAME                             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

Se uno dei pod è in uno stato diverso da In esecuzione, esegui il seguente comando:

$ kubectl describe pod yourPodName -n kube-system
  1. Per ottenere informazioni aggiuntive dai log dei pod aws-node e kube-proxy, esegui il seguente comando:
$ kubectl logs yourPodName -n kube-system

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

Nota: Il nome dei pod può differire da aws-node-qvqr2 e kube-proxy-292b4, come mostrato negli esempi precedenti.

  1. Se i pod aws-node e kube-proxy non sono elencati dopo aver eseguito il comando del passaggio 1, esegui i seguenti comandi:
$ kubectl describe daemonset aws-node -n kube-system
$ kubectl describe daemonset kube-proxy -n kube-system
  1. Cerca nell'output dei comandi del passaggio 4 un motivo per cui i pod non possono essere avviati.

Suggerimento: Puoi cercare nei registri del piano di controllo di Amazon EKS informazioni sul motivo per cui i pod non possono essere programmati.

  1. 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, puoi eseguire 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 Gestione del plug-in Amazon VPC CNI per il componente aggiuntivo Kubernetes. Per aggiornare la versione kube-proxy, segui il passaggio 4 in Aggiorna la versione Kubernetes per il tuo cluster Amazon EKS.

In alcuni scenari, il nodo può avere lo stato Sconosciuto. Ciò significa che il kubelet sul nodo non può comunicare con il piano di controllo con lo stato corretto del nodo.

Per risolvere i problemi relativi ai nodi con stato ** Sconosciuto**, completa i passaggi nelle seguenti sezioni:

  • Verificare la configurazione di rete tra i nodi e il piano di controllo
  • Controlla lo stato del kubelet
  • Verifica che l'endpoint dell'API Amazon EC2 sia raggiungibile

Verificare la configurazione di rete tra i nodi e il piano di controllo

  1. Verifica che non ci siano regole ACL (Network Access Control List) sulle tue sottoreti che bloccano il traffico tra il piano di controllo di Amazon EKS e i tuoi nodi di lavoro.

  2. Verifica che i gruppi di sicurezza per il piano di controllo e i nodi soddisfino i requisiti minimi in entrata e in uscita.

  3. (Facoltativo) Se i tuoi 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 443
Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

Importante: Sostituisci 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com con l'endpoint del tuo server API.

  1. Verifica che le tabelle dei percorsi siano configurate correttamente per consentire la comunicazione con l'endpoint del server API tramite un gateway Internet o un gateway NAT. Se il cluster utilizza la rete PrivateOnly, verifica che gli endpoint VPC siano configurati correttamente.

Controlla lo stato del kubelet

  1. Usa SSH per connetterti al nodo di lavoro interessato.

  2. Per controllare 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.

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

$ 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 2019-12-04 08:57:33 UTC; 40s ago

Se il kubelet non è nello stato In esecuzione, esegui il seguente comando per riavviare il kubelet:

$ sudo systemctl restart kubelet

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

  1. Usa SSH per connetterti a uno dei nodi di lavoro.

  2. Per verificare se l'endpoint API Amazon Elastic Compute Cloud (Amazon EC2) per la tua regione AWS è raggiungibile, esegui il seguente comando:

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

**Importante:**Sostituisci us-east-1 con la regione AWS in cui si trova il tuo nodo di lavoro.

Controlla il profilo dell'istanza del nodo di lavoro e la ConfigMap

  1. Verificare che il profilo dell'istanza del nodo di lavoro disponga dei criteri consigliati.

  2. Conferma che il ruolo dell'istanza del nodo di lavoro 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 di lavoro. 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

AWS UFFICIALE
AWS UFFICIALEAggiornata 3 anni fa