Einführung in die Fehlerbehebung bei GKE

Auf dieser Seite werden grundlegende Methoden zur Fehlerbehebung für Google Kubernetes Engine (GKE) vorgestellt. Diese Seite richtet sich an Nutzer, die neu in Kubernetes und GKE sind und effektive Methoden zur Fehlerbehebung kennenlernen möchten.

Auf dieser Seite finden Sie eine Übersicht über die folgenden Tools und Techniken zum Monitoring, zur Diagnose und zur Behebung von Problemen mit GKE:

• Cluster- und Arbeitslaststatus in der Google Cloud Console prüfen: Sie erhalten einen allgemeinen Überblick, um potenzielle Probleme mit Ihren Clustern und Apps schnell zu erkennen.
• Clusterstatus mit dem kubectl-Befehlszeilentool untersuchen: Mit diesen Befehlen können Sie den Live-Status von Ressourcen wie Knoten und Pods aufrufen.
• Verlaufsanalyse mit Cloud Logging durchführen: Fragen Sie Verlaufslogdaten ab und untersuchen Sie Ereignisse, um die Ursache von Fehlern zu ermitteln.
• Proaktive Überwachung mit Cloud Monitoring durchführen: Leistungsmesswerte im Zeitverlauf verfolgen, Trends visualisieren und Benachrichtigungen erstellen, um Probleme zu erkennen und darauf zu reagieren, bevor sie sich auf Nutzer auswirken.
• Diagnose mit Gemini Cloud Assist beschleunigen: Analysieren Sie komplexe Fehlermeldungen, erhalten Sie eine Schritt-für-Schritt-Anleitung zur Fehlerbehebung und untersuchen Sie Probleme automatisch.
• Alles zusammen: Beispiel für ein Szenario zur Fehlerbehebung: Hier erfahren Sie, wie Sie diese Tools gemeinsam in einer Schritt-für-Schritt-Anleitung verwenden, um einen häufigen App-Fehler in der Praxis zu diagnostizieren und zu beheben.

Zentrale Begriffe und Funktionsweise

Wenn Sie Kubernetes und GKE noch nicht kennen, ist es wichtig, dass Sie sich mit den grundlegenden Konzepten wie der Clusterarchitektur und der Beziehung zwischen Pods und Knoten vertraut machen, bevor Sie mit der Fehlerbehebung beginnen. Weitere Informationen finden Sie unter GKE kennenlernen.

Es ist auch hilfreich zu wissen, für welche Teile von GKE Sie verantwortlich sind und für welche Google Cloud . Weitere Informationen finden Sie unter Geteilte Verantwortung in GKE.

Cluster- und Arbeitslaststatus in der Google Cloud -Konsole prüfen

Die Google Cloud -Konsole ist ein guter Ausgangspunkt für die Fehlerbehebung, da sie einen schnellen Überblick über den Zustand Ihrer Cluster und Arbeitslasten bietet. Clusterzustand bezieht sich auf den Zustand der zugrunde liegenden GKE-Infrastruktur wie Knoten und Netzwerk, während sich Arbeitslastzustand auf den Status und die Leistung Ihrer Anwendungen bezieht, die im Cluster ausgeführt werden.

In den folgenden Abschnitten werden die Cluster- und Arbeitslastseiten beschrieben. Um ein vollständiges Bild vom Zustand Ihrer App zu erhalten, bietet die Google Cloud Konsole auch Zugriff auf leistungsstarke Logging- und Monitoring-Tools, mit denen Sie die Ursache vergangener Fehler untersuchen und zukünftige Fehler proaktiv verhindern können. Weitere Informationen zu diesen Tools finden Sie in den Abschnitten Verlaufsanalyse mit Cloud Logging durchführen und Proaktives Monitoring mit Cloud Monitoring durchführen.

Clusterprobleme finden

Auf der Seite Kubernetes-Cluster erhalten Sie einen Überblick über den Status Ihrer Cluster. Auf dieser Seite können Sie Probleme mit Ihren Clustern ermitteln.

• Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

  Zur Seite "Kubernetes-Cluster"

Hier sind einige Beispiele dafür, wie Sie diese Seite zur Fehlerbehebung nutzen können:

• Wenn Sie Ratschläge zur Verbesserung des Clusterzustands, zur Upgradestrategie und zur Kostenoptimierung benötigen, klicken Sie auf Empfehlungen ansehen.
• In der Spalte Status sehen Sie, welche Cluster fehlerhaft sind. Für alle Cluster ohne grünes Häkchen sind Maßnahmen erforderlich.
• In der Spalte Benachrichtigungen finden Sie Informationen zu potenziellen Problemen. Klicken Sie auf eine beliebige Benachrichtigung, um weitere Informationen zu erhalten.

