Fehlerbehebung bei CrashLoopBackOff-Ereignissen

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Pods beheben, bei denen CrashLoopBackOff-Ereignisse in Google Kubernetes Engine (GKE) auftreten.

Diese Seite richtet sich an Anwendungsentwickler, die Probleme auf App-Ebene wie Konfigurationsfehler oder codebezogene Fehler ermitteln möchten, die zum Absturz ihrer Container führen. Es ist auch für Plattformadministratoren und ‑operatoren gedacht, die Ursachen auf Plattformebene für Containerneustarts ermitteln müssen, z. B. Ressourcenerschöpfung, Knotenunterbrechungen oder falsch konfigurierte Aktivitätsprüfungen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Trusted Cloud by S3NS -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

CrashLoopBackOff-Ereignisse verstehen

Wenn sich Ihr Pod im Status CrashLoopBackOff befindet, wird ein Container darin wiederholt gestartet und stürzt ab oder wird beendet. Dieser CrashLoop löst aus, dass Kubernetes versucht, den Container gemäß seiner restartPolicy neu zu starten. Bei jedem fehlgeschlagenen Neustart erhöht sich die BackOff-Verzögerung vor dem nächsten Versuch exponentiell (z. B. 10 s, 20 s, 40 s) auf maximal fünf Minuten.

Dieses Ereignis deutet zwar auf ein Problem in Ihrem Container hin, ist aber auch ein wertvolles Diagnosesignal. Ein CrashLoopBackOff-Ereignis bestätigt, dass viele grundlegende Schritte der Pod-Erstellung, z. B. die Zuweisung zu einem Knoten und das Pullen des Container-Images, bereits abgeschlossen sind. So können Sie sich bei der Untersuchung auf die App oder Konfiguration des Containers konzentrieren und müssen sich nicht mit der Clusterinfrastruktur befassen.

Der Status CrashLoopBackOff tritt aufgrund der Art und Weise auf, wie Kubernetes, insbesondere das Kubelet, die Beendigung von Containern basierend auf der Neustartrichtlinie des Pods behandelt. Der Zyklus folgt in der Regel diesem Muster:

1. Der Container wird gestartet.
2. Der Container wird beendet.
3. Das Kubelet beobachtet den angehaltenen Container und startet ihn gemäß der restartPolicy des Pods neu.
4. Dieser Zyklus wird wiederholt, wobei der Container nach einer zunehmenden exponentiellen Backoff-Verzögerung neu gestartet wird.

Der restartPolicy des Pods ist der Schlüssel zu diesem Verhalten. Die Standardrichtlinie Always ist die häufigste Ursache für diese Schleife, da sie einen Container neu startet, wenn er aus irgendeinem Grund beendet wird, auch nach einem erfolgreichen Beenden. Die Richtlinie OnFailure führt seltener zu einer Schleife, da sie nur bei Exit-Codes ungleich null neu gestartet wird. Die Richtlinie Never vermeidet einen Neustart vollständig.

Symptome eines CrashLoopBackOff-Ereignisses erkennen

Ein Pod mit dem Status CrashLoopBackOff ist der primäre Hinweis auf ein CrashLoopBackOff-Ereignis.

Es gibt jedoch auch weniger offensichtliche Symptome eines CrashLoopBackOff-Ereignisses:

• Keine fehlerfreien Replikate für eine Arbeitslast.
• Ein starker Rückgang der fehlerfreien Replikate.
• Arbeitslasten mit aktiviertem horizontalen Pod-Autoscaling werden langsam skaliert oder können nicht skaliert werden.

Wenn eine system-Arbeitslast (z. B. ein Logging- oder Messwerte-Agent) den Status CrashLoopBackOff hat, können auch die folgenden Symptome auftreten:

• Einige GKE-Messwerte werden nicht gemeldet.
• Einige GKE-Dashboards und ‑Diagramme weisen Lücken auf.
• Verbindungsprobleme auf Pod-Ebene.

