Wie kann ich den Status meiner Knoten vom Status NotReady oder Unknown in den Status Ready ändern?

Kurzbeschreibung

Sie können keine Pods auf einem Knoten planen, der sich im Status NotReady oder Unknown befindet. Sie können Pods nur auf einem Knoten planen, der sich im Status Ready befindet.

Die folgende Lösung bezieht sich auf Knoten mit dem Status NotReady oder Unknown.

Wenn sich Ihr Knoten im Status MemoryPressure, DiskPressure oder PIDPressure befindet, müssen Sie Ihre Ressourcen so verwalten, dass zusätzliche Pods auf dem Knoten geplant werden können.

Wenn sich Ihr Knoten im Status NetworkUnavailable befindet, müssen Sie das Netzwerk auf dem Knoten ordnungsgemäß konfigurieren. Weitere Informationen finden Sie unter Node-Status auf der Kubernetes-Website.

**Hinweis:**Informationen zur Verwaltung von Pod-Bereinigungen und Ressourcenlimits finden Sie unter Knoten-Druck-Bereinigung auf der Kubernetes-Website.

Behebung

Überprüfen Sie die AWS-Knoten und Kube-Proxy-Pods, um zu sehen, warum die Knoten im Status NotReady sind

Ein Knoten mit dem Status NotReady ist für Pods zur Planung nicht verfügbar.

Die verwaltete Knotengruppe hat aufgehört, die Container Network Interface (CNI)-Richtlinie an den Amazon Resource Name (ARN) der Knotenrolle anzuhängen, um die Sicherheitslage zu verbessern. Diese fehlende CNI-Richtlinie führt dazu, dass die Knoten in den NotReady-Status wechseln. Um dieses Problem zu beheben, folgen Sie den Richtlinien zur Einrichtung von IAM-Rollen für Service Accounts (IRSA) für das AWS-Knoten-DaemonSet.

1. Führen Sie den folgenden Befehl aus, um den Status Ihrer AWS-Konten- und Kube-Proxy-Pods zu überprüfen:

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

   Die Ausgabe sieht etwa wie folgt aus:

   $ 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. Überprüfen Sie die Ausgabe. Wenn Ihr Knotenstatus normal ist, sollten sich Ihre AWS-Knoten- und Kube-Proxy-Pods im Status Running befinden.
   Wenn keine AWS-Knoten oder Kube-Proxy-Pods aufgeführt sind, fahren Sie mit Schritt 3 fort. Die AWS-Knoten- und Kube-Proxy-Pods werden von einem DaemonSet verwaltet. Das bedeutet, dass auf jedem Knoten im Cluster ein AWS-Knoten- und ein Kube-Proxy-Pod laufen muss. Weitere Informationen finden Sie unter DaemonSet auf der Kubernetes-Website.

   Wenn sich einer der Pods in einem anderen Status als Running befindet, führen Sie den folgenden Befehl aus:

   $ kubectl describe pod yourPodName -n kube-system

   Führen Sie den folgenden Befehl aus, um zusätzliche Informationen aus den AWS-Knoten- und Kube-Proxy-Pod-Protokollen abzurufen:

   $ kubectl logs yourPodName -n kube-system

   Die Protokolle und Ereignisse aus der Describe-Ausgabe können zeigen, warum sich die Pods nicht im Status Running befinden. Damit ein Knoten in den Status Ready wechselt, müssen sowohl die AWS-Knoten- als auch die Kube-Proxy-Pods sich auf diesem Knoten im Status Running befinden.

3. Wenn die AWS-Knoten- und Kube-Proxy-Pods nicht in der Befehlsausgabe erscheinen, führen Sie die folgenden Befehle aus:

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

4. Suchen Sie in der Ausgabe nach einem Grund, warum die Pods nicht gestartet werden können:

   Hinweis: Sie können in den Protokollen der Amazon EKS-Steuerebene nach Informationen darüber suchen, warum die Pods nicht geplant werden können.