Bestimmten Cluster untersuchen

Wenn Sie ein Problem mit einem Cluster feststellen, können Sie auf der Seite Details des Clusters detaillierte Informationen abrufen, die Ihnen bei der Fehlerbehebung und beim Verständnis der Konfiguration helfen.

So rufen Sie die Seite Details eines Clusters auf:

1. Rufen Sie die Seite Kubernetes-Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Sehen Sie sich die Spalte Name an und klicken Sie auf den Namen des Clusters, den Sie untersuchen möchten.

Hier sind einige Beispiele dafür, wie Sie die Seite Details des Clusters zur Fehlerbehebung verwenden können:

• Versuchen Sie bei allgemeinen Systemdiagnosen Folgendes:

  • Wenn Sie Dashboards auf Clusterebene aufrufen möchten, rufen Sie den Tab Beobachtbarkeit auf. Standardmäßig wird Cloud Monitoring in GKE aktiviert, wenn Sie einen Cluster erstellen. Wenn Cloud Monitoring aktiviert ist, werden die Dashboards auf dieser Seite automatisch von GKE eingerichtet. Hier sind einige Ansichten, die für die Fehlerbehebung am nützlichsten sein könnten:

    • Übersicht: Hier finden Sie eine allgemeine Zusammenfassung des Clusterzustands, der Ressourcenauslastung und der wichtigsten Ereignisse. Mit diesem Dashboard können Sie den allgemeinen Zustand Ihres Clusters schnell beurteilen und potenzielle Probleme erkennen.
    • Traffic-Messwerte: Knotenbasierte Netzwerkmesswerte liefern Ihnen Daten über den Traffic zwischen Ihren Kubernetes-Arbeitslasten.
    • Arbeitslaststatus: Hier können Sie den Status von Deployments, Pods und Containern ansehen. Fehlerhafte oder fehlerhafte Instanzen identifizieren und Ressourcenbeschränkungen erkennen.

    • Steuerungsebene: Hier können Sie den Zustand und die Leistung der Steuerungsebene ansehen. Mit diesem Dashboard können Sie wichtige Messwerte von Komponenten wie kube-apiserver und etcd überwachen, Leistungsengpässe erkennen und Komponentenfehler ermitteln.

  • Aktuelle App-Fehler finden Sie auf dem Tab App-Fehler. Die Informationen auf diesem Tab können Ihnen dabei helfen, Fehler zu priorisieren und zu beheben, da sie die Anzahl der Vorkommen, das erste Auftreten und das letzte Auftreten eines Fehlers anzeigen.

    Wenn Sie einen Fehler genauer untersuchen möchten, klicken Sie auf die Fehlermeldung, um einen detaillierten Fehlerbericht mit Links zu relevanten Logs aufzurufen.

• Wenn Sie Probleme nach einem kürzlich erfolgten Upgrade oder einer Änderung beheben möchten, sehen Sie sich den Abschnitt Clusterbasics auf dem Tab Details des Clusters an. Prüfen Sie, ob die im Feld Version aufgeführte Version der erwarteten Version entspricht. Klicken Sie im Bereich Upgrades auf Upgrade-Verlauf anzeigen, um weitere Informationen zu erhalten.

• Wenn Sie einen Standardcluster verwenden und Ihre Pods im Status Pending hängen bleiben oder Sie vermuten, dass Knoten überlastet sind, sehen Sie auf dem Tab Knoten nach. Der Tab Knoten ist für Autopilot-Cluster nicht verfügbar, da GKE die Knoten für Sie verwaltet.

  • Prüfen Sie im Abschnitt Knotenpools, ob die automatische Skalierung richtig konfiguriert ist und der Maschinentyp für Ihre Arbeitslasten geeignet ist.
  • Suchen Sie im Abschnitt Knoten nach Knoten mit einem anderen Status als Ready. Der Status NotReady weist auf ein Problem mit dem Knoten selbst hin, z. B. Ressourcenengpässe oder ein Problem mit dem Kubelet (dem Agent, der auf jedem Knoten ausgeführt wird, um Container zu verwalten).

Probleme mit Arbeitslasten finden

Wenn Sie vermuten, dass ein Problem mit einer bestimmten App vorliegt, z. B. eine fehlgeschlagene Bereitstellung, rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf. Auf dieser Seite finden Sie eine zentrale Ansicht aller Apps, die in Ihren Clustern ausgeführt werden.

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

  Zu Arbeitslasten

Hier sind einige Beispiele dafür, wie Sie diese Seite zur Fehlerbehebung nutzen können:

• Sehen Sie sich die Spalte Status an, um fehlerhafte Arbeitslasten zu identifizieren. Alle Arbeitslasten ohne grünes Häkchen müssen überprüft werden.
• Wenn eine App nicht reagiert, sehen Sie sich die Spalte Pods an. Ein Status wie 1/3 bedeutet beispielsweise, dass nur eines von drei App-Replikaten ausgeführt wird, was auf ein Problem hinweist.

Bestimmte Arbeitslast untersuchen

Nachdem Sie in der Übersicht eine problematische Arbeitslast identifiziert haben, können Sie auf der Seite Details der Arbeitslast mit der Eingrenzung der Ursache beginnen.

So rufen Sie die Seite Details einer Arbeitslast auf:

1. Zur Seite „Arbeitslasten“

   Zu Arbeitslasten

2. Sehen Sie sich die Spalte Name an und klicken Sie auf den Namen der Arbeitslast, die Sie untersuchen möchten.

Hier sind einige Beispiele dafür, wie Sie die Seite Details der Arbeitslast verwenden können, um Probleme mit Ihren Arbeitslasten zu beheben:

• Verwenden Sie die Tabs Übersicht und Details, um die Konfiguration der Arbeitslast zu prüfen. Anhand dieser Informationen können Sie Ereignisse wie die Bereitstellung des richtigen Container-Image-Tags überprüfen oder die Ressourcenanforderungen und ‑limits der Arbeitslast prüfen.

• Den Namen eines bestimmten abstürzenden Pods finden Sie im Bereich Verwaltete Pods. Möglicherweise benötigen Sie diese Informationen für kubectl-Befehle. In diesem Abschnitt werden alle Pods aufgeführt, die von der Arbeitslast gesteuert werden, sowie deren Status. Wenn Sie den Verlauf der letzten Änderungen an einer Arbeitslast aufrufen möchten, rufen Sie den Tab Überarbeitungsverlauf auf. Wenn Sie nach einer neuen Bereitstellung Leistungsprobleme feststellen, können Sie in diesem Abschnitt ermitteln, welche Revision aktiv ist. Anschließend können Sie die Konfigurationen der aktuellen Überarbeitung mit früheren vergleichen, um die Quelle des Problems zu ermitteln. Wenn dieser Tab nicht angezeigt wird, ist die Arbeitslast entweder ein Typ, für den keine Revisionen verwendet werden, oder es gab noch keine Aktualisierungen.

• Wenn eine Bereitstellung fehlgeschlagen zu sein scheint, rufen Sie den Tab Ereignisse auf. Diese Seite ist oft die wertvollste Informationsquelle, da sie Ereignisse auf Kubernetes-Ebene enthält.

• Wenn Sie sich die Logs Ihrer App ansehen möchten, klicken Sie auf den Tab Logs. Auf dieser Seite erfahren Sie, was in Ihrem Cluster passiert. Hier finden Sie Fehlermeldungen und Stacks, die Ihnen bei der Diagnose von Problemen helfen können.

• Auf dem Tab YAML können Sie genau sehen, was bereitgestellt wurde. Auf dieser Seite wird das aktuelle YAML-Manifest für die Arbeitslast angezeigt, wie es im Cluster vorhanden ist. Diese Informationen sind nützlich, um Abweichungen von Ihren quellcodeverwalteten Manifesten zu finden. Wenn Sie das YAML-Manifest eines einzelnen Pods aufrufen, wird auf diesem Tab auch der Status des Pods angezeigt. So erhalten Sie Informationen zu Fehlern auf Pod-Ebene.

Clusterstatus mit dem kubectl-Befehlszeilentool untersuchen

Mit der Google Cloud Konsole können Sie zwar feststellen, ob ein Problem vorliegt, aber das kubectl-Befehlszeilentool ist unerlässlich, um herauszufinden, warum. Durch die direkte Kommunikation mit der Kubernetes-Steuerungsebene können Sie mit dem kubectl-Befehlszeilentool die detaillierten Informationen abrufen, die Sie zur Fehlerbehebung in Ihrer GKE-Umgebung benötigen.

In den folgenden Abschnitten werden einige wichtige Befehle vorgestellt, die einen guten Ausgangspunkt für die Fehlerbehebung in GKE darstellen.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Installieren Sie kubectl.

• Konfigurieren Sie das kubectl-Befehlszeilentool für die Kommunikation mit Ihrem Cluster:

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=LOCATION
  

  Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • LOCATION: der Compute Engine-Standort der Steuerungsebene Ihres Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