Wenn Sie eines dieser weniger offensichtlichen Symptome feststellen, sollten Sie als Nächstes prüfen, ob ein CrashLoopBackOff-Ereignis aufgetreten ist.

CrashLoopBackOff-Ereignis bestätigen

Um ein CrashLoopBackOff-Ereignis zu bestätigen und zu untersuchen, sammeln Sie Beweise aus Kubernetes-Ereignissen und den App-Logs des Containers. Diese beiden Quellen bieten unterschiedliche, aber sich ergänzende Perspektiven auf das Problem:

• Kubernetes-Ereignisse bestätigen, dass ein Pod abstürzt.
• In den App-Logs des Containers können Sie nachsehen, warum der Prozess im Container fehlschlägt.

Wählen Sie eine der folgenden Optionen aus, um diese Informationen aufzurufen:

Interaktives Playbook für Pods in Absturzschleifen verwenden

Nachdem Sie ein CrashLoopBackOff-Ereignis bestätigt haben, beginnen Sie mit der Fehlerbehebung mithilfe des interaktiven Playbooks:

1. Rufen Sie in der Trusted Cloud Console die Seite Interaktives Playbook für GKE – Pods in Absturzschleifen auf.

   Zu Crashloopic-Pods

2. Wählen Sie in der 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 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 ein.

4. Gehen Sie die einzelnen Abschnitte durch, um die folgenden Fragen zu beantworten:

   1. App-Fehler identifizieren: Welche Container werden neu gestartet?
   2. Speichermangelprobleme untersuchen: Liegt eine Fehlkonfiguration oder ein Fehler im Zusammenhang mit der App vor?
   3. Knotenstörungen untersuchen: Führen Störungen der Knotenressource zu Containerneustarts?
   4. Fehlgeschlagene Aktivitätsprüfungen untersuchen: Werden Ihre Container durch Aktivitätsprüfungen beendet?
   5. Änderungsereignisse korrelieren: Was geschah um den Zeitpunkt herum, als die Container begannen abzustürzen?

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

Wenn das Problem nach der Verwendung des Playbooks weiterhin besteht, lesen Sie den Rest des Leitfadens, um weitere Informationen zur Behebung von CrashLoopBackOff-Ereignissen zu erhalten.

CrashLoopBackOff-Ereignis beheben

In den folgenden Abschnitten erfahren Sie, wie Sie die häufigsten Ursachen für CrashLoopBackOff-Ereignisse beheben können:

• Ressourcenerschöpfung (OOMKilled)
• Fehler bei der Aktivitätsprüfung
• Falsch konfigurierte App

Ressourcenerschöpfung beheben

Ein CrashLoopBackOff-Ereignis wird häufig durch ein Problem mit unzureichendem Arbeitsspeicher (Out of Memory, OOM) verursacht. Sie können prüfen, ob dies die Ursache ist, wenn in der kubectl describe-Ausgabe Folgendes angezeigt wird:

Last State: Terminated
  Reason: OOMKilled

Informationen zum Diagnostizieren und Beheben von OOM-Ereignissen finden Sie unter OOM-Ereignisse beheben.

Fehler bei Aktivitätsprüfungen beheben

Eine Liveness-Probe ist eine regelmäßige Systemdiagnose, die von kubelet durchgeführt wird. Wenn die Prüfung eine bestimmte Anzahl von Malen fehlschlägt (standardmäßig drei), startet kubelet den Container neu. Wenn die Prüfungsfehler weiterhin auftreten, kann dies zu einem CrashLoopBackOff-Ereignis führen.

Prüfen, ob eine Aktivitätsprüfung die Ursache ist

Wenn Sie prüfen möchten, ob Fehler bei Aktivitätsprüfungen das Ereignis CrashLoopBackOff auslösen, fragen Sie die Logs von kubelet ab. Diese Logs enthalten oft explizite Meldungen, die auf Sondenfehler und nachfolgende Neustarts hinweisen.

