Wie behebe ich Probleme mit Kubernetes-Pods in Amazon EKS?

Lösung

Den Fehler ermitteln, der das Pod-Problem verursacht

1. Führe den folgenden Befehl kubectl describe aus, um Informationen über die Pods abzurufen:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Hinweis: Ersetze YOUR_POD_NAME durch deinen Pod-Namen und YOUR_NAMESPACE durch deinen Namespace.

2. Identifiziere die Fehlermeldung im Abschnitt Ereignisse der Befehlsausgabe.

   Beispielausgabe:

   Events:
     Type     Reason            Age                From               Message
     ----     ------            ----               ----               -------
     Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
     Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

Gehe auf der Grundlage der erhaltenen Fehlermeldung wie folgt vor, um das Pod-Problem zu lösen.

Probleme beim Einbinden von EBS-Volumes

Die folgende Beispielausgabe stammt aus einem kubectl describe pod ebs-pod-Befehl. Die Ausgabe zeigt einen Volume-Knoten-Affinitätsfehler beim Einbinden von Amazon Elastic Block Store (Amazon EBS)-Volumes:

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

Der vorherige Fehler tritt auf, wenn du Persistent Volume Claims (PVCs, Anforderungen für persistenten Speicher) für den Pod in mehreren Availability Zones planst. Du kannst den Pod nicht planen, da der Pod keine Verbindung zum Volume aus einer anderen Availability Zone herstellen kann. Um dieses Problem zu beheben, musst du PVCs in einer Availability Zone planen.

Führe die folgenden Schritte aus, um den vorherigen Fehler zu beheben:

1. Um Informationen über alle PVCs in deinem Namespace abzurufen, führe den folgenden Befehl kubectl get pvc aus:

   kubectl get pvc -n YOUR_NAMESPACE

   Hinweis: Ersetze YOUR_NAMESPACE durch deinen Namespace.

2. Führe den folgenden Befehl kubectl get pv aus, um Informationen über das Persistent Volume (PV) abzurufen:

   kubectl get pv

3. Führe den folgenden Befehl kubectl describe pv aus, um das PV zu finden, das deinem PC entspricht:

   kubectl describe pv your_PV

   Hinweis: Ersetze your_PV durch den Namen deines PVs.

4. Vergewissere dich, dass die Volume-ID, die du vom vorherigen Befehl erhältst, der richtigen Availability Zone zugeordnet ist.

5. Überprüfe den Knoten, auf dem sich die Availability Zone befindet.

Wenn ein Volume-Knoten-Affinitätskonflikt auftritt, führe eine der folgenden Aktionen aus:

• Verwende Taints und Toleranzen, um sicherzustellen, dass Pods, die das Amazon-EBS-Einbinden verwenden, auf dem richtigen Knoten geplant werden. Der Knoten muss sich in der Availability Zone befinden, in der sich das EBS-Volume befindet. Weitere Informationen findest du unter Taints and Tolerations (Taints und Toleranzen) auf der Kubernetes-Website.
• Verwende StatefulSets anstelle einer Bereitstellung, um für jeden Pod im StatefulSet ein eindeutiges EBS-Volume in derselben Availability Zone zu erstellen. Weitere Informationen findest du unter StatefulSets auf der Kubernetes-Website.

Der Pod oder StatefulSet steckt möglicherweise im Status Ausstehend fest. Dies gilt auch dann, wenn sich der Pod oder StatefulSet in derselben Availability Zone wie das EBS-Volume befindet. Um dieses Problem zu beheben, führe den folgenden kubectl logs-Befehl aus, um die Protokolle der Treiber-Pods von Amazon EBS CSI zu überprüfen:

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

Hinweis: Ersetze your-ebs-csi-controller durch deinen Amazon-EBS-CSI-Controller. Ersetze außerdem your-kube-system durch deinen vordefinierten Namespace und your-csi-provisioner durch einen Container-Namen, den du zum Abrufen von Protokollen verwendest.

ContainerCreating-Zustandsfehler

Die folgende Fehlermeldung tritt auf, wenn der Pod im Status ContainerCreating feststeckt und das networkPlugin: cni dem Pod keine IP-Adresse zuweist:

„Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container.“

Gehe wie folgt vor, um den Zustandsfehler ContainerCreating zu beheben:

• Prüfe, ob das Subnetz über eine verfügbare IP-Adresse verfügt, um das Problem zu lösen. Öffne die Amazon Virtual Private Cloud (Amazon VPC)-Konsole. Wähle im Navigationsbereich unter Virtual Private Cloud die Option Subnetze aus.
• Stelle sicher, dass sich der Pod für aws-node im Status Wird ausgeführt befindet. Stelle außerdem sicher, dass du die neueste unterstützte Version von Amazon VPC CNI verwendest.
• Prüfe, ob die Anzahl der Pods auf der Instance die maximale Anzahl von Pods erreicht hat.
• Suche in dem Knoten, in dem du den Pod geplant hast, in den ipamd-Protokollen und im Plug-in unter dem Pfad var/log/aws-routed-eni nach Fehlermeldungen.

CrashLoopBackOff-Zustandsfehler

