Probleme mit bereitgestellten Arbeitslasten beheben

Auf dieser Seite wird beschrieben, wie Sie Fehler bei bereitgestellten Arbeitslasten in Google Kubernetes Engine (GKE) beheben.

Allgemeine Informationen zur Fehlerbehebung bei Anwendungen finden Sie in der Kubernetes-Dokumentation unter Fehlerbehebung bei Anwendungen.

Alle Fehler: Pod-Status prüfen

Bei Problemen mit den Pods einer Arbeitslast wird der Pod-Status von Kubernetes mit einer Fehlermeldung aktualisiert. Sie können diese Fehler einsehen, indem Sie den Status eines Pods in der Trusted Cloud -Konsole oder mit dem kubectl-Befehlszeilentool prüfen.

kubectl get pods

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

kubectl describe pod POD_NAME

kubectl logs POD_NAME

Nachdem Sie den Fehler identifiziert haben, können Sie versuchen, das Problem mithilfe der folgenden Abschnitte zu beheben.

Fehler: CrashLoopBackOff

Ein Status von CrashLoopBackOff bedeutet nicht, dass ein bestimmter Fehler vorliegt. Er gibt stattdessen an, dass ein Container nach dem Neustart wiederholt abstürzt. Wenn ein Container abstürzt oder kurz nach dem Start beendet wird (CrashLoop), versucht Kubernetes, den Container neu zu starten. Bei jedem fehlgeschlagenen Neustart erhöht sich die Verzögerung (BackOff) vor dem nächsten Versuch exponentiell (10 s, 20 s, 40 s usw.) auf maximal fünf Minuten.

In den folgenden Abschnitten erfahren Sie, warum Ihr Container abstürzen könnte.

Interaktives Playbook für Pods in Absturzschleifen verwenden

Beginnen Sie mit der Fehlerbehebung, um die Ursache für den Status CrashLoopBackOff zu ermitteln. Verwenden Sie dazu das interaktive Playbook in der Trusted Cloud Console:

1. Rufen Sie das Interaktive Playbook für Pods in Absturzschleifen auf:

   Zum Playbook

2. Wählen Sie in der Drop-down-Liste Cluster den Cluster aus, bei dem Sie Fehler beheben möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie den Namen des Clusters in das Feld filter_list Filter ein.

3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld filter_list Filtern ein.

4. Gehen Sie die einzelnen Abschnitte durch, um die Ursache zu ermitteln:

   1. Anwendungsfehler ermitteln
   2. Probleme durch unzureichenden Arbeitsspeicher untersuchen
   3. Knotenstörungen untersuchen
   4. Fehlgeschlagene Aktivitätsprüfungen untersuchen
   5. Änderungsereignisse korrelieren

5. Optional: Wenn Sie Benachrichtigungen zu zukünftigen CrashLoopBackOff-Fehlern erhalten möchten, wählen Sie im Abschnitt Future Mitigation Tips (Tipps zur zukünftigen Fehlerbehebung) die Option Create an Alert (Benachrichtigung erstellen) aus.

Logs prüfen

Ein Container kann aus verschiedenen Gründen abstürzen. Hier kann ein Blick in die Logs eines Pods helfen, die Ursache zu beheben.

Sie können die Logs mit der Trusted Cloud -Konsole oder dem kubectl-Befehlszeilentool prüfen.

Exit-Code des abgestürzten Containers überprüfen

So finden Sie den Exit-Code, um besser nachvollziehen zu können, warum Ihr Container abgestürzt ist:

1. Beschreiben Sie den Pod:

   kubectl describe pod POD_NAME
   

   Ersetzen Sie POD_NAME durch den Namen des problematischen Pods.