1. Rufen Sie in der Trusted Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

2. Filtern Sie im Bereich „Abfrage“ nach Neustarts im Zusammenhang mit Aktivitätsprüfungen, indem Sie die folgende Abfrage eingeben:

   resource.type="k8s_node"
   log_id("kubelet")
   jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

3. Sehen Sie sich die Ausgabe an. Wenn ein Fehler bei der Aktivitätsprüfung die Ursache für Ihre CrashLoopBackOff-Ereignisse ist, gibt die Abfrage Logmeldungen ähnlich den folgenden zurück:

   Container probe failed liveness probe, will be restarted
   

Nachdem Sie bestätigt haben, dass Liveness-Probes die Ursache für das CrashLoopBackOff-Ereignis sind, fahren Sie mit der Fehlerbehebung häufiger Ursachen fort:

• Konfiguration der Aktivitätsprüfung prüfen
• CPU- und Laufwerk-E/A-Nutzung prüfen
• Große Bereitstellungen angehen:
• Vorübergehende Fehler beheben:
• Ressourcenverbrauch von Tests beheben:

Konfiguration der Aktivitätsprüfung überprüfen

Falsch konfigurierte Proben sind eine häufige Ursache für CrashLoopBackOff-Ereignisse. Prüfen Sie die folgenden Einstellungen im Manifest Ihrer Prüfung:

• Prüfungstyp bestätigen: Die Konfiguration der Prüfung muss mit der Art und Weise übereinstimmen, wie Ihre App ihren Zustand meldet. Wenn Ihre App beispielsweise eine Systemdiagnose-URL wie /healthz hat, verwenden Sie den Sondentyp httpGet. Wenn der Zustand durch Ausführen eines Befehls bestimmt wird, verwenden Sie den Sondentyp exec. Wenn Sie beispielsweise prüfen möchten, ob ein Netzwerkport geöffnet ist und auf Anfragen wartet, verwenden Sie den Sondentyp tcpSocket.
• Sondenparameter prüfen:
  • Pfad (für den Sondentyp httpGet): Achten Sie darauf, dass der HTTP-Pfad korrekt ist und Ihre App Systemdiagnosen darüber bereitstellt.
  • Port: Prüfen Sie, ob der in der Probe konfigurierte Port tatsächlich von der App verwendet und bereitgestellt wird.
  • Befehl (für den Sondentyp exec): Der Befehl muss im Container vorhanden sein, bei Erfolg den Exitcode 0 zurückgeben und innerhalb des konfigurierten Zeitraums von timeoutSeconds abgeschlossen werden.
  • Zeitlimit: Achten Sie darauf, dass der timeoutSeconds-Wert ausreichend ist, damit die App reagieren kann, insbesondere beim Start oder unter Last.
  • Anfängliche Verzögerung (initialDelaySeconds): Prüfen Sie, ob die anfängliche Verzögerung ausreicht, damit die App vor Beginn der Tests gestartet werden kann.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.

CPU- und Laufwerk-E/A-Nutzung prüfen

Ressourcenkonflikte führen zu Zeitüberschreitungen bei Prüfungen, was eine Hauptursache für fehlgeschlagene Liveness-Prüfungen ist. Wenn Sie prüfen möchten, ob die Ressourcennutzung die Ursache für den Fehler des Liveness-Probe ist, versuchen Sie Folgendes:

