Wie behebe ich Fehler bei meinem Amazon-EKS-Worker-Knoten, der aufgrund von PLEG-Problemen in den Status NotReady wechselt?

Lösung

Wenn die Worker-Knoten in Ihrem Amazon-EKS-Cluster den Status NotReady oder Unknown annehmen, werden die für diesen Knoten geplanten Arbeitslasten unterbrochen. Gehen Sie wie folgt vor, um dieses Problem zu beheben:

Rufen Sie Informationen zum Worker-Knoten ab, indem Sie den folgenden Befehl ausführen:

$ kubectl describe node node-name

Überprüfen Sie in der Ausgabe den Abschnitt Bedingungen, um die Ursache für das Problem zu finden.

Beispiel:

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

Die häufigsten Gründe dafür, dass PLEG fehlerhaft ist, sind die folgenden:

• Kubelet kann nicht mit dem Docker-Daemon kommunizieren, da der Daemon beschäftigt oder tot ist. Beispielsweise könnte der Docker-Daemon auf Ihrem EKS-Worker-Knoten defekt sein.
• Ein Problem mit zu wenig Arbeitsspeicher (OOM) oder CPU-Auslastung auf Instance-Ebene führte dazu, dass PLEG fehlerhaft wurde.
• Wenn der Worker-Knoten über eine große Anzahl von Pods verfügt, können der Kubelet- und der Docker-Daemon einer höheren Arbeitslast ausgesetzt sein, was zu PLEG-bezogenen Fehlern führt. Höhere Arbeitsbelastungen können auch die Folge sein, wenn die Verfügbarkeit oder Bereitschaft häufig überprüft werden.

Kubelet-Protokolle überprüfen

Sie können die Kubelet-Protokolle auf der Instance überprüfen, um festzustellen, warum PLEG fehlerhaft ist.

1.    Verwenden Sie SSH, um eine Verbindung zur Instance herzustellen, und führen Sie den folgenden Befehl aus:

$ journalctl -u kubelet > kubelet.log

Wenn Sie das Amazon-EKS-optimierte AMI verwenden und SSH nicht aktiviert ist, können Sie eine Verbindung über SSM herstellen. Weitere Informationen finden Sie unter Verbindung zu Ihrer Linux-Instance mithilfe des Session Managers herstellen.

2.    Suchen Sie in diesen Protokollen nach PLEG-bezogenen Ereignissen, die von kubelet veröffentlicht wurden:

Beispiel:

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    Sehen Sie in den Kubelet-Protokollen nach, ob es Pods gibt, die die Readiness- und Liveness-Tests nicht bestanden haben. Diese Protokollmeldungen sehen in etwa wie folgt aus:

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Verwenden Sie diese Protokolle, um die Pods zu identifizieren, die ausfallen. Überprüfen Sie bei den identifizierten Pods, ob die Health Probes korrekt konfiguriert sind.

Ressourcenverbrauch des Worker-Knotens überwachen

Prüfen Sie, ob ein Problem auf Instance-Ebene vorliegt, z. B. eine Ressourcenknappheit aufgrund von OOM-Problemen oder einer hohen CPU-Auslastung.

Überwachen Sie die Metrik zur CPU-Auslastung für den zugrunde liegenden Amazon-Elastic-Compute-Cloud-Worker-Knoten (Amazon EC2). Überprüfen Sie diese Metrik, um festzustellen, ob es zu plötzlichen Spitzen kommt oder ob die CPU-Auslastung 100 % erreicht.

Kubelet berichtet, dass der Knoten unter Druck steht, wenn der Knoten unabhängig von den konfigurierten Übergangsfristen harte oder weiche Räumungsschwellen erreicht. Sie können den Zustand des Knotens überprüfen, indem Sie den folgenden Befehl ausführen:

$ kubectl describe node <node_name>

Prüfen Sie, ob der Knotenzustand in der Ausgabe als MemoryPressure angegeben ist. In diesen Fällen kann die Instance aufgrund der Nichtverfügbarkeit von Ressourcen zum Stillstand kommen. Dies kann dazu führen, dass der Prozess nicht mehr reagiert.

Um Probleme aufgrund von Ressourcenknappheit zu vermeiden, empfiehlt es sich, die CPU- und Speicherauslastung Ihrer Pods zu begrenzen.

Wenn Sie ein Ressourcenlimit für Ihren Container angeben, setzt Kubelet diese Grenzwerte durch. Die Verwendung des laufenden Containers darf diese Grenzwerte nicht überschreiten. Dadurch wird verhindert, dass der Pod mehr Speicher als benötigt beansprucht, wodurch OOM-Probleme vermieden werden. Weitere Informationen finden Sie unter Ressourcenmanagement für Pods und Container auf der Kubernetes-Website.

Erwägen Sie auch, Container Insights zu verwenden, um Metriken und Protokolle aus Ihren containerisierten Anwendungen und Microservices zu sammeln, zu aggregieren und zusammenzufassen. Weitere Informationen finden Sie unter Amazon-EKS- und Kubernetes-Container-Insights-Metriken. Sie können node_cpu_utilization und node_memory_utilization verwenden, um die Ressourcenauslastung auf Knotenebene zu überwachen. Sie können auch Alarme einrichten, um benachrichtigt zu werden, wenn ein bestimmter Schwellenwert erreicht wird.

Leistung des Amazon-EBS-Root-Volumes überwachen

PLEG ist möglicherweise aufgrund von Festplattenproblemen in Ihrem Amazon-Elastic-Block-Store-Volume (Amazon EBS) fehlerhaft. In diesem Fall sehen die Kubelet-Protokolle wie folgt aus:

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

Dies passiert, wenn Ihre Anwendungen, die die Pods auf der Instance verwenden, intensive E/A-Vorgänge auf der Festplatte ausführen.

Sie können die IOPS-Auslastung und den Durchsatz Ihres Amazon-EBS-Volumes mithilfe der Amazon-CloudWatch-Metriken für Amazon EBS überwachen.

Verwenden Sie die folgenden CloudWatch-Metriken, um den Durchsatz und die IOPS eines Amazon-EBS-Volumes zu überwachen:

• VolumeReadops
• VolumeWriteOps
• VolumeReadBytes

Sie können beispielsweise die durchschnittlichen IOPS in Ops/s mit der folgenden Formel berechnen:

((VolumeReadOps) + (VolumeWriteOps)) / (Zeitraum)

Sie können den durchschnittlichen Durchsatz in Bytes/s mit der folgenden Formel berechnen:

((VolumeReadBytes) + (VolumeWriteBytes)) / (Zeitraum)

Weitere Informationen finden Sie unter Wie kann ich CloudWatch-Metriken verwenden, um den durchschnittlichen Durchsatz und die durchschnittliche Anzahl von IOPS zu berechnen, die mein EBS-Volume bereitstellt?

Um dieses Problem zu beheben, sollten Sie erwägen, die Festplattengröße zu erhöhen oder den EBS-Volume-Typ zu ändern, um einen besseren E/A-Durchsatz zu erzielen.

---