• Prüfen Sie Ihre Berechtigungen. Mit dem Befehl kubectl auth can-i können Sie prüfen, ob Sie die erforderlichen Berechtigungen zum Ausführen von kubectl-Befehlen haben. Wenn Sie beispielsweise prüfen möchten, ob Sie die Berechtigung zum Ausführen von kubectl get nodes haben, führen Sie den Befehl kubectl auth can-i get nodes aus.

  Wenn Sie die erforderlichen Berechtigungen haben, gibt der Befehl yes zurück. Andernfalls gibt er no zurück.

  Wenn Sie keine Berechtigung zum Ausführen eines kubectl-Befehls haben, wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:

  Error from server (Forbidden): pods "POD_NAME" is forbidden: User
  "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  Wenn Sie nicht die erforderlichen Berechtigungen haben, bitten Sie Ihren Clusteradministrator, Ihnen die erforderlichen Rollen zuzuweisen.

Übersicht über laufende Prozesse

Mit dem Befehl kubectl get erhalten Sie einen Gesamtüberblick über die Vorgänge in Ihrem Cluster. Verwenden Sie die folgenden Befehle, um den Status von zwei der wichtigsten Clusterkomponenten, Knoten und Pods, aufzurufen:

1. So prüfen Sie, ob Ihre Knoten fehlerfrei sind:

   kubectl get nodes
   

   Die Ausgabe sieht etwa so aus:

   NAME                                        STATUS   ROLES    AGE     VERSION
   
   gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003
   

   Bei allen anderen Status als Ready ist eine zusätzliche Untersuchung erforderlich.

2. So prüfen Sie, ob Ihre Pods fehlerfrei sind:

   kubectl get pods --all-namespaces
   

   Die Ausgabe sieht etwa so aus:

   NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
   kube-system netd-6nbsq 3/3     Running     0          4d23h
   kube-system netd-g7tpl 3/3     Running     0          4d23h
   

   Bei allen anderen Status als Running ist eine zusätzliche Untersuchung erforderlich. Im Folgenden finden Sie einige häufige Status:

   • Running: Ein fehlerfreier, laufender Zustand.
   • Pending: Der Pod wartet darauf, auf einem Knoten geplant zu werden.
   • CrashLoopBackOff: Die Container im Pod stürzen in einer Schleife immer wieder ab, weil die App gestartet wird, mit einem Fehler beendet wird und dann von Kubernetes neu gestartet wird.
   • ImagePullBackOff: Der Pod kann das Container-Image nicht abrufen.

Die vorherigen Befehle sind nur zwei Beispiele dafür, wie Sie den Befehl kubectl get verwenden können. Sie können den Befehl auch verwenden, um mehr über viele Arten von Kubernetes-Ressourcen zu erfahren. Eine vollständige Liste der Ressourcen, die Sie untersuchen können, finden Sie in der Kubernetes-Dokumentation unter kubectl get.

Weitere Informationen zu bestimmten Ressourcen

Nachdem Sie ein Problem identifiziert haben, müssen Sie weitere Details dazu abrufen. Ein Beispiel für ein Problem ist ein Pod, der nicht den Status Running hat. Weitere Details erhalten Sie mit dem Befehl kubectl describe.

Führen Sie beispielsweise den folgenden Befehl aus, um einen bestimmten Pod zu beschreiben:

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Ersetzen Sie Folgendes:

• POD_NAME: Der Name des Pods, bei dem Probleme auftreten.
• NAMESPACE_NAME: der Namespace, in dem sich der Pod befindet. Wenn Sie sich nicht sicher sind, welcher Namespace verwendet wird, sehen Sie sich die Spalte Namespace in der Ausgabe des Befehls kubectl get pods an.

Die Ausgabe des Befehls kubectl describe enthält detaillierte Informationen zu Ihrer Ressource. Hier sind einige der hilfreichsten Abschnitte, die Sie bei der Fehlerbehebung eines Pods überprüfen sollten:

• Status: Der aktuelle Status des Pods.
• Conditions: Der allgemeine Zustand und die Bereitschaft des Pods.
• Restart Count: Wie oft die Container im Pod neu gestartet wurden. Hohe Zahlen können Anlass zur Sorge geben.
• Events: Ein Log wichtiger Ereignisse, die für diesen Pod aufgetreten sind, z. B. die Planung auf einem Knoten, das Herunterladen des Container-Images und ob Fehler aufgetreten sind. Im Abschnitt Events finden Sie oft direkte Hinweise darauf, warum ein Pod fehlschlägt.

Wie beim Befehl kubectl get können Sie mit dem Befehl kubectl describe weitere Informationen zu mehreren Ressourcentypen abrufen. Eine vollständige Liste der Ressourcen, die Sie untersuchen können, finden Sie in der Kubernetes-Dokumentation unter kubectl describe.

Verlaufsanalyse mit Cloud Logging durchführen