2. Prüfen Sie den Wert im Feld containers: CONTAINER_NAME: last state: exit code:

   • Lautet der Exit-Code 1, ist ein Absturz der Anwendung der Grund dafür, dass der Container abgestürzt ist.
   • Lautet der Exit-Code 0, stellen Sie fest, wie lange die App ausgeführt wurde. Container werden beendet, wenn der Hauptprozess der Anwendung beendet wird. Wird die Ausführung einer Anwendung sehr schnell beendet, ist es möglich, dass der Container weiter neu gestartet wird. Wenn dieser Fehler auftritt, können Sie das Feld restartPolicy auf OnFailure festlegen. Nach dieser Änderung wird die App nur neu gestartet, wenn der Exit-Code nicht 0 ist.

Verbindung zu einem ausgeführten Container herstellen

Wenn Sie Bash-Befehle aus dem Container ausführen möchten, um das Netzwerk zu testen oder zu prüfen, ob Sie Zugriff auf Dateien oder Datenbanken haben, die von der Anwendung verwendet werden, öffnen Sie eine Shell für den Pod:

kubectl exec -it POD_NAME -- /bin/bash

Wenn sich in Ihrem Pod mehrere Container befinden, fügen Sie -c CONTAINER_NAME hinzu.

Fehler: ImagePullBackOff und ErrImagePull

Ein Status von ImagePullBackOff oder ErrImagePull gibt an, dass das von einem Container verwendete Image nicht aus der Image-Registry geladen werden kann.

Eine Anleitung zur Fehlerbehebung bei diesen Status finden Sie unter Fehlerbehebung beim Pullen von Images.

Fehler: Pod nicht planbar

Der Status PodUnschedulable gibt an, dass Ihr Pod aufgrund unzureichender Ressourcen oder eines Konfigurationsfehlers nicht geplant werden kann.

Wenn Sie Messwerte der Steuerungsebene konfiguriert haben, finden Sie weitere Informationen zu diesen Fehlern unter Planermesswerte und API-Servermesswerte.

Interaktives Playbook für nicht planbare Pods verwenden

Sie können PodUnschedulable-Fehler mithilfe des interaktiven Playbooks in der Trusted Cloud -Konsole beheben:

1. Rufen Sie das Interaktive Playbook für nicht planbare Pods auf:

   Zum Playbook

2. Wählen Sie in der Drop-down-Liste Cluster den Cluster aus, bei dem Sie Fehler beheben möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie den Namen des Clusters in das Feld filter_list Filter ein.

3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld filter_list Filtern ein.

4. Um die Ursache zu ermitteln, arbeiten Sie die einzelnen Abschnitte im Playbook durch:

   1. CPU und Arbeitsspeicher untersuchen
   2. Maximale Anzahl von Pods pro Knoten untersuchen
   3. Autoscaling-Verhalten untersuchen
   4. Andere Fehlermodi untersuchen
   5. Änderungsereignisse korrelieren

5. Optional: Wenn Sie Benachrichtigungen zu zukünftigen PodUnschedulable-Fehlern erhalten möchten, wählen Sie im Abschnitt Future Mitigation Tips (Tipps zur zukünftigen Fehlerbehebung) die Option Create an Alert (Benachrichtigung erstellen) aus .

Fehler: Unzureichende Ressourcen

Möglicherweise stoßen Sie auf einen Fehler, der auf zu wenig CPU-Kapazität, Arbeitsspeicher oder andere Ressourcen hinweist. Beispiel: No nodes are available that match all of the predicates: Insufficient cpu (2). Dies weist darauf hin, dass auf zwei Knoten nicht genügend CPU-Kapazität verfügbar ist, um die Anfragen eines Pods zu erfüllen.

Wenn die Ressourcenanforderungen Ihres Pods die eines einzelnen Knotens aus einem der infrage kommenden Knotenpools überschreiten, plant GKE den Pod nicht und löst auch keine Aufskalierung aus, um einen neuen Knoten hinzuzufügen. Damit GKE den Pod planen kann, müssen Sie entweder weniger Ressourcen für den Pod anfordern oder einen neuen Knotenpool mit ausreichenden Ressourcen erstellen.

Sie können auch die automatische Knotenbereitstellung aktivieren, damit GKE automatisch Knotenpools mit Knoten erstellen kann, auf denen die nicht geplanten Pods ausgeführt werden können.

