Wie kann ich den Pod-Status in Amazon EKS beheben?
Meine Amazon Elastic Kubernetes Service (Amazon EKS)-Pods, die auf Amazon Elastic Compute Cloud (Amazon EC2)-Instances oder auf einer verwalteten Knotengruppe ausgeführt werden, stecken fest. Ich möchte, dass meine Pods in den Status „Wird ausgeführt“ oder „Beendet“ versetzt werden.
Behebung
Wichtig: Die folgenden Schritte gelten nur für Pods, die auf Amazon EC2-Instances oder in einer verwalteten Knotengruppe gestartet werden. Diese Schritte gelten nicht für Pods, die auf AWS Fargate gestartet werden.
Finden Sie den Status Ihres Pods
Um den Pod-Status in Amazon EKS zu überprüfen, führen Sie die folgenden Schritte durch:
-
Um den Status Ihres Pods abzufragen, führen Sie den folgenden Befehl aus:
$ kubectl get pod
-
Führen Sie den folgenden Befehl aus, um Informationen aus dem Ereignis-Verlauf Ihres Pods abzurufen:
$ kubectl describe pod YOUR_POD_NAME
-
Führen Sie je nach Status Ihres Pods die Schritte im folgenden Abschnitt aus.
Ihr Pod befindet sich im Status Ausstehend
**Hinweis:**Die Beispielbefehle in den folgenden Schritten befinden sich im Standard-Namespace. Für andere Namespaces fügen Sie den Befehl mit -n YOURNAMESPACE an.
Pods können aufgrund unzureichender Ressourcen oder weil Sie einen HostPort definiert haben, im Status Pending stecken bleiben. Weitere Informationen finden Sie unter Pod-Phase auf der Kubernetes-Website.
Wenn Sie nicht über unzureichende Ressourcen auf den Worker-Knoten verfügen, löschen Sie nicht benötigte Pods. Sie können auch weitere Ressourcen auf den Worker-Knoten hinzufügen. Wenn Sie nicht über genügend Ressourcen in Ihrem Cluster verfügen, verwenden Sie den Kubernetes Cluster Autoscaler, um Ihre Worker-Knotengruppe automatisch zu skalieren.
Beispiel für unzureichende CPU:
$ kubectl describe pod frontend-cpu Name: frontend-cpu ... Status: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 22s (x14 over 13m) default-scheduler 0/3 nodes are available: 3 Insufficient cpu.
Beispiel für unzureichenden Speicher:
$ kubectl describe pod frontend-memory Name: frontend-memory ... Status: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 80s (x14 over 15m) default-scheduler 0/3 nodes are available: 3 Insufficient memory.
Wenn Sie einen HostPort für Ihren Pod definiert haben, folgen Sie diese Best Practices:
- Da die Kombination aus HostIP, HostPort und Protokoll einzigartig sein muss, geben Sie einen HostPort nur an, wenn dies erforderlich ist.
- Wenn Sie einen HostPort angeben, planen Sie die gleiche Anzahl von Pods ein, wie es Worker-Knoten gibt.
Hinweis: Wenn Sie einen Pod an einen HostPort binden, gibt es eine begrenzte Anzahl von Orten, an denen Sie einen Pod planen können.
Das folgende Beispiel zeigt die Ausgabe des Befehls describe für einen Pod, der sich im Status Pending befindet, frontend-Port-77f67cff67-2bv7w. Der Pod ist ungeplant, da der angeforderte Host-Port für Worker-Knoten im Cluster nicht verfügbar ist:
$ kubectl describe pod frontend-port-77f67cff67-2bv7w Name: frontend-port-77f67cff67-2bv7w ... Status: Pending IP: IPs: <none> Controlled By: ReplicaSet/frontend-port-77f67cff67 Containers: app: Image: nginx Port: 80/TCP Host Port: 80/TCP ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 11s (x7 over 6m22s) default-scheduler 0/3 nodes are available: 3 node(s) didn't have free ports for the requested pod ports.
Wenn Sie die Pods nicht planen können, weil die Knoten Taints haben, die der Pod nicht zulässt, dann ähnelt die Beispielausgabe der folgenden:
$ kubectl describe pod nginx Name: nginx ... Status: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 8s (x10 over 9m22s) default-scheduler 0/3 nodes are available: 3 node(s) had taint {key1: value1}, that the pod didn't tolerate.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Knoten Taints haben:
$ kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
Um Ihre Knoten-Taints beizubehalten, geben Sie in der PodSpec eine Toleranz für einen Pod an. Weitere Informationen finden Sie unter Concepts auf der Kubernetes-Website. Oder fügen Sie**-** an das Ende des Taint-Werts an, um den Knoten-Taint zu entfernen:
$ kubectl taint nodes NODE_Name key1=value1:NoSchedule-
Wenn sich Ihre Pods immer noch im Status Ausstehend befinden, führen Sie die Schritte im Abschnitt Zusätzliche Problembehandlung aus.
Ihr Container befindet sich im Status Wartend
Ihr Container befindet sich möglicherweise aufgrund eines falschen Docker-Images oder eines falschen Repository-Namens im Status Wartend. Oder Ihr Pod befindet sich möglicherweise im Status Wartend, weil das Image nicht existiert oder Sie keine Berechtigungen haben.
Um zu bestätigen, dass das Image und der Repository-Name korrekt sind, melden Sie sich bei Docker Hub, Amazon Elastic Container Registry (Amazon ECR) oder einem anderen Container-Image-Repository an. Vergleichen Sie das Repository oder Bild aus dem Repository mit dem Repository- oder Image-Namen, der in der Pod-Spezifikation angegeben ist. Wenn das Bild nicht existiert oder Sie keine Berechtigungen haben, führen Sie die folgenden Schritte aus:
-
Stellen Sie sicher, dass das angegebene Image im Repository verfügbar ist und dass die richtigen Berechtigungen konfiguriert sind, damit Sie das Image abrufen können.
-
Um sicherzustellen, dass Sie das Image abrufen können und dass es keine allgemeinen Netzwerk- und Repository-Berechtigungsprobleme gibt, ziehen Sie das Image manuell ab. Sie müssen Docker verwenden, um das Image von den Amazon EKS-Worker-Knoten abzurufen:
$ docker pull yourImageURI:yourImageTag
-
Um zu überprüfen, ob das Image existiert, überprüfen Sie, ob sich sowohl das Image als auch das Tag entweder in Docker Hub oder Amazon ECR befinden.
Hinweis: Wenn Sie Amazon ECR verwenden, stellen Sie sicher, dass die Repository-Richtlinie das Abrufen von Bildern für die NodeInstanceRole zulässt. Oder stellen Sie sicher, dass die Rolle AmazonEC2ContainerRegistryReadOnly an die Richtlinie angehängt ist.
Das folgende Beispiel zeigt einen Pod im Status Pending, wobei sich der Container aufgrund eines Image-Pull-Fehlers im Status Waiting befindet:
$ kubectl describe po web-test Name: web-test ... Status: Pending IP: 192.168.1.143 Containers: web-test: Container ID: Image: somerandomnonexistentimage Image ID: Port: 80/TCP Host Port: 0/TCP State: Waiting Reason: ErrImagePull ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 66s default-scheduler Successfully assigned default/web-test to ip-192-168-6-51.us-east-2.compute.internal Normal Pulling 14s (x3 over 65s) kubelet, ip-192-168-6-51.us-east-2.compute.internal Pulling image "somerandomnonexistentimage" Warning Failed 14s (x3 over 55s) kubelet, ip-192-168-6-51.us-east-2.compute.internal Failed to pull image "somerandomnonexistentimage": rpc error: code = Unknown desc = Error response from daemon: pull access denied for somerandomnonexistentimage, repository does not exist or may require 'docker login' Warning Failed 14s (x3 over 55s) kubelet, ip-192-168-6-51.us-east-2.compute.internal Error: ErrImagePull
Wenn sich Ihre Container immer noch im Status Wartend befinden, führen Sie die Schritte im Abschnitt Zusätzliche Problemlösung durch.
Ihr Pod befindet sich im CrashLoopBackOff-Status
Wenn Sie die Ausgabemeldung „Back-Off restarting failed container“ erhalten, wurde Ihr Container möglicherweise kurz nach dem Start des Containers durch Kubernetes beendet.
Führen Sie den folgenden Befehl aus, um in den Protokollen des aktuellen Pods nach Fehlern zu suchen:
$ kubectl logs YOUR_POD_NAME
Führen Sie den folgenden Befehl aus, um in den Protokollen des vorherigen Pods, der abgestürzt ist, nach Fehlern zu suchen:
$ kubectl logs --previous YOUR-POD_NAME
Bei einem Pod mit mehreren Containern fügen Sie den Container-Namen am Ende an. Zum Beispiel:
$ kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]
Wenn der Liveness Probe nicht den Status Erfolgreich zurückgibt, stellen Sie sicher, dass der Liveness Probe für die Anwendung richtig konfiguriert ist. Weitere Informationen finden Sie unter Probes konfigurieren auf der Kubernetes-Website.
Das folgende Beispiel zeigt einen Pod im CrashLoopBackOff-Status, weil die Anwendung nach dem Start beendet wird:
$ kubectl describe pod crash-app-b9cf4587-66ftw Name: crash-app-b9cf4587-66ftw ... Containers: alpine: Container ID: containerd://a36709d9520db92d7f6d9ee02ab80125a384fee178f003ee0b0fcfec303c2e58 Image: alpine Image ID: docker.io/library/alpine@sha256:e1c082e3d3c45cccac829840a25941e679c25d438cc8412c2fa221cf1a824e6a Port: <none> Host Port: <none> State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Completed Exit Code: 0 Started: Tue, 12 Oct 2021 12:26:21 +1100 Finished: Tue, 12 Oct 2021 12:26:21 +1100 Ready: False Restart Count: 4 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Started 97s (x4 over 2m25s) kubelet Started container alpine Normal Pulled 97s kubelet Successfully pulled image "alpine" in 1.872870869s Warning BackOff 69s (x7 over 2m21s) kubelet Back-off restarting failed container Normal Pulling 55s (x5 over 2m30s) kubelet Pulling image "alpine" Normal Pulled 53s kubelet Successfully pulled image "alpine" in 1.858871422s
Das Folgende ist ein Beispiel für einen Liveness Probe, der für den Pod fehlschlägt:
$ kubectl describe pod nginx Name: nginx ... Containers: nginx: Container ID: containerd://950740197c425fa281c205a527a11867301b8ec7a0f2a12f5f49d8687a0ee911 Image: nginx Image ID: docker.io/library/nginx@sha256:06e4235e95299b1d6d595c5ef4c41a9b12641f6683136c18394b858967cd1506 Port: 80/TCP Host Port: 0/TCP State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Completed Exit Code: 0 Started: Tue, 12 Oct 2021 13:10:06 +1100 Finished: Tue, 12 Oct 2021 13:10:13 +1100 Ready: False Restart Count: 5 Liveness: http-get http://:8080/ delay=3s timeout=1s period=2s #success=1 #failure=3 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Pulled 2m25s kubelet Successfully pulled image "nginx" in 1.876232575s Warning Unhealthy 2m17s (x9 over 2m41s) kubelet Liveness probe failed: Get "http://192.168.79.220:8080/": dial tcp 192.168.79.220:8080: connect: connection refused Normal Killing 2m17s (x3 over 2m37s) kubelet Container nginx failed liveness probe, will be restarted Normal Pulling 2m17s (x4 over 2m46s) kubelet Pulling image "nginx"
Wenn sich Ihre Pods immer noch im CrashLoopBackOff-Status befinden, führen Sie die Schritte im Abschnitt Zusätzliche Problembehandlung aus.
Ihr Pod befindet sich im Status Beenden
Wenn Ihre Pods im Status Beendigung feststecken, überprüfen Sie den Zustand des Knoten, auf dem der Pod läuft, und die Finalizers. Ein Finalizer ist eine Funktion, die eine Beendigungsverarbeitung durchführt, bevor der Pod in den Zustand Beendet übergeht. Weitere Informationen finden Sie unter Finalizers auf der Kubernetes-Website. Führen Sie den folgenden Befehl aus, um den Finalizer für den terminierenden Pod zu überprüfen:
$ kubectl get po nginx -o yaml apiVersion: v1 kind: Pod metadata: ... finalizers: - sample/do-something ...
Im vorherigen Beispiel wechselt der Pod erst zu Beendet, nachdem der sample/do-something-Finalizer entfernt worden ist. Im Allgemeinen verarbeitet ein benutzerdefinierter Controller den Finalizer und entfernt ihn dann. Der Pod wechselt dann in den Status Beendet.
Um dieses Problem zu beheben, überprüfen Sie, ob der Pod des benutzerdefinierten Controllers ordnungsgemäß ausgeführt wird. Beheben Sie alle Probleme mit dem Pod des Controllers und lassen Sie den benutzerdefinierten Controller den Finalizer-Prozess abschließen. Der Pod wechselt dann automatisch in den Status Beendet . Oder führen Sie den folgenden Befehl aus, um den Finalizer direkt zu löschen:
$ kubectl edit po nginx
Zusätzliche Problembehandlung
Wenn Ihr Pod immer noch nicht funktioniert, führen Sie die folgenden Schritte aus:
-
Führen Sie den folgenden Befehl aus, um zu bestätigen, dass sich Worker-Knoten im Cluster befinden und den Status Bereit aufweisen:
$ kubectl get nodes
Wenn der Status der Knoten NotReady lautet, lesen Sie Wie kann ich den Status meiner Knoten von NotReady oder Unknown in Ready ändern? Wenn die Knoten dem Cluster nicht beitreten können, finden Sie weitere Informationen unter Wie kann ich meine Worker-Knoten dazu bringen, meinem Amazon EKS-Cluster beizutreten?
-
Führen Sie den folgenden Befehl aus, um die Version des Kubernetes-Clusters zu überprüfen:
$ kubectl version --short
-
Führen Sie den folgenden Befehl aus, um die Version des Kubernetes-Worker-Knotens zu überprüfen:
$ kubectl get node -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion
-
Vergewissern Sie sich, dass die Kubernetes-Serverversion für den Cluster mit der Version der Worker-Knoten innerhalb eines akzeptablen Versionsversatzes übereinstimmt. Weitere Informationen finden Sie unter Versionsverzerrungsrichtlinie auf der Kubernetes-Website.
Wichtig: Die Patch-Versionen können zwischen Cluster und Worker-Knoten unterschiedlich sein, z. B. v1.21.x für den Cluster und v1.21.y für den Worker-Knoten. Wenn die Cluster- und Worker-Knotenversionen nicht kompatibel sind, verwenden Sie eksctl oder AWS CloudFormation, um eine neue Knotengruppe zu erstellen. Oder verwenden Sie eine kompatible Kubernetes-Version, um eine neue verwaltete Knotengruppe zu erstellen, z. B. Kubernetes: v1.21, Plattform: eks.1 und höher. Löschen Sie dann die Knotengruppe, die die inkompatible Kubernetes-Version enthält. -
Vergewissern Sie sich, dass die Kubernetes-Kontrollebene mit den Worker-Knoten kommunizieren kann. Vergleichen Sie die Firewallregeln mit den erforderlichen Regeln in den Anforderungen und Überlegungen zur Amazon EKS-Sicherheitsgruppe. Stellen Sie dann sicher, dass sich die Knoten im Status Bereit befinden.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 10 Monaten
- AWS OFFICIALAktualisiert vor einem Monat