Das kubectl-Befehlszeilentool ist zwar sehr nützlich, um den aktuellen Status Ihrer Kubernetes-Objekte zu prüfen, aber die Ansicht ist oft auf den aktuellen Moment beschränkt. Um die Ursache eines Problems zu verstehen, müssen Sie oft untersuchen, was im Laufe der Zeit passiert ist. Wenn Sie diesen historischen Kontext benötigen, verwenden Sie Cloud Logging.

Cloud Logging aggregiert Logs aus Ihren GKE-Clustern, containerisierten Apps und anderen Google Cloud Diensten.

Wichtige Logtypen für die Fehlerbehebung

Cloud Logging erfasst automatisch verschiedene Arten von GKE-Logs, die Ihnen bei der Fehlerbehebung helfen können:

• Knoten- und Laufzeitlogs (kubelet, containerd): die Logs der zugrunde liegenden Knotendienste. Da kubelet den Lebenszyklus aller Pods auf dem Knoten verwaltet, sind seine Logs für die Fehlerbehebung bei Problemen wie Containerstarts, OOM-Ereignissen (Out of Memory, fehlender Speicher), Prüfungsfehlern und Fehlern beim Einbinden von Volumes unerlässlich. Diese Logs sind auch entscheidend für die Diagnose von Problemen auf Knotenebene, z. B. bei einem Knoten mit dem Status NotReady.

  Da containerd den Lebenszyklus Ihrer Container verwaltet, einschließlich des Abrufens von Images, sind die Logs für die Fehlerbehebung bei Problemen, die auftreten, bevor das kubelet den Container starten kann, von entscheidender Bedeutung. containerd-Logs helfen Ihnen, Probleme auf Knotenebene in GKE zu diagnostizieren, da sie die spezifischen Aktivitäten und potenziellen Fehler der Containerlaufzeit dokumentieren.

• App-Logs (stdout, stderr): Die Standardausgabe- und Fehlerstreams aus Ihren containerisierten Prozessen. Diese Logs sind für die Fehlerbehebung von app-spezifischen Problemen wie Abstürzen, Fehlern oder unerwartetem Verhalten unerlässlich.

• Audit-Logs: Diese Logs beantworten die Frage „Wer hat was, wo und wann getan?“ für Ihren Cluster. Sie verfolgen administrative Aktionen und API-Aufrufe, die an den Kubernetes API-Server gesendet werden. Das ist nützlich, um Probleme zu diagnostizieren, die durch Konfigurationsänderungen oder unbefugten Zugriff verursacht werden.

Häufige Fehlerbehebungsszenarien

Nachdem Sie ein Problem identifiziert haben, können Sie diese Logs abfragen, um herauszufinden, was passiert ist. Protokolle können Ihnen bei folgenden Problemen helfen:

• Wenn ein Knoten den Status NotReady hat, sehen Sie sich die Knotenlogs an. Die Logs kubelet und containerd geben oft Aufschluss über die zugrunde liegende Ursache, z. B. Netzwerkprobleme oder Ressourcenbeschränkungen.
• Wenn ein neuer Knoten nicht bereitgestellt werden kann und dem Cluster nicht beitreten kann, sehen Sie sich die Logs des seriellen Ports des Knotens an. In diesen Logs werden Aktivitäten beim frühen Start und beim Starten von kubelet erfasst, bevor die Logging-Agents des Knotens vollständig aktiv sind.
• Wenn ein Pod in der Vergangenheit nicht gestartet wurde, sehen Sie in den App-Logs für diesen Pod nach, ob Abstürze aufgetreten sind. Wenn die Logs leer sind oder der Pod nicht geplant werden kann, suchen Sie in den Audit-Logs nach relevanten Ereignissen oder in den Knoten-Logs auf dem Zielknoten nach Hinweisen auf Ressourcenengpässe oder Fehler beim Abrufen von Images.
• Wenn eine kritische Bereitstellung gelöscht wurde und niemand weiß, warum, können Sie die Audit-Logs für Administratoraktivitäten abfragen. Anhand dieser Logs können Sie ermitteln, welcher Nutzer oder welches Dienstkonto den API-Aufruf zum Löschen ausgegeben hat. So haben Sie einen klaren Ausgangspunkt für Ihre Untersuchung.

Auf Logs zugreifen

Mit dem Log-Explorer können Sie GKE-Logs in der Google Cloud Console abfragen, ansehen und analysieren. Der Log-Explorer bietet leistungsstarke Filteroptionen, mit denen Sie Ihr Problem eingrenzen können.

So greifen Sie auf den Log-Explorer zu und verwenden ihn:

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

   Zum Log-Explorer