• CPU-Auslastung analysieren: Überwachen Sie die CPU-Auslastung des betroffenen Containers und des Knotens, auf dem er ausgeführt wird, während der Probeintervalle. Eine wichtige Kennzahl, die Sie im Blick behalten sollten, ist kubernetes.io/container/cpu/core_usage_time. Eine hohe CPU-Auslastung auf dem Container oder dem Knoten kann verhindern, dass die App rechtzeitig auf die Anfrage reagiert.
• Laufwerk-E/A überwachen: Prüfen Sie die Messwerte für die Laufwerk-E/A für den Knoten. Mit dem Messwert compute.googleapis.com/guest/disk/operation_time können Sie die Zeitdauer für die Festplattenvorgänge bewerten, die nach Lese- und Schreibvorgängen kategorisiert werden. Hohe Laufwerks-E/A kann den Containerstart, die App-Initialisierung oder die Gesamtleistung der App erheblich verlangsamen, was zu Zeitüberschreitungen bei Prüfungen führt.

Umfangreiche Bereitstellungen

In Szenarien, in denen eine große Anzahl von Pods gleichzeitig bereitgestellt wird (z. B. durch ein CI/CD-Tool wie ArgoCD), kann ein plötzlicher Anstieg neuer Pods die Clusterressourcen überlasten, was zu einer Erschöpfung der Ressourcen der Steuerungsebene führt. Dieser Mangel an Ressourcen verzögert den Start der App und kann dazu führen, dass Aktivitätsprüfungen wiederholt fehlschlagen, bevor die Apps bereit sind.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

• Staggered Deployments implementieren: Implementieren Sie Strategien, um Pods in Batches oder über einen längeren Zeitraum bereitzustellen, um eine Überlastung der Knotenressourcen zu vermeiden.
• Knoten neu konfigurieren oder skalieren: Wenn gestaffelte Bereitstellungen nicht möglich sind, sollten Sie Knoten mit schnelleren oder größeren Festplatten oder PersistentVolumeClaims aktualisieren, um die erhöhte E/A-Anforderung besser zu bewältigen. Prüfen Sie, ob die automatische Skalierung Ihres Clusters richtig konfiguriert ist.
• Warten und beobachten: In einigen Fällen, wenn der Cluster nicht stark unterversorgt ist, können Arbeitslasten nach einer erheblichen Verzögerung (manchmal 30 Minuten oder mehr) bereitgestellt werden.

Vorübergehende Fehler beheben

Bei der App können während des Starts oder der Initialisierung vorübergehende Fehler oder Verlangsamungen auftreten, die dazu führen, dass der Test anfangs fehlschlägt. Wenn sich die App schließlich erholt, sollten Sie die in den Feldern initialDelaySeconds oder failureThreshold im Manifest Ihres Liveness-Probe-Jobs definierten Werte erhöhen.

Ressourcenverbrauch von Prüfungen berücksichtigen

In seltenen Fällen kann die Ausführung der Aktivitätsprüfung selbst erhebliche Ressourcen verbrauchen, was zu Ressourcenbeschränkungen führen kann, die möglicherweise dazu führen, dass der Container aufgrund eines OOM-Kill beendet wird. Sorgen Sie dafür, dass Ihre Probe-Befehle schlank sind. Eine einfache Probe wird mit größerer Wahrscheinlichkeit schnell und zuverlässig ausgeführt. Dadurch kann der tatsächliche Zustand Ihrer App genauer erfasst werden.

Falsch konfigurierte Apps korrigieren

Viele CrashLoopBackOff-Ereignisse werden durch falsche App-Konfigurationen verursacht. Um herauszufinden, warum Ihre App beendet wird, müssen Sie zuerst den Exit-Code untersuchen. Dieser Code bestimmt den Pfad zur Fehlerbehebung:

• Der Exitcode 0 weist auf einen erfolgreichen Exit hin, was für einen Dienst, der lange ausgeführt wird, unerwartet ist und auf Probleme mit dem Einstiegspunkt des Containers oder dem App-Design hindeutet.
• Ein Exit-Code ungleich null signalisiert einen App-Absturz. Sie sollten sich dann auf Konfigurationsfehler, Probleme mit Abhängigkeiten oder Fehler im Code konzentrieren.

Exit-Code finden

So finden Sie den Exit-Code Ihrer App:

