Probleme mit bereitgestellten Arbeitslasten beheben

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

Allgemeinere Tipps 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 aktualisiert Kubernetes den Pod-Status mit einer Fehlermeldung. Sie können diese Fehler prüfen, indem Sie den Status eines Pods in der Google Cloud Console oder mit dem kubectl-Befehlszeilentool prüfen.

Consolekubectl

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Wählen Sie die Arbeitslast aus, die Sie prüfen möchten. Auf dem Tab Übersicht wird der Status der Arbeitslast angezeigt.

  3. Klicken Sie im Abschnitt Verwaltete Pods auf eine Fehlerstatusmeldung.

Führen Sie den folgenden Befehl aus, um alle in Ihrem Cluster ausgeführten Pods anzusehen:

kubectl get pods

Die Ausgabe sieht in etwa so aus:

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

Potenzielle Fehler sind in der Spalte Status aufgeführt.

Führen Sie den folgenden Befehl aus, um weitere Details zu einem bestimmten Pod abzurufen:

kubectl describe pod POD_NAME

Ersetzen Sie POD_NAME durch den Namen des Pods, den Sie sich prüfen möchten.

In der Ausgabe enthält das Feld Events weitere Informationen zu Fehlern.

Weitere Informationen finden Sie in den Container-Logs:

kubectl logs POD_NAME

Anhand dieser Logs können Sie feststellen, ob ein Befehl oder Code im Container den Absturz des Pods verursacht hat.

Nachdem Sie den Fehler identifiziert haben, können Sie in den folgenden Abschnitten versuchen, das Problem zu beheben.

Fehler: CrashLoopBackOff

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

In den folgenden Abschnitten erfahren Sie, warum Ihr Container möglicherweise abstürzt.

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 Google Cloud Console:

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

    Playbook aufrufen

  2. Wählen Sie in der Drop-down-Liste Cluster den Cluster aus, für den Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie seinen Namen in das Feld Filter ein.

  3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie Fehler beheben möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld Filter 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 über zukünftige CrashLoopBackOff-Fehler benachrichtigt werden möchten, wählen Sie im Abschnitt Tipps zur zukünftigen Behebung die Option 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 Protokolle mit der Google Cloud Console oder dem kubectl-Befehlszeilentool prüfen.

Consolekubectl

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Wählen Sie die Arbeitslast aus, die Sie prüfen möchten. Auf dem Tab Übersicht wird der Status der Arbeitslast angezeigt.

  3. Klicken Sie im Abschnitt Verwaltete Pods auf den problematischen Pod.

  4. Klicken Sie im Menü des Pods auf den Tab Logs.

  1. So rufen Sie alle in Ihrem Cluster ausgeführten Pods auf:

    kubectl get pods

  2. Suchen Sie in der Ausgabe des vorherigen Befehls in der Spalte Status nach einem Pod mit dem Fehler CrashLoopBackOff.

  3. Rufen Sie die Logs des Pods ab:

    kubectl logs POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des problematischen Pods.

    Wenn Sie das Flag -p übergeben, können Sie außerdem die Logs der vorherigen Instanz des Containers eines Pods abrufen, falls vorhanden.

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

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

  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.
    • Wenn der Exit-Code 0 ist, prüfen Sie, wie lange die Anwendung 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 dann neu gestartet, wenn der Beendigungscode 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 Ihrer 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 bei Bildabrufen.

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 mit dem interaktiven Playbook in der Google Cloud Console beheben:

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

    Playbook aufrufen

  2. Wählen Sie in der Drop-down-Liste Cluster den Cluster aus, für den Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie den Namen des Clusters in das Feld Filter ein.

  3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie Fehler beheben möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld Filter ein.

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

    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 über zukünftige PodUnschedulable-Fehler benachrichtigt werden möchten, wählen Sie im Abschnitt Tipps zur zukünftigen Behebung die Option 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 Ressourcenanfragen Ihres Pods die eines einzelnen Knotens aus allen infrage kommenden Knotenpools überschreiten, wird der Pod von GKE nicht geplant und es wird auch kein vertikales Skalieren ausgelöst, 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 gibt an, dass ein Knoten versucht, einen Port zu verwenden, der bereits belegt ist.

Um das Problem zu beheben, können Sie die Best Practices für Kubernetes befolgen und statt eines hostPort ein NodePort 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 Google Cloud Console oder dem kubectl-Befehlszeilentool prüfen.

Consolekubectl

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Wählen Sie den gewünschten zu prüfenden Cluster aus. Auf dem Tab Knoten werden die Knoten und ihr Status angezeigt.

Führen Sie die folgenden Schritte aus, um die Planung auf dem Knoten zu aktivieren:

  1. Klicken Sie in der Liste auf den Knoten, den Sie untersuchen möchten.

  2. Klicken Sie im Bereich Knotendetails auf Entsperren.

Führen Sie den folgenden Befehl aus, um die Status der Knoten abzurufen:

kubectl get nodes

Die Planung auf dem Knoten aktivieren Sie mit folgendem Befehl:

kubectl uncordon NODE_NAME

Fehler: Maximale Anzahl von Pods pro Knoten erreicht

Wenn das Limit für die maximale Anzahl von Pods pro Knoten von allen Knoten im Cluster erreicht wird, befinden sich die Pods im Status „Nicht planbar“. Auf dem Tab Ereignisse des Pods sehen Sie eine Nachricht mit dem Begriff Too many pods.

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 Google Cloud Console.

  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 dem vorhandenen Knotenpool zusätzliche Knoten hinzu.

Problem: Maximale Knotenpoolgröße bei aktivierter 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 der Pod mit diesem Knotenpool geplant werden soll, ändern Sie die Cluster-Autoscaling-Konfiguration.

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

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

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 die Skalierung 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 veralteten APIs verwenden, die mit der Nebenversion Ihres Clusters entfernt werden. Weitere Informationen finden Sie unter Verworfene Komponenten von GKE.

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

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

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.

Wenn Sie einen Pod an eine hostPort binden, schränkt das ein, wo GKE den Pod planen kann, da jede Kombination aus hostIP, hostPort und protocol eindeutig sein muss.

Um das Problem zu beheben, können Sie die Best Practices für Kubernetes befolgen und statt eines hostPort ein NodePort 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 weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.