2. Geben Sie im Bereich „Abfrage“ eine Abfrage ein. Verwenden Sie die Logging-Abfragesprache, um gezielte Abfragen zu schreiben. Hier sind einige gängige Filter für den Anfang:

   Filtertyp	Beschreibung	Beispielwert
   resource.type	Der Typ der Kubernetes-Ressource.	k8s_cluster, k8s_node, k8s_pod, k8s_container
   log_id	Der Logstream der Ressource.	stdout, stderr
   resource.labels.RESOURCE_TYPE.name	Nach Ressourcen mit einem bestimmten Namen filtern  Ersetzen Sie RESOURCE_TYPE durch den Namen der Ressource, die Sie abfragen möchten. Beispiel: namespace oder pod.	example-namespace-name, example-pod-name
   severity	Der Schweregrad des Logs.	DEFAULT: INFO, WARNING, ERROR, CRITICAL
   jsonPayload.message=~	Eine Suche nach regulären Ausdrücken für Text in der Logmeldung.	scale.down.error.failed.to.delete.node.min.size.reached

   Wenn Sie beispielsweise Probleme mit einem bestimmten Pod beheben möchten, können Sie seine Fehlerlogs isolieren. Wenn Sie nur Logs mit dem Schweregrad ERROR für diesen Pod sehen möchten, verwenden Sie die folgende Abfrage:

   resource.type="k8s_container"
   resource.labels.pod_name="POD_NAME"
   resource.labels.namespace_name="NAMESPACE_NAME"
   severity=ERROR
   

   Ersetzen Sie Folgendes:

   • POD_NAME: der Name des Pods, bei dem Probleme auftreten.
   • NAMESPACE_NAME: der Namespace, in dem sich der Pod befindet. Wenn Sie nicht sicher sind, welcher Namespace verwendet wird, sehen Sie sich die Spalte Namespace in der Ausgabe des Befehls kubectl get pods an.

   Weitere Beispiele finden Sie in der Google Cloud Observability-Dokumentation unter Kubernetes-bezogene Abfragen.

3. Klicken Sie auf Abfrage ausführen.

4. Wenn Sie die vollständige Log-Nachricht mit JSON-Nutzlast, Metadaten und Zeitstempel sehen möchten, klicken Sie auf den Logeintrag.

Weitere Informationen zu GKE-Logs finden Sie unter GKE-Logs.

Proaktives Monitoring mit Cloud Monitoring durchführen

Nachdem ein Problem aufgetreten ist, ist das Überprüfen von Logs ein wichtiger Schritt bei der Fehlerbehebung. Ein wirklich robustes System erfordert jedoch auch einen proaktiven Ansatz, um Probleme zu erkennen, bevor sie zu einem Ausfall führen.

Verwenden Sie Cloud Monitoring, um zukünftige Probleme proaktiv zu erkennen und Leistungskennzahlen im Zeitverlauf zu verfolgen. Cloud Monitoring bietet Dashboards, Messwerte und Benachrichtigungsfunktionen. Mit diesen Tools können Sie steigende Fehlerraten, zunehmende Latenz oder Ressourcenbeschränkungen erkennen und so reagieren, bevor Nutzer betroffen sind.

Nützliche Messwerte ansehen

GKE sendet automatisch eine Reihe von Messwerten an Cloud Monitoring. In den folgenden Abschnitten sind einige der wichtigsten Messwerte für die Fehlerbehebung aufgeführt:

• Messwerte für Containerleistung und -zustand
• Messwerte für Knotenleistung und ‑zustand
• Messwerte zu Leistung und Zustand von Pods

Eine vollständige Liste der GKE-Messwerte finden Sie unter GKE-Systemmesswerte.

Messwerte für Containerleistung und -zustand

Beginnen Sie mit diesen Messwerten, wenn Sie ein Problem mit einer bestimmten App vermuten. Mit diesen Messwerten können Sie den Zustand Ihrer App überwachen und feststellen, ob ein Container häufig neu gestartet wird, der Arbeitsspeicher knapp wird oder die CPU-Grenzwerte überschritten werden.

Knotenleistungs- und ‑zustandsmesswerte

Sehen Sie sich diese Messwerte an, wenn Sie Probleme mit der zugrunde liegenden GKE-Infrastruktur diagnostizieren müssen. Diese Messwerte sind entscheidend, um den allgemeinen Zustand und die Kapazität Ihrer Knoten zu verstehen. Sie helfen Ihnen, zu untersuchen, ob der Knoten fehlerhaft oder überlastet ist oder ob der Knoten genügend Arbeitsspeicher hat, um neue Pods zu planen.

Leistungs- und Gesundheitsmesswerte für Pods