1. Beschreiben Sie den Pod:

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   Ersetzen Sie Folgendes:

   • POD_NAME: der Name des problematischen Pods.
   • NAMESPACE_NAME: der Namespace des Pods.

2. Sehen Sie sich in der Ausgabe das Feld Exit Code an, das sich unter dem Abschnitt Last State für den relevanten Container befindet. Wenn der Exit-Code 0 ist, lesen Sie den Abschnitt Fehlerbehebung bei erfolgreichen Beendigungen (Exit-Code 0). Wenn der Exit-Code eine andere Zahl als 0 ist, lesen Sie den Abschnitt App-Abstürze beheben (Exit-Code ungleich null).

Probleme mit erfolgreichen Beendigungen beheben (Exit-Code 0)

Ein Exitcode von 0 bedeutet in der Regel, dass der Prozess des Containers erfolgreich abgeschlossen wurde. Obwohl dies das gewünschte Ergebnis für einen aufgabenbasierten Job ist, kann es ein Problem für einen lang andauernden Controller wie ein Deployment, StatefulSet oder ReplicaSet signalisieren.

Diese Controller sorgen dafür, dass immer ein Pod ausgeführt wird. Daher wird jeder Exit als Fehler behandelt, der behoben werden muss. Der kubelet erzwingt dieses Verhalten, indem er sich an die restartPolicy des Pods hält (die standardmäßig auf Always festgelegt ist) und den Container auch nach einem erfolgreichen Beenden neu startet. Durch diese Aktion wird eine Schleife erstellt, die letztendlich den Status CrashLoopBackOff auslöst.

Die häufigsten Gründe für unerwartete erfolgreiche Ausstiege sind:

• Mit dem Containerbefehl wird kein dauerhafter Prozess gestartet: Ein Container wird nur so lange ausgeführt, wie sein ursprünglicher Prozess (command oder entrypoint). Wenn es sich bei diesem Prozess nicht um einen Dienst handelt, der lange ausgeführt wird, wird der Container beendet, sobald der Befehl abgeschlossen ist. Ein Befehl wie ["/bin/bash"] wird beispielsweise sofort beendet, da kein Skript ausgeführt werden kann. Achten Sie zur Behebung dieses Problems darauf, dass der erste Prozess Ihres Containers einen Prozess startet, der kontinuierlich ausgeführt wird.

• Worker-App wird beendet, wenn eine Arbeitswarteschlange leer ist: Viele Worker-Apps sind so konzipiert, dass sie eine Warteschlange nach einer Aufgabe durchsuchen und sauber beendet werden, wenn die Warteschlange leer ist. Zur Behebung dieses Problems können Sie entweder einen Job-Controller verwenden (der für Aufgaben konzipiert ist, die bis zum Abschluss ausgeführt werden) oder die Logik der App so ändern, dass sie als persistenter Dienst ausgeführt wird.

• App wird aufgrund einer fehlenden oder ungültigen Konfiguration beendet: Ihre App wird möglicherweise sofort beendet, wenn erforderliche Startanweisungen fehlen, z. B. Befehlszeilenargumente, Umgebungsvariablen oder eine wichtige Konfigurationsdatei.

  Sehen Sie sich zur Behebung dieses Problems zuerst die Logs Ihrer App an, um nach bestimmten Fehlermeldungen im Zusammenhang mit dem Laden der Konfiguration oder fehlenden Parametern zu suchen. Prüfen Sie dann Folgendes:

  • App-Argumente oder Umgebung: Achten Sie darauf, dass alle erforderlichen Befehlszeilenargumente und Umgebungsvariablen wie von Ihrer App erwartet korrekt an den Container übergeben werden.
  • Vorhandensein von Konfigurationsdateien: Prüfen Sie, ob alle erforderlichen Konfigurationsdateien an den erwarteten Pfaden im Container vorhanden sind.
  • Inhalt der Konfigurationsdatei: Prüfen Sie den Inhalt und das Format Ihrer Konfigurationsdateien auf Syntaxfehler, fehlende Pflichtfelder oder falsche Werte.

  Ein häufiges Beispiel für dieses Problem ist, wenn eine App so konfiguriert ist, dass sie aus einer Datei liest, die mit einem ConfigMap-Volume bereitgestellt wird. Wenn die ConfigMap nicht angehängt ist, leer ist oder falsch benannte Schlüssel enthält, wird eine App, die so konzipiert ist, dass sie beendet wird, wenn ihre Konfiguration fehlt, möglicherweise mit dem Exitcode 0 beendet. Prüfen Sie in solchen Fällen die folgenden Einstellungen: - Der Name ConfigMap in der Volumedefinition Ihres Pods stimmt mit dem tatsächlichen Namen überein. – Die Schlüssel in ConfigMap entsprechen den Dateinamen, die Ihre App im bereitgestellten Volume erwartet.