5. Stellen Sie sicher, dass die Versionen von AWS-Knoten und Kube-Proxy mit der Cluster-Version kompatibel sind, basierend auf den AWS-Richtlinien. Sie können zum Beispiel die folgenden Befehle ausführen, um die Pod-Versionen zu überprüfen:

   $ 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}'

   **Hinweis:**Informationen zum Aktualisieren der AWS-Knoten-Version finden Sie unter Arbeiten mit dem Amazon VPC CNI-Plugin für Kubernetes Amazon EKS-Add-On. Um die Kube-Proxy-Version zu aktualisieren, folgen Sie Schritt 4 unter Aktualisieren der Kubernetes-Version für Ihren Amazon EKS-Cluster.

In einigen Szenarien kann sich der Knoten im Status Unknown befinden. Das bedeutet, dass das Kubelet auf dem Knoten den korrekten Status des Knotens nicht an die Steuerungsebene übermitteln kann.

Gehen Sie wie in den folgenden Abschnitten beschrieben vor, um Probleme mit Knoten mit dem Status Unknown zu beheben.

Überprüfung der Netzkonfiguration zwischen den Knoten und der Steuerebene

1. Vergewissern Sie sich, dass in Ihren Subnetzen keine Netzwerk-Zugriffssteuerungslisten-Regeln vorhanden sind, die den Verkehr zwischen der Amazon EKS-Steuerebene und Ihren Worker-Knoten blockieren.

2. Vergewissern Sie sich, dass die Sicherheitsgruppen für Ihre Steuerebene und Knoten die Mindestanforderungen für eingehende und ausgehende Nachrichten erfüllen.

3. (Optional) Wenn Ihre Knoten für die Verwendung eines Proxys konfiguriert sind, stellen Sie sicher, dass der Proxy den Verkehr zu den API-Server-Endpunkten zulässt.

4. Um zu überprüfen, ob der Knoten Zugriff auf den API-Server hat, führen Sie den folgenden Netcat-Befehl innerhalb des Worker-Knotens aus:

   $ 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!

   **Hinweis:**Ersetzen Sie 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com durch Ihren API-Serverendpunkt.

5. Stellen Sie sicher, dass die Routing-Tabellen so konfiguriert sind, dass sie die Kommunikation mit dem API-Serverendpunkt ermöglichen. Dies kann entweder über ein Internet-Gateway oder ein NAT-Gateway erfolgen. Wenn der Cluster PrivateOnly-Netzwerke verwendet, überprüfen Sie, ob die VPC-Endpunkte korrekt konfiguriert sind.

Prüfen Sie den Status des Kubelet

1. Verwenden Sie SSH, um sich mit dem betroffenen Worker-Knoten zu verbinden.

2. Führen Sie den folgenden Befehl aus, um die Kubelet-Protokolle zu überprüfen:

   $ journalctl -u kubelet > kubelet.log

   **Hinweis:**Die Kubelet.log-Datei enthält Informationen zu Kubelet-Vorgängen, die Ihnen helfen können, die Ursache des Knotenstatusproblems zu finden.

3. Wenn die Protokolle keine Informationen zur Ursache des Problems enthalten, führen Sie den folgenden Befehl aus. Der Befehl überprüft den Status des Kubelets auf dem Worker-Knoten:

   $ 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

   Wenn sich das Kubelet nicht im Status Running befindet, führen Sie den folgenden Befehl aus, um das Kubelet neu zu starten:

   $ sudo systemctl restart kubelet

Prüfen Sie, ob der Amazon EC2 API-Endpunkt erreichbar ist

1. Verwenden Sie SSH, um sich mit einem der Worker-Knoten zu verbinden.
2. Um zu prüfen, ob der Amazon Elastic Compute Cloud (Amazon EC2) API-Endpunkt für Ihre AWS Region erreichbar ist, führen Sie den folgenden Befehl aus:

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

   **Hinweis:**Ersetzen Sie Us-East-1 durch die AWS-Region, in der sich Ihr Worker-Knoten befindet.

Überprüfen Sie das Instance-Profil des Worker-Knotens und die ConfigMap

1. Vergewissern Sie sich, dass das Worker-Knoten-Instance-Profil die empfohlenen Richtlinien enthält.
2. Vergewissern Sie sich, dass sich die Rolle der Worker-Knoten-Instance in der AWS-Auth-ConfigMap befindet. Um die ConfigMap zu überprüfen, führen Sie den folgenden Befehl aus:

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

   Die ConfigMap sollte einen Eintrag für die AWS Identity and Access Management (IAM)-Rolle der Worker-Knoten-Instance enthalten. Zum Beispiel:

   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