Mithilfe dieser Messwerte können Sie Probleme im Zusammenhang mit der Interaktion eines Pods mit seiner Umgebung beheben, z. B. Netzwerk- und Speicherprobleme. Verwenden Sie diese Messwerte, wenn Sie langsam startende Pods diagnostizieren, potenzielle Probleme mit der Netzwerkverbindung untersuchen oder den Speicher proaktiv verwalten müssen, um Schreibfehler aufgrund von vollen Volumes zu vermeiden.

Messwerte mit dem Metrics Explorer visualisieren

Um den Status Ihrer GKE-Umgebung zu visualisieren, können Sie mit dem Metrics Explorer Diagramme auf Grundlage von Messwerten erstellen.

So verwenden Sie den Metrics Explorer:

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

   Zum Metrics Explorer

2. Wählen Sie im Feld Messwerte den Messwert aus, den Sie untersuchen möchten, oder geben Sie ihn ein.

3. Sehen Sie sich die Ergebnisse an und beobachten Sie Trends im Zeitverlauf.

Wenn Sie beispielsweise den Arbeitsspeicherverbrauch von Pods in einem bestimmten Namespace untersuchen möchten, können Sie Folgendes tun:

1. Wählen Sie in der Liste Messwert auswählen den Messwert kubernetes.io/container/memory/used_bytes aus und klicken Sie auf Übernehmen.
2. Klicken Sie auf Filter hinzufügen und wählen Sie namespace_name aus.
3. Wählen Sie in der Liste Wert den Namespace aus, den Sie untersuchen möchten.
4. Wählen Sie im Feld Aggregation die Option Summe > pod_name aus und klicken Sie auf OK. Mit dieser Einstellung wird für jeden Pod eine separate Zeitachse angezeigt.
5. Klicken Sie auf Diagramm speichern.

Das resultierende Diagramm zeigt die Speichernutzung für jeden Pod im Zeitverlauf. So können Sie Pods mit ungewöhnlich hohem oder sprunghaft ansteigendem Speicherverbrauch visuell erkennen.

Mit Metrics Explorer können Sie die Messwerte, die Sie sehen möchten, sehr flexibel erstellen. Weitere Informationen zu den erweiterten Optionen des Metrics Explorers finden Sie in der Cloud Monitoring-Dokumentation unter Diagramme mit dem Metrics Explorer erstellen.

Benachrichtigungen für die proaktive Problemerkennung erstellen

Wenn Sie Benachrichtigungen erhalten möchten, wenn etwas schiefgeht oder wenn Messwerte bestimmte Grenzwerte überschreiten, richten Sie Benachrichtigungsrichtlinien in Cloud Monitoring ein.

So richten Sie beispielsweise eine Benachrichtigungsrichtlinie ein, die Sie benachrichtigt, wenn das CPU-Limit des Containers fünf Minuten lang über 80% liegt:

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

   Zu Benachrichtigungen

2. Klicken Sie auf Richtlinie erstellen.

3. Filtern Sie im Feld Messwert auswählen nach CPU limit utilization und wählen Sie dann den folgenden Messwert aus: kubernetes.io/container/cpu/limit_utilization.

4. Klicken Sie auf Übernehmen.

5. Lassen Sie das Feld Filter hinzufügen leer. Mit dieser Einstellung wird eine Benachrichtigung ausgelöst, wenn ein Cluster gegen den Schwellenwert verstößt.

6. Führen Sie im Bereich Daten transformieren folgende Schritte aus:

   1. Wählen Sie in der Liste Rollierendes Fenster die Option 1 Minute aus. Mit dieser Einstellung berechnet Google Cloud jede Minute einen Durchschnittswert.

   2. Wählen Sie in der Liste Funktion für rollierendes Zeitfenster die Option Mittelwert aus.

      Bei beiden Einstellungen wird die CPU-Limit-Auslastung für jeden Container jede Minute gemittelt.

7. Klicken Sie auf Weiter.

8. Führen Sie im Abschnitt Benachrichtigung konfigurieren die folgenden Schritte aus:

   1. Wählen Sie als Bedingungstyp die Option Schwellenwert aus.
   2. Wählen Sie unter Benachrichtigungstrigger die Option Bei jedem Verstoß aus.
   3. Wählen Sie für Grenzwertposition die Option Über Grenzwert aus.
   4. Geben Sie für Grenzwert den Wert 0.8 ein. Dieser Wert stellt den 80‑%‑Schwellenwert dar, den Sie überwachen möchten.
   5. Klicken Sie auf Erweiterte Optionen.
   6. Wählen Sie in der Liste Retest window (Zeitfenster für erneuten Test) die Option 5 min aus. Mit dieser Einstellung wird die Benachrichtigung nur ausgelöst, wenn die CPU-Auslastung über einen kontinuierlichen Zeitraum von fünf Minuten über 80 % bleibt. Dadurch werden Fehlalarme durch kurze Spitzen reduziert.
   7. Geben Sie im Feld Bedingungsname einen aussagekräftigen Namen für die Bedingung ein.
   8. Klicken Sie auf Weiter.