Fehlerbehebung bei App-Abstürzen (Exit-Code ungleich null)

Wenn ein Container mit einem Code ungleich null beendet wird, startet Kubernetes ihn neu. Wenn das zugrunde liegende Problem, das den Fehler verursacht hat, weiterhin besteht, stürzt die App wieder ab und der Zyklus wiederholt sich, bis der Status CrashLoopBackOff erreicht wird.

Der Exit-Code ungleich null ist ein deutliches Signal dafür, dass in der App selbst ein Fehler aufgetreten ist. Das bedeutet, dass Sie sich bei der Fehlersuche auf die internen Abläufe und die Umgebung der App konzentrieren müssen. Die folgenden Probleme führen häufig zu einer solchen Kündigung:

• Konfigurationsfehler: Ein Exit-Code ungleich null deutet oft auf Probleme mit der Konfiguration der App oder der Umgebung hin, in der sie ausgeführt wird. Prüfen Sie Ihre App auf diese häufigen Probleme:

  • Fehlende Konfigurationsdatei: Die App kann möglicherweise eine erforderliche Konfigurationsdatei nicht finden oder darauf zugreifen.
  • Ungültige Konfiguration: Die Konfigurationsdatei enthält möglicherweise Syntaxfehler, falsche Werte oder inkompatible Einstellungen, die zum Absturz der App führen.
  • Berechtigungsprobleme: Der App fehlen möglicherweise die erforderlichen Berechtigungen zum Lesen oder Schreiben der Konfigurationsdatei.
  • Umgebungsvariablen: Falsche oder fehlende Umgebungsvariablen können dazu führen, dass die App nicht richtig funktioniert oder nicht gestartet werden kann.
  • Ungültiges entrypoint oder command: Der im Feld entrypoint oder command des Containers angegebene Befehl ist möglicherweise falsch. Dieses Problem kann bei neu bereitgestellten Images auftreten, wenn der Pfad zur ausführbaren Datei falsch ist oder die Datei selbst nicht im Container-Image vorhanden ist. Diese Fehlkonfiguration führt häufig zum Exitcode 128.

  • Unkontrollierte Image-Updates (:latest-Tag): Wenn in den Images für Ihre Arbeitslast das :latest-Tag verwendet wird, rufen neue Pods möglicherweise eine aktualisierte Image-Version ab, die Breaking Changes enthält.

    Um Konsistenz und Reproduzierbarkeit zu gewährleisten, sollten Sie in Produktionsumgebungen immer bestimmte, unveränderliche Image-Tags (z. B. v1.2.3) oder SHA-Digests (z. B. sha256:45b23dee08...) verwenden. So wird sichergestellt, dass jedes Mal genau dieselben Bildinhalte abgerufen werden.

