Alles zusammenführen: Beispiel für ein Szenario zur Fehlerbehebung

Es ist hilfreich, die einzelnen Tools zur Fehlerbehebung für die Google Kubernetes Engine (GKE) zu kennen. Noch besser ist es jedoch, zu sehen, wie sie gemeinsam zur Lösung eines realen Problems eingesetzt werden.

In diesem Beispiel wird gezeigt, wie Sie die Google Cloud Console, das kubectl Befehlszeilentool, Cloud Logging und Cloud Monitoring kombinieren, um die Ursache eines OutOfMemory (OOMKilled) Fehlers zu ermitteln.

Dieses Beispiel ist für alle gedacht, die eine praktische Anwendung der in dieser Reihe beschriebenen Techniken zur Fehlerbehebung sehen möchten, insbesondere für Plattformadministratoren und ‑operatoren sowie Anwendungsentwickler. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Szenario

Sie sind der Bereitschaftsingenieur für eine Webanwendung namens product-catalog, die in GKE ausgeführt wird.

Ihre Untersuchung beginnt, als Sie eine automatische Benachrichtigung von Cloud Monitoring erhalten:

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

Diese Benachrichtigung informiert Sie über ein Problem und gibt an, dass es mit der Arbeitslast product-catalog zusammenhängt.

Problem in der Google Cloud Console bestätigen

Sie beginnen mit einer allgemeinen Übersicht Ihrer Arbeitslasten, um das Problem zu bestätigen.

  1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf und filtern Sie nach Ihrer product-catalog Arbeitslast.
  2. Sehen Sie sich die Spalte Pods an. Anstelle des fehlerfreien Werts 3/3 sehen Sie, dass der Wert einen fehlerhaften Status anzeigt: 2/3. Dieser Wert bedeutet, dass einer der Pods Ihrer Anwendung nicht den Status Readyhat.
  3. Sie möchten das Problem weiter untersuchen und klicken daher auf den Namen der Arbeitslast product-catalog, um die zugehörige Detailseite aufzurufen.
  4. Auf der Detailseite sehen Sie sich den Bereich Verwaltete Pods an. Sie erkennen sofort ein Problem: In der Spalte Restarts für Ihren Pod wird 14 angezeigt, eine ungewöhnlich hohe Zahl.

Diese hohe Anzahl von Neustarts bestätigt, dass das Problem zu einer Instabilität der Anwendung führt, und deutet darauf hin, dass bei einem Container die Systemdiagnosen fehlschlagen oder er abstürzt.

Ursache mit kubectl-Befehlen ermitteln

Jetzt wissen Sie, dass Ihre Anwendung wiederholt neu gestartet wird. Sie müssen nun herausfinden, warum. Der Befehl kubectl describe ist dafür ein gutes Tool.

  1. Sie rufen den genauen Namen des instabilen Pods ab:

    kubectl get pods -n prod

    Die Ausgabe sieht so aus:

    NAME                             READY  STATUS            RESTARTS  AGE
product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m

  2. Sie beschreiben den instabilen Pod, um den detaillierten Ereignisverlauf zu erhalten:

    kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod

  3. Sehen Sie sich die Ausgabe an und suchen Sie in den Abschnitten Last State und Events nach Hinweisen:

    Containers:
  product-catalog-api:
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 23 Jun 2025 10:50:15 -0700
      Finished:     Mon, 23 Jun 2025 10:54:58 -0700
    Ready:          False
    Restart Count:  14
...
Events:
  Type     Reason     Age                           From                Message
  ----     ------     ----                          ----                -------
  Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
  Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
  Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
  Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
  Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container

    Die Ausgabe liefert Ihnen zwei wichtige Hinweise:

    • Im Abschnitt Last State sehen Sie, dass der Container mit Reason: OOMKilled beendet wurde. Das bedeutet, dass der Arbeitsspeicher nicht mehr ausgereicht hat. Dieser Grund wird durch den Exit Code: 137 bestätigt. Das ist der Standard-Linux-Exit-Code für einen Prozess, der aufgrund übermäßiger Arbeitsspeichernutzung beendet wurde.
    • Im Abschnitt Events sehen Sie ein Warning: BackOff-Ereignis mit der Meldung Back-off restarting failed container. Diese Meldung bestätigt, dass sich der Container in einer Fehlerschleife befindet. Das ist die direkte Ursache für den Status CrashLoopBackOff, den Sie zuvor gesehen haben.

Verhalten mit Messwerten visualisieren

Der Befehl kubectl describe hat Ihnen gezeigt, was passiert ist. Mit Cloud Monitoring können Sie jedoch das Verhalten Ihrer Umgebung im Zeitverlauf sehen.

  1. Rufen Sie in der Google Cloud Console Metrics Explorer auf.
  2. Wählen Sie den Messwert container/memory/used_bytes aus.
  3. Filtern Sie die Ausgabe nach Ihrem spezifischen Cluster, Namespace und Pod-Namen.

Das Diagramm zeigt ein deutliches Muster: Die Arbeitsspeichernutzung steigt stetig an und fällt dann abrupt auf null, wenn der Container aufgrund von Arbeitsspeichermangel beendet und neu gestartet wird. Diese visuellen Beweise deuten entweder auf ein Speicherleck oder ein unzureichendes Arbeitsspeicherlimit hin.

Ursache in Logs ermitteln

Sie wissen jetzt, dass der Arbeitsspeicher des Containers nicht mehr ausreicht, aber Sie wissen noch nicht genau, warum. Verwenden Sie den Log-Explorer, um die Ursache zu ermitteln.

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

  2. Erstellen Sie eine Abfrage, um die Logs Ihres spezifischen Containers kurz vor dem Zeitpunkt des letzten Absturzes zu filtern (den Sie in der Ausgabe des Befehls kubectl describe gesehen haben):

    resource.type="k8s_container"
resource.labels.cluster_name="example-cluster"
resource.labels.namespace_name="prod"
resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
timestamp >= "2025-06-23T17:50:00Z"
timestamp < "2025-06-23T17:55:00Z"

  3. In den Logs finden Sie kurz vor jedem Absturz ein sich wiederholendes Muster von Nachrichten:

    {
  "message": "Processing large image file product-image-large.jpg",
  "severity": "INFO"
},
{
  "message": "WARN: Memory cache size now at 248MB, nearing limit.",
  "severity": "WARNING"
}

Diese Logeinträge zeigen, dass die Anwendung versucht, große Bilddateien zu verarbeiten, indem sie sie vollständig in den Arbeitsspeicher lädt. Dadurch wird schließlich das Arbeitsspeicherlimit des Containers überschritten.

Ergebnisse

Durch die gemeinsame Verwendung der Tools erhalten Sie ein vollständiges Bild des Problems:

  • Die Monitoringbenachrichtigung hat Sie über ein Problem informiert.
  • In der Google Cloud Console haben Sie gesehen, dass das Problem Nutzer betrifft (Neustarts).
  • Mit kubectl-Befehlen wurde die genaue Ursache für die Neustarts ermittelt (OOMKilled).
  • Im Metrics Explorer wurde das Muster des Speicherlecks im Zeitverlauf visualisiert.
  • Im Log-Explorer wurde das spezifische Verhalten ermittelt, das das Arbeitsspeicherproblem verursacht.

Jetzt können Sie eine Lösung implementieren. Sie können entweder den Anwendungscode optimieren, um große Dateien effizienter zu verarbeiten, oder als kurzfristige Lösung das Arbeitsspeicherlimit des Containers erhöhen (insbesondere den Wert spec.containers.resources.limits.memory) im YAML-Manifest der Arbeitslast.

Nächste Schritte