Du erhältst die Fehlermeldung „Back-Off restarting failed container“.

Die vorherige Fehlermeldung tritt auf, weil der Container wiederholt nicht gestartet werden kann und dann in den Status CrashLoopBackOff übergeht und innerhalb des Pods kontinuierlich neu gestartet wird.

Die folgenden Probleme können dazu führen, dass der Container wiederholt nicht gestartet werden kann:

• Ungenügender Speicher
• Überlastung der Ressourcen
• Fehler bei der Bereitstellung
• Externe Abhängigkeitsprobleme wie DNS-Fehler
• Abhängigkeiten von Drittanbietern
• Durch Portkonflikte verursachte Ausfälle auf Containerebene

Führe den folgenden kubectl logs-Befehl aus, um die Fehler in den Protokollen des aktuellen Pods abzurufen:

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

Hinweis: Ersetze YOUR_POD_NAME durch deinen Pod-Namen und YOUR_NAMESPACE durch deinen Namespace.

Führe den folgenden Befehl kubectl logs --previous aus, um Fehler in den Protokollen des vorherigen Pods abzurufen, der abgestürzt ist:

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

Hinweis: Ersetze YOUR_POD_NAME durch deinen Pod-Namen und YOUR_NAMESPACE durch deinen Namespace.

Fehler bei Testfehlschlägen

Wenn ein Pod abstürzt, wird aufgrund einer abgelehnten Verbindung oder eines Client-Timeouts ein Fehler bei Testfehlschlägen angezeigt.

Problembehandlung bei einer abgelehnten Verbindung

Wenn ein Test aufgrund einer abgelehnten Verbindung fehlgeschlagen ist, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• „Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused.“
• „Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused.“

Gehe wie folgt vor, um eine abgelehnte Verbindung zu beheben:

1. Führe den folgenden Befehl aus, um den im Pod-Manifest definierten Zustandsprüfungspfad manuell vom Worker-Knoten abzurufen:

   [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

   Hinweis: Ersetze podIP durch die IP-Adresse deines Pods und your_healthcheck_path durch deinen Pfadnamen.

2. Überprüfe den Zustandsprüfungspfad, der im Pod-Manifest für den Pod definiert ist, bei dem der Live-Test oder Bereitschaftstest fehlgeschlagen ist. Führe den folgenden Befehl aus, um den Zustandsprüfungspfad zu überprüfen:

   local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

   Hinweis: Ersetze YOUR_POD_NAME durch den Namen deines Pods.

3. Führe dasselbe Container-Image auf dem Bastion-Host aus.

4. Prüfe, ob du den Zustandsprüfungspfad abrufen kannst, der für die Tests im Manifest definiert ist. Überprüfe dann die Container-Protokolle auf Ausfälle, Timeouts oder Fehler.

5. Führe den folgenden journalctl-Befehl aus, um die kubelet-Protokolle des Worker-Knotens, auf dem der Pod ausgeführt wird, auf Fehler zu überprüfen:

   [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

Problembehandlung bei einem Client-Timeout

Wenn eine Prüfung aufgrund eines Client-Timeouts fehlgeschlagen ist, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• „Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers).“
• „Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers).“

Um das Client-Timeout zu beheben, überprüfe, ob die Konfiguration für die Live- und Bereitschaftstests für deine Anwendungs-Pods korrekt ist.

Wenn du eine Sicherheitsgruppe für Pods und ENABLE_POD_ENI=true verwendest, musst du TCP early demux deaktivieren. Mit dieser Aktion kann das Kubelet eine Verbindung zu den Pods auf den Zweignetzwerkschnittstellen herstellen, die TCP verwenden.

Um TCP early demux zu deaktivieren, führe den folgenden kubectl patch-Befehl aus:

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

ImagePullBackOff-Fehler

Der ImagePullBackOff-Fehler tritt auf, wenn ein Container, der in einem Pod ausgeführt wird, das erforderliche Image nicht aus einer Containerregistrierung abrufen kann.

Die folgenden Probleme können diesen Fehler verursachen:

• Probleme mit der Netzwerkverbindung
• Falscher Image-Name oder falsches Tag
• Fehlende Anmeldeinformationen
• Unzureichende Berechtigungen

Gehe wie folgt vor, um die Ursache des Problems zu ermitteln:

1. Führe den folgenden Befehl aus, um den Status des Pods abzufragen:

   kubectl get pods -n YOUR_NAMESPACE

   Hinweis: Ersetze YOUR_NAMESPACE durch deinen Namespace.

2. Führe den folgenden Befehl aus, um Fehlerdetails zu deinem Pod abzurufen:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Hinweis: Ersetze YOUR_POD_NAME durch deinen Pod-Namen und YOUR_NAMESPACE durch deinen Namespace.

   Beispielausgabe:

   Events:
   Type     Reason     Age                From                Message
   ----     ------     ----               ----                -------
   Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
   Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
   Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

Informationen zur Behebung des ImagePullBackOff-Fehlers findest du unter Wie kann ich die Pod-Status-Fehler ErrImagePull und ImagePullBackoff in Amazon EKS beheben?