Die Standard-CPU-Anfrage beträgt 100 MB oder 10 % einer CPU bzw. eines Kerns. Wenn Sie mehr oder weniger Ressourcen anfordern möchten, geben Sie den Wert in der Pod-Spezifikation unter spec: containers: resources: requests an.

Fehler: MatchNodeSelector

Der Fehler MatchNodeSelector gibt an, dass keine Knoten vorhanden sind, die mit der Labelauswahl des Pods übereinstimmen.

Sehen Sie sich in der Pod-Spezifikation unter spec: nodeSelector die im Feld nodeSelector angegebenen Labels an, um das zu prüfen.

Führen Sie den folgenden Befehl aus, um sich die Labels von Knoten in Ihrem Cluster anzusehen:

kubectl get nodes --show-labels

Führen Sie den folgenden Befehl aus, um einem Knoten ein Label hinzuzufügen:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Ersetzen Sie Folgendes:

• NODE_NAME: Der Knoten, dem Sie ein Label hinzufügen möchten.
• LABEL_KEY: der Schlüssel des Labels
• LABEL_VALUE: der Wert des Labels

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pods zu Knoten zuweisen.

Fehler: PodToleratesNodeTaints

Der Fehler PodToleratesNodeTaints gibt an, dass der Pod für keinen Knoten geplant werden kann, da der Pod keine Toleranzen hat, die den vorhandenen Knotenmarkierungen entsprechen.

Führen Sie den folgenden Befehl aus, um dies zu ermitteln:

kubectl describe nodes NODE_NAME

Prüfen Sie in der Ausgabe das Feld Taints. Darin sind Schlüssel/Wert-Paare und Planungseffekte aufgeführt.

Lautet der aufgeführte Effekt NoSchedule, können Pods auf diesem Knoten nur geplant werden, wenn sie eine übereinstimmende Toleranz haben.

Eine Möglichkeit zur Behebung dieses Problems ist, die Markierung zu entfernen. Führen Sie beispielsweise den folgenden Befehl aus, um eine NoSchedule-Markierung zu entfernen:

kubectl taint nodes NODE_NAME key:NoSchedule-

Fehler: PodFitsHostPorts

Der Fehler PodFitsHostPorts bedeutet, dass ein Knoten versucht, einen Port zu verwenden, der bereits belegt ist.

Um das Problem zu beheben, sollten Sie die Kubernetes-Best Practices beachten und einen NodePort anstelle eines hostPort verwenden.

Wenn Sie eine hostPort verwenden müssen, prüfen Sie die Manifeste der Pods und achten Sie darauf, dass für alle Pods auf demselben Knoten eindeutige Werte für hostPort definiert sind.

Fehler: Keine Mindestverfügbarkeit vorhanden

Wenn für einen Knoten genügend Ressourcen vorhanden sind, die Meldung Does not have minimum availability jedoch immer noch angezeigt wird, prüfen Sie den Status des Pods. Wenn er SchedulingDisabled oder Cordoned lautet, kann der Knoten keine neuen Pods planen. Sie können den Status eines Knotens in der Trusted Cloud -Konsole oder mit dem kubectl-Befehlszeilentool prüfen.

kubectl get nodes

kubectl uncordon NODE_NAME

Fehler: Das Limit für die maximale Anzahl von Pods pro Knoten wurde erreicht

Wenn das Limit für Maximale Anzahl von Pods pro Knoten für alle Knoten im Cluster erreicht ist, bleiben die Pods im Status „Nicht planbar“ hängen. Auf dem Tab Ereignisse des Pods wird eine Nachricht mit dem Ausdruck Too many pods angezeigt.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Prüfen Sie die Maximum pods per node-Konfiguration auf dem Tab „Knoten“ in den GKE-Clusterdetails in der Trusted Cloud -Konsole.

2. Rufen Sie eine Liste der Knoten ab:

   kubectl get nodes
   

