Alles zusammenführen: Beispiel für ein Fehlerbehebungsszenario

Es ist hilfreich, die einzelnen Tools zur Fehlerbehebung für Google Kubernetes Engine (GKE) zu kennen. Wenn Sie jedoch sehen, wie sie zusammen verwendet werden, um ein reales Problem zu lösen, können Sie Ihr Wissen festigen.

Folgen Sie einem geführten Beispiel, in dem die Verwendung der Google Cloud -Konsole, des kubectl-Befehlszeilentools, von Cloud Logging und Cloud Monitoring kombiniert wird, um die Ursache eines OutOfMemory-Fehlers (OOMKilled) zu ermitteln.

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

Das Szenario

Sie sind der Bereitschaftsingenieur für eine Web-App mit dem Namen product-catalog, die in GKE ausgeführt wird.

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

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

Diese Benachrichtigung informiert Sie darüber, dass ein Problem vorliegt, und weist darauf hin, dass das Problem mit der Arbeitslast product-catalog zusammenhängt.

Problem in der Google Cloud -Konsole bestätigen

Sie beginnen mit einer allgemeinen Ansicht 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 Statusspalte Pods an. Anstelle des fehlerfreien 3/3 wird der Wert 2/3 angezeigt, der einen fehlerhaften Status angibt. Dieser Wert gibt an, dass einer der Pods Ihrer App nicht den Status Ready hat.
  3. Sie möchten die Situation genauer untersuchen und klicken daher auf den Namen der Arbeitslast product-catalog, um die zugehörige Detailseite aufzurufen.
  4. Auf der Detailseite sehen Sie den Bereich Verwaltete Pods. Sie stellen sofort ein Problem fest: In der Spalte Restarts für Ihren Pod wird 14 angezeigt, eine ungewöhnlich hohe Zahl.

Die hohe Anzahl an Neustarts bestätigt, dass das Problem zu einer instabilen App führt. Das deutet darauf hin, dass ein Container seine Systemdiagnosen nicht besteht oder abstürzt.

Grund mit kubectl-Befehlen herausfinden

Nachdem Sie nun wissen, dass Ihre App wiederholt neu gestartet wird, müssen Sie herausfinden, warum. Der Befehl kubectl describe ist dafür gut geeignet.

  1. Sie erhalten den genauen Namen des instabilen Pods:

    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. Sie sehen sich die Ausgabe an und finden Hinweise in den Abschnitten Last State und Events:

    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 enthält 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, dem Standard-Linux-Exit-Code für einen Prozess, der aufgrund von übermäßigem Speicherverbrauch beendet wurde.
    • Zweitens wird im Abschnitt Events ein Warning: BackOff-Ereignis mit der Meldung Back-off restarting failed container angezeigt. 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 den Metrics Explorer auf.
  2. Sie wählen 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 Speichernutzung steigt stetig an und fällt dann abrupt auf null, wenn der Container aufgrund von OOM beendet und neu gestartet wird. Diese visuellen Beweise bestätigen entweder ein Speicherleck oder ein unzureichendes Speicherlimit.

Grundursache in Protokollen finden

Sie wissen jetzt, dass der Container nicht mehr genügend Arbeitsspeicher hat, aber noch nicht genau, warum. Verwenden Sie den Log-Explorer, um die Ursache zu ermitteln.

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

  2. Sie schreiben eine Abfrage, um die Logs Ihres Containers kurz vor dem Zeitpunkt des letzten Absturzes zu filtern (den Sie in der Ausgabe des kubectl describe-Befehls 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 weisen darauf hin, dass die App versucht, große Bilddateien zu verarbeiten, indem sie sie vollständig in den Arbeitsspeicher lädt. Dadurch wird das Arbeitsspeicherlimit des Containers überschritten.

Die Ergebnisse

Wenn Sie die Tools zusammen verwenden, erhalten Sie ein vollständiges Bild des Problems:

  • Die Überwachungsbenachrichtigung hat Sie darauf hingewiesen, dass ein Problem vorliegt.
  • In der Google Cloud Console wurde angezeigt, dass das Problem Nutzer betrifft (Neustarts).
  • kubectl-Befehle haben den genauen Grund für die Neustarts ermittelt (OOMKilled).
  • Im Metrics Explorer wird das Muster des Speicherlecks im Zeitverlauf visualisiert.
  • Der Log-Explorer hat das spezifische Verhalten aufgedeckt, das das Speicherproblem verursacht hat.

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

Nächste Schritte