• Probleme mit Abhängigkeiten: Ihre App stürzt möglicherweise ab, wenn sie keine Verbindung zu den anderen Diensten herstellen kann, von denen sie abhängt, oder wenn die Authentifizierung fehlschlägt oder sie nicht über die erforderlichen Berechtigungen für den Zugriff auf diese Dienste verfügt.

  • Externer Dienst nicht verfügbar: Die App ist möglicherweise von externen Diensten (z. B. Datenbanken oder APIs) abhängig, die aufgrund von Problemen mit der Netzwerkverbindung oder Dienstausfällen nicht erreichbar sind. Um dieses Problem zu beheben, stellen Sie eine Verbindung zum Pod her. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Laufende Pods debuggen.

    Nachdem Sie eine Verbindung zum Pod hergestellt haben, können Sie Befehle ausführen, um den Zugriff auf Dateien oder Datenbanken zu prüfen oder das Netzwerk zu testen. Sie können beispielsweise mit einem Tool wie curl versuchen, die URL eines Dienstes zu erreichen. So können Sie feststellen, ob ein Problem durch Netzwerkrichtlinien, DNS oder den Dienst selbst verursacht wird.

  • Authentifizierungsfehler: Die App kann sich möglicherweise aufgrund falscher Anmeldedaten nicht bei externen Diensten authentifizieren. Sehen Sie sich die Containerlogs nach Meldungen wie 401 Unauthorized (ungültige Anmeldedaten) oder 403 Forbidden (unzureichende Berechtigungen) an. Diese Meldungen weisen häufig darauf hin, dass dem Dienstkonto für den Pod die erforderlichen IAM-Rollen für externe Trusted Cloud by S3NSDienstaufrufe fehlen.

    Wenn Sie die GKE Workload Identity Federation verwenden, prüfen Sie, ob die Prinzipal-ID die für die Aufgabe erforderlichen Berechtigungen hat. Weitere Informationen zum Zuweisen von IAM-Rollen zu Identitäten mithilfe von GKE Workload Identity Federation finden Sie unter Autorisierung und Identitäten konfigurieren. Sie sollten auch prüfen, ob die Ressourcennutzung des GKE-Metadatenservers die Grenzwerte überschritten hat.

  • Zeitüberschreitungen: Bei der App kann es zu Zeitüberschreitungen kommen, wenn sie auf Antworten von externen Diensten wartet, was zu Abstürzen führt.

• App-spezifische Fehler: Wenn die Konfiguration und die externen Abhängigkeiten korrekt zu sein scheinen, liegt der Fehler möglicherweise im Code der App. Prüfen Sie die App-Logs auf diese häufigen internen Fehler:

  • Nicht abgefangene Ausnahmen: Die App-Logs enthalten möglicherweise Stacktraces oder Fehlermeldungen, die auf nicht abgefangene Ausnahmen oder andere codebezogene Fehler hinweisen.
  • Deadlocks oder Livelocks: Die App hängt möglicherweise in einem Deadlock fest, bei dem mehrere Prozesse darauf warten, dass der jeweils andere Prozess abgeschlossen wird. In diesem Fall wird die App möglicherweise nicht beendet, reagiert aber auf unbestimmte Zeit nicht mehr.
  • Portkonflikte: Die App kann möglicherweise nicht gestartet werden, wenn sie versucht, eine Bindung zu einem Port herzustellen, der bereits von einem anderen Prozess verwendet wird.
  • Inkompatible Bibliotheken: Die App ist möglicherweise von Bibliotheken oder Abhängigkeiten abhängig, die fehlen oder mit der Laufzeitumgebung inkompatibel sind.

  Um die Ursache zu ermitteln, sehen Sie in den Containerlogs nach einer bestimmten Fehlermeldung oder einem Stacktrace. Anhand dieser Informationen können Sie entscheiden, ob Sie den App-Code korrigieren, die Ressourcenlimits anpassen oder die Konfiguration der Umgebung korrigieren möchten. Weitere Informationen zu Logs finden Sie unter GKE-Logs.

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.