3. Prüfen Sie für jeden Knoten die Anzahl der Pods, die auf dem Knoten ausgeführt werden:

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. Wenn das Limit erreicht ist, fügen Sie einen neuen Knotenpool oder zusätzliche Knoten zum vorhandenen Knotenpool hinzu.

Problem: Maximale Knotenpoolgröße mit aktiviertem Cluster Autoscaler erreicht

Wenn der Knotenpool seine Maximalgröße gemäß der Cluster-Autoscaling-Konfiguration erreicht hat, löst GKE keine vertikale Skalierung für den Pod aus, der andernfalls mit diesem Knotenpool geplant wäre. Wenn Sie möchten, dass der Pod mit diesem Knotenpool geplant wird, ändern Sie die Cluster-Autoscaling-Konfiguration.

Problem: Maximale Knotenpoolgröße erreicht, Cluster Autoscaler deaktiviert

Wenn der Knotenpool die maximale Anzahl von Knoten erreicht hat und Cluster Autoscaler deaktiviert ist, kann GKE den Pod nicht mit dem Knotenpool planen. Erhöhen Sie die Größe Ihres Knotenpools oder aktivieren Sie Cluster Autoscaler für GKE, damit die Größe Ihres Clusters automatisch angepasst wird.

Fehler: Ungebundene PersistentVolumeClaims

Der Fehler Unbound PersistentVolumeClaims gibt an, dass der Pod auf einen nicht gebundenen PersistentVolumeClaim verweist. Dieser Fehler kann auftreten, wenn das PersistentVolume nicht bereitgestellt werden konnte. Sie können prüfen, ob die Bereitstellung fehlgeschlagen ist. Dazu rufen Sie die Ereignisse für den PersistentVolumeClaim ab und untersuchen sie auf Fehler.

Führen Sie den folgenden Befehl aus, um Ereignisse abzurufen:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Dabei gilt:

• STATEFULSET_NAME: Name des StatefulSet-Objekts.
• PVC_NAME: Name des PersistentVolumeClaim-Objekts.

Dies kann auch passieren, wenn während der manuellen Vorabbereitstellung eines PersistentVolume und der Bindung an einen PersistentVolumeClaim ein Konfigurationsfehler aufgetreten ist.

Um diesen Fehler zu beheben, versuchen Sie, das Volume noch einmal vorab bereitzustellen.

Fehler: Unzureichendes Kontingent

Prüfen Sie, ob Ihr Projekt ein ausreichendes Compute Engine-Kontingent für GKE hat, um Ihren Cluster zu skalieren. Wenn GKE versucht, Ihrem Cluster einen Knoten hinzuzufügen, um den Pod zu planen, und das Hochskalieren das verfügbare Kontingent Ihres Projekts überschreiten würde, erhalten Sie die Fehlermeldung scale.up.error.quota.exceeded.

Weitere Informationen finden Sie unter ScaleUp-Fehler.

Problem: Eingestellte APIs

Achten Sie darauf, dass Sie keine eingestellten APIs verwenden, die mit der Nebenversion Ihres Clusters entfernt werden. Weitere Informationen finden Sie unter Einstellung von Funktionen und APIs.

Fehler: Es waren keine freien Ports für die angeforderten Pod-Ports verfügbar.

Wenn Sie einen Fehler wie den folgenden sehen, haben Sie wahrscheinlich mehrere Pods auf demselben Knoten mit demselben Wert, der im Feld hostPort definiert ist:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Durch das Binden eines Pods an ein hostPort wird eingeschränkt, wo GKE den Pod planen kann, da jede Kombination aus hostIP, hostPort und protocol eindeutig sein muss.

Um das Problem zu beheben, sollten Sie die Kubernetes-Best Practices beachten und einen NodePort anstelle eines hostPort verwenden.

Wenn Sie eine hostPort verwenden müssen, prüfen Sie die Manifeste der Pods und achten Sie darauf, dass für alle Pods auf demselben Knoten eindeutige Werte für hostPort definiert sind.

Nächste Schritte

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen:

  • Sie können eine Supportanfrage erstellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag google-kubernetes-engine nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
  • Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.