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.

Lösung

Ü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. Dies führt dazu, dass Knoten aufgrund einer fehlenden CNI-Richtlinie in den Status NotReady wechseln.

1.Führen Sie den folgenden Befehl aus, um zu überprüfen, ob sich der AWS-Knoten-Pod im Fehlerstatus befindet:

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

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.

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

3.Überprüfen Sie den Status der AWS-Knoten- und Kube-Proxy-Pods, indem Sie die Ausgabe aus Schritt 1 überprüfen.

**Hinweis:**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. Wenn keine AWS-Knoten oder Kube-Proxy-Pods aufgeführt sind, fahren Sie mit Schritt 4 fort. Weitere Informationen finden Sie unter DaemonSet auf der Kubernetes-Website.

Wenn Ihr Knotenstatus normal ist, sollten sich Ihre AWS-Knoten- und Kube-Proxy-Pods im Status Running befinden. Zum Beispiel:

$ 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

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

4.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.

**Hinweis:**Der Name der Pods kann von AWS-Knoten-Qvqr2 und Kube-Proxy-292b4 abweichen, wie in den vorherigen Beispielen gezeigt.

5.Wenn die AWS-Knoten- und Kube-Proxy-Pods nach dem Ausführen des Befehls aus Schritt 1 nicht aufgeführt sind, führen Sie die folgenden Befehle aus:

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

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

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

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

7.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 Verwaltung des Amazon VPC CNI-Plug-ins für das Kubernetes-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 nicht mit der Steuerebene kommunizieren kann, wenn der Knoten den korrekten Status hat.

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

• Überprüfen Sie die Netzwerkkonfiguration zwischen Knoten und der Steuerebene.
• Überprüfen Sie den Status des Kubelets.
• Stellen Sie sicher, dass der Amazon EC2-API-Endpunkt erreichbar ist.

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

1.Vergewissern Sie sich, dass in Ihren Subnetzen keine Network-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 443
Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

**Wichtig:**Ersetzen Sie 9fcf4ea77d81408ed82517b9b7e60d52.yl4.eu-north-1.eks.amazonAWS.com durch Ihren API-Serverendpunkt.

5.Überprüfen Sie, ob die Routing-Tabellen korrekt konfiguriert sind, um die Kommunikation mit dem API-Server-Endpunkt entweder über ein Internet-Gateway oder ein NAT-Gateway zu ermöglichen. 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.

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

$ 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

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 443
Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

**Wichtig:**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: 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

---