9. Führen Sie im Bereich Benachrichtigungen konfigurieren und Benachrichtigung fertigstellen die folgenden Schritte aus:

   1. Wählen Sie in der Liste Benachrichtigungskanäle den Kanal aus, über den Sie die Benachrichtigung erhalten möchten. Wenn Sie keinen Kanal haben, klicken Sie auf Benachrichtigungskanäle verwalten, um einen zu erstellen.
   2. Geben Sie im Feld Benachrichtigungsrichtlinie benennen einen eindeutigen und aussagekräftigen Namen für die Richtlinie ein.
   3. Behalten Sie in allen anderen Feldern die Standardwerte bei.
   4. Klicken Sie auf Weiter.

10. Prüfen Sie die Richtlinie. Wenn alles korrekt aussieht, klicken Sie auf Richtlinie erstellen.

Weitere Informationen zum Erstellen von Benachrichtigungen finden Sie in der Cloud Monitoring-Dokumentation unter Benachrichtigungen – Übersicht.

Diagnose mit Gemini Cloud Assist beschleunigen

Manchmal ist die Ursache Ihres Problems nicht sofort ersichtlich, auch wenn Sie die in den vorherigen Abschnitten beschriebenen Tools verwendet haben. Die Untersuchung komplexer Fälle kann zeitaufwendig sein und erfordert umfassendes Fachwissen. Für solche Szenarien kann Gemini Cloud Assist hilfreich sein. Es kann automatisch verborgene Muster erkennen, Anomalien aufdecken und Zusammenfassungen bereitstellen, damit Sie schnell eine wahrscheinliche Ursache ermitteln können.

Auf Gemini Cloud Assist zugreifen

So greifen Sie auf Gemini Cloud Assist zu:

1. Rufen Sie in der Google Cloud Console eine beliebige Seite auf.

2. Klicken Sie in der Google Cloud -Symbolleiste auf spark Gemini Cloud Assist-Chat öffnen oder schließen.

   Der Bereich Cloud Assist wird geöffnet. Sie können auf Beispiel-Prompts klicken, sofern sie angezeigt werden, oder einen Prompt in das Feld Prompt eingeben eingeben.

Beispiel-Prompts ansehen

Damit Sie besser nachvollziehen können, wie Gemini Cloud Assist Ihnen helfen kann, finden Sie hier einige Beispiel-Prompts:

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Weitere Informationen zum Schreiben besserer Prompts
• Informationen zur Verwendung des Gemini Cloud Assist-Bereichs
• Gemini für Google Cloud  – Übersicht
• Weitere Informationen dazu, wie Gemini für Google Cloud Ihre Daten verwendet

Gemini Cloud Assist-Prüfungen verwenden

Neben dem interaktiven Chat kann Gemini Cloud Assist mit Gemini Cloud Assist-Prüfungen auch automatisierte, detaillierte Analysen durchführen. Diese Funktion ist direkt in Workflows wie Logs Explorer integriert und ist ein leistungsstarkes Tool zur Ursachenanalyse.

Wenn Sie eine Untersuchung über einen Fehler oder eine bestimmte Ressource starten, analysiert Gemini Cloud Assist Logs, Konfigurationen und Messwerte. Anhand dieser Daten werden dann sortierte Beobachtungen und Hypothesen zu wahrscheinlichen Ursachen erstellt und Sie erhalten Empfehlungen für die nächsten Schritte. Sie können diese Ergebnisse auch in ein Google Cloud Support-Ticket übertragen, um wertvollen Kontext bereitzustellen, der Ihnen helfen kann, Ihr Problem schneller zu beheben.

Weitere Informationen finden Sie in der Gemini-Dokumentation unter Gemini Cloud Assist-Prüfungen.

Alles zusammenführen: Beispiel für ein Fehlerbehebungsszenario

In diesem Beispiel wird gezeigt, wie Sie eine Kombination aus GKE-Tools verwenden können, um ein häufiges reales Problem zu diagnostizieren und zu verstehen: ein Container, der aufgrund von unzureichendem Arbeitsspeicher wiederholt abstürzt.

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 das Problem 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 Instabilität der App führt. Dies 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 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 spezifischen 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 -Konsole 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

• Hinweise zur Behebung bestimmter Probleme finden Sie in den Anleitungen zur Fehlerbehebung für GKE.

• 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.