Wie kann ich den Pod-Status in Amazon EKS beheben?

Lesedauer: 10 Minute
0

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:

  1. Um den Status Ihres Pods abzufragen, führen Sie den folgenden Befehl aus:

    $ kubectl get pod
  2. Führen Sie den folgenden Befehl aus, um Informationen aus dem Ereignis-Verlauf Ihres Pods abzurufen:

    $ kubectl describe pod YOUR_POD_NAME
  3. 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:

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

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

  1. 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?

  2. Führen Sie den folgenden Befehl aus, um die Version des Kubernetes-Clusters zu überprüfen:

    $ kubectl version --short
  3. 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
  4. 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.

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

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 3 Monaten