Fehlerbehebung bei Clusterupgrades

Wenn das Upgrade der Google Kubernetes Engine-Steuerungsebene (GKE) oder des Knotenpools fehlschlägt, hängen bleibt oder unerwartetes Arbeitslastverhalten verursacht, müssen Sie möglicherweise Fehlerbehebung durchführen. Es ist wichtig, dass Sie Ihre Steuerungsebene und Ihre Knotenpools auf dem neuesten Stand halten, um die Sicherheit und Leistung zu gewährleisten. Wenn Sie Probleme beheben, sorgen Sie dafür, dass Ihre Umgebung stabil bleibt.

Ein guter erster Schritt zur Behebung häufiger Probleme beim Upgrade ist die Überwachung des Cluster-Upgrades. Dort finden Sie dann Informationen zur Behebung des Problems:

Diese Informationen sind wichtig für Plattformadministratoren und ‑betreiber, die die Ursachen für fehlgeschlagene oder hängengebliebene Upgrades diagnostizieren, Wartungsrichtlinien verwalten und Versionsinkompatibilitäten beheben möchten. Anwendungsentwickler finden hier Informationen zum Beheben von Problemen mit Arbeitslasten nach dem Upgrade und dazu, wie sich Arbeitslastkonfigurationen wie PodDisruptionBudgets auf die Dauer des Upgrades auswirken können. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Clusterupgrade überwachen

Um Probleme beim Upgrade effektiver zu beheben, sollten Sie zuerst herausfinden, was während des Upgrade-Vorgangs passiert ist. GKE bietet mehrere Tools, mit denen Sie diesen Prozess im Blick behalten können.

In der Google Cloud Console bietet das Upgrade-Dashboard eine projektweite Ansicht aller laufenden Cluster-Upgrades, eine Zeitachse der letzten Ereignisse und Warnungen vor potenziellen Blockierungen wie aktiven Wartungsausschlüssen oder bevorstehenden Versionsverwerfungen. Für Befehlszeilen- oder automatisierte Prüfungen können Sie mit dem Befehl gcloud container operations list den Status bestimmter Upgradevorgänge abrufen. Weitere Informationen finden Sie unter Einblick in Cluster-Upgrades erhalten.

Für eine detailliertere Untersuchung ist Cloud Logging Ihre primäre Informationsquelle. GKE zeichnet detaillierte Informationen zu Upgrade-Prozessen für Steuerungsebenen und Knotenpools in Cloud Logging auf. Dazu gehören Audit-Logs auf hoher Ebene, in denen die wichtigsten Upgradevorgänge aufgezeichnet werden, sowie detailliertere Logs wie Kubernetes-Ereignisse und Logs von Knotenkomponenten, die weitere Informationen zu bestimmten Fehlern enthalten können.

In den folgenden Abschnitten wird erläutert, wie Sie diese Logs mit dem Log-Explorer oder der gcloud CLI abfragen. Weitere Informationen finden Sie unter Upgrade-Logs prüfen.

Upgrade-Vorgang anhand von Audit-Logs identifizieren

Wenn Sie nicht wissen, welcher Upgradevorgang fehlgeschlagen ist, können Sie GKE-Prüfprotokolle verwenden. In Audit-Logs werden Verwaltungsaktionen aufgezeichnet. Sie enthalten einen autoritativen Datensatz dazu, wann ein Upgrade initiiert wurde und welchen Status es hat. Verwenden Sie die folgenden Abfragen im Log-Explorer, um den relevanten Vorgang zu finden.

Ereignistyp Logabfrage
Automatisches Upgrade der Steuerungsebene 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie untersuchen möchten.

Diese Abfrage zeigt die Zielversion der Steuerungsebene und die vorherige Version der Steuerungsebene.
Manuelles Upgrade der Steuerungsebene 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
Automatisches Upgrade von Knotenpools (nur Zielversion) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Ersetzen Sie NODEPOOL_NAME durch den Namen des Knotenpools, der zum Cluster gehört.
Manuelles Upgrade von Knotenpools 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

So finden Sie die vorherige Knotenpoolversion:

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

Detaillierte Fehlermeldungen in GKE-Logs finden

Nachdem Sie im Audit-Log gesehen haben, welcher Vorgang wann fehlgeschlagen ist, können Sie nach detaillierteren Fehlermeldungen von GKE-Komponenten im selben Zeitraum suchen. Diese Logs können die genauen Gründe für einen fehlgeschlagenen Upgrade enthalten, z. B. ein falsch konfiguriertes PodDisruptionBudget-Objekt.

Wenn Sie beispielsweise in den Audit-Logs einen fehlgeschlagenen UPGRADE_NODES-Vorgang finden, können Sie den Zeitstempel verwenden, um Ihre Suche einzugrenzen. Geben Sie im Log-Explorer die folgende Abfrage ein und verwenden Sie dann die Zeitraumauswahl, um sich auf den Zeitpunkt zu konzentrieren, zu dem der Fehler aufgetreten ist:

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • NODE_NAME: Der Name des Knotens im Cluster, den Sie auf Fehler prüfen möchten.

Upgrade-Ereignisse mit der gcloud CLI ansehen

Neben dem Log-Explorer können Sie auch gcloud CLI-Befehle verwenden, um Upgrade-Ereignisse zu prüfen.

Führen Sie den folgenden Befehl aus, um nach Upgrades der Steuerungsebene zu suchen:

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

Die Ausgabe sieht etwa so aus:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Diese Ausgabe enthält die folgenden Werte:

  • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
  • CLUSTER_NAME: Der Name Ihres Clusters.

Führen Sie den folgenden Befehl aus, um nach Knotenpool-Upgrades zu suchen:

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

Die Ausgabe sieht etwa so aus:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Beispiel: Protokolle zur Fehlerbehebung bei Upgrades der Steuerungsebene verwenden

Das folgende Beispiel zeigt, wie Sie Logs verwenden, um Probleme bei einem fehlgeschlagenen Upgrade der Steuerungsebene zu beheben:

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

    Zum Log-Explorer

  2. Filtern Sie im Bereich „Abfrage“ nach Upgrade-Logs der Steuerungsebene, indem Sie die folgende Abfrage eingeben:

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie untersuchen möchten.

  3. Klicken Sie auf Abfrage ausführen.

  4. Prüfen Sie die Logausgabe auf die folgenden Informationen:

  5. Prüfen Sie, ob das Upgrade gestartet wurde: Suchen Sie nach UPGRADE_MASTER-Ereignissen, die kurz nach dem Start des Upgrades aufgetreten sind. Das Vorhandensein dieser Ereignisse bestätigt, dass entweder Sie oder GKE den Upgradeprozess ausgelöst haben.

    • Versionen prüfen: Prüfen Sie die folgenden Felder, um die vorherige und die Zielversion zu bestätigen:

      • protoPayload.metadata.previousMasterVersion: Hier wird die Version der Steuerungsebene vor dem Upgrade angezeigt.

      • protoPayload.metadata.currentMasterVersion: Die Version, auf die GKE versucht hat, die Steuerungsebene zu aktualisieren.

        Wenn Sie beispielsweise ein Upgrade auf Version 1.30.1-gke.1234 ausführen wollten, aber versehentlich 1.30.2-gke.4321 angegeben haben (eine neuere, möglicherweise inkompatible Version für Ihre Arbeitslasten), würde diese Diskrepanz durch die Überprüfung dieser beiden Felder deutlich. Wenn im Feld currentMasterVersion nach längerer Zeit immer noch die frühere Version angezeigt wird, bedeutet das, dass beim Upgrade die neue Version nicht angewendet wurde.

    • Nach Fehlern suchen: Prüfen Sie, ob wiederholt UPGRADE_MASTER-Ereignisse oder andere Fehlermeldungen angezeigt werden. Wenn das Vorgangsprotokoll ohne Angabe des Abschlusses oder Fehlers endet, deutet dies auf ein Problem hin.

Nachdem Sie einen bestimmten Fehler oder ein bestimmtes Verhalten in den Logs gefunden haben, können Sie diese Informationen verwenden, um die passende Lösung in diesem Leitfaden zu finden.

Fehlerbehebung bei Knotenpool-Upgrades, die länger als gewöhnlich dauern

Wenn das Upgrade Ihres Knotenpools länger als erwartet dauert, versuchen Sie es mit den folgenden Lösungen:

  1. Prüfen Sie den Wert von terminationGracePeriodSeconds im Manifest Ihrer Pods. Dieser Wert definiert die maximale Zeit, die Kubernetes wartet, bis ein Pod ordnungsgemäß heruntergefahren wird. Ein hoher Wert (z. B. einige Minuten) kann die Upgrade-Dauer erheblich verlängern, da Kubernetes für jeden Pod den gesamten Zeitraum abwartet. Wenn diese Verzögerung Probleme verursacht, sollten Sie den Wert verringern.

  2. Überprüfen Sie Ihre PodDisruptionBudget-Objekte. Wenn ein Knoten geleert wird, wartet GKE maximal eine Stunde pro Knoten, bis die Arbeitslasten ordnungsgemäß entfernt werden. Wenn Ihr PodDisruptionBudget-Objekt zu restriktiv ist, kann dies verhindern, dass ein ordnungsgemäßes Entfernen jemals erfolgreich ist. In diesem Fall verwendet GKE den gesamten einstündigen Kulanzzeitraum, um den Knoten zu leeren, bevor er schließlich das Zeitlimit überschreitet und das Upgrade erzwungen wird. Diese Verzögerung, die sich über mehrere Knoten wiederholt, ist eine häufige Ursache für ein langsames Cluster-Upgrade. So prüfen Sie, ob ein restriktives PodDisruptionBudget-Objekt die Ursache für langsame Upgrades ist:

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

      Zum Log-Explorer

    2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. Klicken Sie auf Abfrage ausführen.

    4. Sehen Sie sich die Logausgabe an. Wenn das PodDisruptionBudget-Objekt die Ursache des Problems ist, sieht die Ausgabe in etwa so aus:

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. Nachdem Sie bestätigt haben, dass ein PodDisruptionBudget-Objekt die Ursache ist, listen Sie alle PodDisruptionBudget-Objekte auf und prüfen Sie, ob die Einstellungen angemessen sind:

      kubectl get pdb --all-namespaces

      Die Ausgabe sieht etwa so aus:

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      In diesem Beispiel benötigt die PodDisruptionBudget mit dem Namen one_pdb mindestens drei verfügbare Pods. Da durch das Entfernen eines Pods während des Upgrades nur zwei Pods verfügbar wären, wird das Budget durch die Aktion verletzt und das Upgrade wird angehalten.

      Wenn Ihr PodDisruptionBudget-Objekt wie gewünscht funktioniert, müssen Sie nichts weiter tun. Wenn nicht, sollten Sie die PodDisruptionBudget-Einstellungen während des Upgrade-Zeitraums lockern.

  3. Prüfen Sie die Knotenaffinitäten. Restriktive Regeln können Upgrades verlangsamen, da sie verhindern, dass Pods auf verfügbaren Knoten neu geplant werden, wenn diese Knoten nicht den erforderlichen Labels entsprechen. Dieses Problem ist besonders problematisch bei Surge-Upgrades, da die Knotenaffinität die Anzahl der Knoten begrenzen kann, die gleichzeitig aktualisiert werden können, wenn Knoten mit den richtigen Labels nicht über genügend Clusterkapazität zum Hosten der neuen Pods verfügen.

  4. Prüfen Sie, ob Sie die Upgrade-Strategie mit kurzer Lebensdauer verwenden. GKE verwendet die kurzlebige Upgradestrategie für Flex-Start-Knoten und für Knoten, die nur die Warteschlangenbereitstellung in Clustern mit GKE-Version 1.32.2-gke.1652000 oder höher verwenden. Wenn Sie diese Upgradestrategie verwenden, kann der Upgradevorgang bis zu sieben Tage dauern.

  5. Prüfen Sie, ob Sie Pods mit verlängerter Laufzeit verwenden (verfügbar für Autopilot-Cluster). Während eines Upgrades muss GKE alle Pods von einem Knoten entfernen, bevor der Vorgang abgeschlossen werden kann. Bei einem von GKE initiierten Upgrade bereinigt GKE Pods mit verlängerter Laufzeit jedoch bis zu sieben Tage lang nicht. Dieser Schutz verhindert, dass der Knoten entleert wird. GKE beendet den Pod erst nach Ablauf dieses Zeitraums. Diese erhebliche Verzögerung von mehreren Tagen für einen einzelnen Knoten kann dazu führen, dass weitere Knoten-Upgrades im Autopilot-Cluster verzögert werden.

  6. Angehängte Persistent Volumes können dazu führen, dass ein Upgrade-Prozess länger als gewöhnlich dauert, da die Verwaltung des Lebenszyklus dieser Volumes Zeit in Anspruch nimmt.

  7. Prüfen Sie den Status des automatischen Cluster-Upgrades. Wenn der Grund SYSTEM_CONFIG ist, sind automatische Upgrades aus technischen oder geschäftlichen Gründen vorübergehend pausiert. Wenn Sie diesen Grund sehen, empfehlen wir, ein manuelles Upgrade nur dann durchzuführen, wenn es erforderlich ist.

Fehlerbehebung bei unvollständigen Knotenpool-Upgrades

Gelegentlich kann GKE ein Knotenpool-Upgrade nicht abschließen, sodass der Knotenpool nur teilweise aktualisiert wird. Es gibt mehrere Gründe, warum Upgrades nicht vollständig durchgeführt werden:

  • Das Upgrade wurde manuell abgebrochen.
  • Das Upgrade ist aufgrund eines Problems fehlgeschlagen, z. B. weil neue Knoten nicht registriert werden konnten, IP-Adressen erschöpft waren oder Ressourcenkontingente nicht ausreichten.
  • GKE hat das Upgrade pausiert. Diese Pause kann beispielsweise erfolgen, um ein Upgrade auf eine Version mit bekannten Problemen zu verhindern oder während bestimmter von Google initiierter Wartungszeiträume.
  • Wenn Sie automatische Upgrades verwenden, wurde ein Wartungsfenster beendet, bevor das Upgrade abgeschlossen werden konnte. Alternativ kann ein Wartungsausschlusszeitraum begonnen haben, bevor das Upgrade abgeschlossen werden konnte. Weitere Informationen finden Sie unter Wartungsfenster verhindert Abschluss der Knotenaktualisierung.

Wenn ein Knotenpool nur teilweise aktualisiert wird, werden die Knoten mit unterschiedlichen Versionen ausgeführt. Um dieses Problem zu beheben und zu prüfen, ob alle Knoten im Knotenpool dieselbe Version ausführen, können Sie entweder das Upgrade fortsetzen oder das Upgrade zurücksetzen.

Die Strategie für Surge-Upgrades und die Strategie für Blau/Grün-Upgrades interagieren jedoch unterschiedlich mit Wartungsfenstern:

  • Surge-Upgrades: Der Upgradevorgang wird pausiert, wenn er über das Wartungsfenster hinaus ausgeführt wird. Das Upgrade wird während des nächsten geplanten Wartungsfensters automatisch fortgesetzt.
  • Blau/Grün-Upgrades: Der Upgradevorgang wird bis zum Abschluss fortgesetzt, auch wenn er das Wartungsfenster überschreitet. Blau/Grün-Upgrades bieten eine detaillierte Steuerung des Upgradetempo mit Funktionen wie Batch- und Knotenpool-Soak-Zeiten. Der zusätzliche Knotenpool trägt dazu bei, dass Arbeitslasten betriebsbereit bleiben.

Fehlerbehebung bei unerwartetem automatischen Upgrade

Manchmal werden automatische Cluster-Upgrades nicht wie erwartet ausgeführt. In den folgenden Abschnitten wird beschrieben, wie Sie die folgenden Probleme beheben können:

Cluster können nicht aktualisiert werden, wenn automatische Knoten-Upgrades aktiviert sind

Wenn Sie automatische Knotenupgrades nicht deaktiviert haben, aber kein Upgrade erfolgt, versuchen Sie es mit den folgenden Lösungen:

  1. Wenn Sie eine Release-Version verwenden, prüfen Sie, ob automatische Knotenupgrades blockiert sind. Für Cluster, die für eine Release-Version registriert sind, ist Ihr maintenancePolicy die primäre Methode zum Steuern automatischer Upgrades. Dadurch kann verhindert werden, dass ein Upgrade gestartet wird, oder ein bereits laufendes Upgrade kann unterbrochen werden. Ein aktiver Wartungsausschluss kann ein Upgrade vollständig blockieren und der Zeitpunkt eines Wartungsfensters kann zu einer Unterbrechung führen. Prüfen Sie in Ihren maintenancePolicy, ob eine der folgenden Einstellungen die Ursache ist:

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters des zu beschreibenden Knotenpools.
    • PROJECT_ID: die Projekt-ID des Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

    Die Ausgabe sieht etwa so aus:

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    Prüfen Sie in der Ausgabe im Abschnitt maintenancePolicy die folgenden beiden Bedingungen:

    • So prüfen Sie, ob ein Upgrade blockiert ist: Suchen Sie nach einem aktiven maintenanceExclusion mit dem Bereich NO_MINOR_OR_NODE_UPGRADES. Diese Einstellung verhindert in der Regel, dass GKE ein neues Upgrade startet.
    • So prüfen Sie, ob ein Upgrade unterbrochen wurde: Sehen Sie sich den Zeitplan für Ihre dailyMaintenanceWindow oder maintenanceExclusions an. Wenn ein Upgrade über das geplante Fenster hinausläuft, pausiert GKE das Upgrade, was zu einem teilweisen Upgrade führt. Weitere Informationen zu teilweisen Upgrades finden Sie im Abschnitt Fehlerbehebung bei unvollständigen Upgrades.

    Um diese Probleme zu beheben, können Sie warten, bis ein Ausschluss endet, ihn entfernen oder Ihre Wartungsfenster anpassen, damit mehr Zeit für die Durchführung von Upgrades zur Verfügung steht.

  2. Wenn Sie keinen Release-Version verwenden, prüfen Sie, ob das automatische Upgrade für den Knotenpool weiterhin aktiviert ist:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    Ersetzen Sie NODE_POOL_NAME durch den Namen des zu beschreibenden Knotenpools.

    Wenn für diesen Knotenpool automatische Knotenpool-Upgrades aktiviert sind, ist die Ausgabe im Feld autoUpgrade folgende:

    management:
  autoUpgrade: true

    Wenn autoUpgrade auf false festgelegt ist oder das Feld nicht vorhanden ist, aktivieren Sie automatische Upgrades.

  3. Das Upgrade wurde möglicherweise noch nicht in der Region oder Zone bereitgestellt, in der sich Ihr Cluster befindet, auch wenn es in den Versionshinweisen erwähnt wurde. GKE-Upgrades werden über mehrere Tage (in der Regel vier oder mehr) schrittweise eingeführt. Nachdem das Upgrade Ihre Region oder Zone erreicht hat, wird es nur während genehmigter Wartungsfenster gestartet. Beispiel: Eine Einführung kann die Zone Ihres Clusters am ersten Tag der Einführung erreichen, das nächste Wartungsfenster des Clusters ist jedoch erst am siebten Tag. In diesem Szenario führt GKE erst am siebten Tag ein Upgrade des Clusters durch. Weitere Informationen finden Sie im GKE-Releasezeitplan.

Cluster werden automatisch aktualisiert, wenn automatische Upgrades nicht aktiviert sind

Um die Zuverlässigkeit, Verfügbarkeit, Sicherheit und Leistung Ihrer GKE-Umgebung zu gewährleisten, kann GKE Ihre Cluster automatisch aktualisieren, auch wenn Sie keine automatischen Upgrades verwenden.

GKE umgeht möglicherweise Ihre Wartungsfenster, Ausschlüsse oder deaktivierten automatischen Knotenpool-Upgrades, um aus mehreren wichtigen Gründen erforderliche Upgrades durchzuführen, z. B. aus den folgenden:

  • Cluster, deren Steuerungsebenen eine GKE-Version ausführen, die das Ende des Supports erreicht hat. Ob das Enddatum des Supports für Ihren Cluster bevorsteht, können Sie im geschätzten Zeitplan für Release-Versionen nachsehen.
  • Knoten in einem Cluster, auf denen eine GKE-Version ausgeführt wird, die das Ende des Supports erreicht hat.
  • Cluster, die sich in einem aktiven Zustand befinden, aber über einen längeren Zeitraum keine Aktivität aufweisen. GKE kann beispielsweise einen Cluster ohne API-Aufrufe, ohne Netzwerkverkehr und ohne aktive Nutzung von Subnetzen als verworfen betrachten.
  • Cluster, die eine anhaltende Instabilität aufweisen und wiederholt Betriebsstatus durchlaufen. Beispielsweise Status, die ohne Lösung von „läuft“ zu „eingeschränkt“, „in Reparatur“ oder „gesperrt“ und zurück zu „läuft“ wechseln.

Wenn Sie ein unerwartetes automatisches Upgrade feststellen und Bedenken hinsichtlich der Auswirkungen dieses Upgrades auf Ihren Cluster haben, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei fehlgeschlagenen Upgrades

Wenn das Upgrade fehlschlägt, gibt GKE Fehlermeldungen aus. In den folgenden Abschnitten werden die Ursachen und Lösungen für die folgenden Fehler erläutert:

Fehler: kube-apiserver ist fehlerhaft

Manchmal wird beim Starten eines manuellen Upgrades der Steuerungsebene der GKE-Version Ihres Clusters die folgende Fehlermeldung angezeigt:

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

Diese Meldung wird in der gcloud CLI und in den Logeinträgen für die Ressourcentypen gke_cluster und gke_nodepool angezeigt.

Dieses Problem tritt auf, wenn einige vom Nutzer bereitgestellte Zulassungs-Webhooks verhindern, dass Systemkomponenten die zulässigen RBAC-Rollen erstellen, die für eine ordnungsgemäße Funktion erforderlich sind.

Während des Upgrades der Steuerungsebene erstellt GKE die Komponente des Kubernetes API-Servers (kube-apiserver) neu. Wenn ein Webhook die RBAC-Rolle für die API-Serverkomponente blockiert, wird der API-Server nicht gestartet und das Clusterupgrade wird nicht abgeschlossen. Auch wenn ein Webhook ordnungsgemäß funktioniert, kann er dazu führen, dass das Clusterupgrade fehlschlägt, da die neu erstellte Steuerungsebene den Webhook möglicherweise nicht erreichen kann.

Kubernetes macht einen automatischen Abgleich der RBAC-Rollen des Standardsystems mit den Standardrichtlinien in der neuesten Nebenversion. Die Standardrichtlinien für Systemrollen ändern sich in neuen Kubernetes-Versionen manchmal.

Für diesen Abgleich erstellt oder aktualisiert GKE die ClusterRoles und ClusterRoleBindings im Cluster. Wenn Sie einen Webhook haben, der die Erstellungs- oder Aktualisierungsanfragen aufgrund des Umfangs der Berechtigungen, die die Standard-RBAC-Richtlinien verwenden, abfängt und ablehnt, kann der API-Server nicht mit der neuen Nebenversion funktionieren.

Um den fehlerhaften Webhook zu identifizieren, prüfen Sie Ihre GKE-Audit-Logs auf RBAC-Aufrufe mit den folgenden Informationen:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

In dieser Ausgabe ist RBAC_RULE der vollständige Name der RBAC-Rolle, z. B. rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Der Name des fehlgeschlagenen Webhooks wird im Log im folgenden Format angezeigt:

admission webhook WEBHOOK_NAME denied the request

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  1. Prüfen Sie Ihre ClusterRoles, um sicherzustellen, dass sie nicht zu restriktiv sind. Ihre Richtlinien dürfen die Anfragen von GKE zum Erstellen oder Aktualisieren der ClusterRoles mit dem Standardpräfix system: nicht blockieren.
  2. Passen Sie Ihren Webhook so an, dass keine Anfragen zum Erstellen und Aktualisieren von System-RBAC-Rollen abgefangen werden.
  3. Deaktivieren Sie den Webhook.

Fehler: „DeployPatch“ fehlgeschlagen

Manchmal schlägt der Cluster-Upgrade-Vorgang mit dem folgenden Fehler fehl:

DeployPatch failed

Dieser Fehler kann auftreten, wenn die Kubernetes-Steuerungsebene länger als 20 Minuten fehlerhaft bleibt.

Dieser Fehler ist oft vorübergehend, da die Steuerungsebene den Vorgang wiederholt, bis er erfolgreich ist. Wenn das Upgrade weiterhin mit diesem Fehler fehlschlägt, wenden Sie sich an Cloud Customer Care.

Probleme nach einem abgeschlossenen Upgrade beheben

Wenn Sie nach dem Upgrade unerwartetes Verhalten feststellen, finden Sie in den folgenden Abschnitten Anleitungen zur Fehlerbehebung für die folgenden häufigen Probleme:

Unerwartetes Verhalten aufgrund funktionsgefährdender Änderungen

Wenn das Upgrade erfolgreich abgeschlossen wurde, Sie aber nach dem Upgrade unerwartetes Verhalten feststellen, sehen Sie in den GKE-Versionshinweisen nach, ob es Fehler und funktionsgefährdende Änderungen im Zusammenhang mit der Version gibt, auf die der Cluster aktualisiert wurde.

Nach dem Upgrade des Standard-Clusters entfernte Arbeitslasten

Ihre Arbeitslasten werden möglicherweise nach einem Clusterupgrade bereinigt, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Systemarbeitslasten benötigen mehr Speicherplatz, wenn die Steuerungsebene des Clusters die neue GKE-Version ausführt.
  • Ihre vorhandenen Knoten haben nicht genügend Ressourcen, um die neuen Systemarbeitslasten und vorhandenen Arbeitslasten auszuführen.
  • Cluster Autoscaler ist für den Cluster deaktiviert.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  1. Autoscaling für vorhandene Knotenpools aktivieren
  2. Automatische Knotenbereitstellung aktivieren
  3. Neuen Knotenpool erstellen
  4. Vorhandenen Knotenpool vertikal hochskalieren

Pods bleiben nach der Konfiguration der Option „Node Allocatable“ im Status Pending

Wenn Sie Node Allocatable konfiguriert haben, kann ein Upgrade der Knotenversion manchmal dazu führen, dass Pods, die den Status Running hatten, im Status Pending hängen bleiben. Diese Änderung tritt in der Regel auf, weil der aktualisierte Knoten etwas andere Systemressourcen verbraucht oder weil neu geplante Pods nun in die Node Allocatable-Limits auf den neuen oder geänderten Knoten passen müssen, möglicherweise unter strengeren Bedingungen.

Wenn deine Pods nach einem Upgrade den Status Pending haben, versuche es mit den folgenden Lösungen:

  1. Prüfen Sie, ob die CPU- und Arbeitsspeicheranforderungen Ihrer Pods die maximale Auslastung nicht überschreiten. Da GKE CPU und Arbeitsspeicher für Overhead reserviert, können Pods diese Ressourcen nicht anfordern. Pods, die mehr CPU oder Arbeitsspeicher anfordern, als sie verwenden, verhindern, dass andere Pods diese Ressourcen anfordern. Der Cluster ist somit möglicherweise nicht optimal ausgelastet. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pods mit Ressourcenanfragen planen.
  2. Erhöhen Sie die Größe Ihres Clusters.
  3. Wenn Sie prüfen möchten, ob das Upgrade die Ursache für dieses Problem ist, machen Sie das Upgrade rückgängig, indem Sie ein Downgrade Ihrer Knotenpools durchführen.
  4. Konfigurieren Sie Ihren Cluster so, dass Kubernetes-Planer-Messwerte an Cloud Monitoring gesendet und Planer-Messwerte angezeigt werden. Wenn Sie diese Messwerte im Blick behalten, können Sie feststellen, ob genügend Ressourcen für die Ausführung der Pods vorhanden sind.

Probleme mit Versionen und Kompatibilität beheben

Die Verwendung unterstützter und kompatibler Versionen für alle Komponenten Ihres Clusters ist für Stabilität und Leistung unerlässlich. In den folgenden Abschnitten finden Sie Informationen dazu, wie Sie Versions- und Kompatibilitätsprobleme, die sich auf den Upgrade-Prozess auswirken können, erkennen und beheben.

Inkompatibilität zwischen Steuerungsebene und Knotenversion prüfen

Versionsabweichungen zwischen der Steuerungsebene und den Knoten können zu Clusterinstabilität führen. Die GKE-Richtlinie zur Versionsinkompatibilität besagt, dass eine Steuerungsebene nur mit Knoten kompatibel ist, die bis zu zwei Nebenversionen älter sind. Eine Steuerungsebene der Version 1.19 funktioniert beispielsweise mit Knoten der Versionen 1.19, 1.18 und 1.17.

Wenn Ihre Knoten außerhalb dieses unterstützten Zeitraums liegen, besteht das Risiko, dass kritische Kompatibilitätsprobleme auftreten. Diese Probleme sind oft API-bezogen. So kann es beispielsweise sein, dass für eine Arbeitslast auf einem älteren Knoten eine API-Version verwendet wird, die in der neueren Steuerungsebene eingestellt oder entfernt wurde. Diese Inkompatibilität kann auch zu schwerwiegenderen Fehlern führen, z. B. zu einem unterbrochenen Netzwerkpfad, der verhindert, dass sich Knoten im Cluster registrieren, wenn eine inkompatible Arbeitslast die Kommunikation unterbricht.

Das GKE-Team führt regelmäßig Upgrades der Cluster-Steuerungsebene in Ihrem Namen durch. Steuerebenen werden auf neuere stabile Versionen von Kubernetes aktualisiert. Damit Ihre Knoten mit der aktualisierten Steuerungsebene kompatibel bleiben, müssen sie ebenfalls auf dem neuesten Stand gehalten werden. Standardmäßig wird dieses Upgrade von GKE durchgeführt, da für die Knoten eines Clusters das automatische Upgrade aktiviert ist. Wir empfehlen, dies nicht zu deaktivieren. Wenn die automatischen Upgrades für die Knoten eines Clusters deaktiviert sind und Sie sie nicht manuell aktualisieren, wird Ihre Steuerungsebene nicht mehr mit Ihren Knoten kompatibel sein.

So prüfen Sie, ob die Versionen der Steuerungsebene und der Knoten inkompatibel sind:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters des zu beschreibenden Knotenpools.
  • PROJECT_ID: die Projekt-ID des Clusters.
  • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

Die Ausgabe sieht etwa so aus:

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

In diesem Beispiel sind die Version der Steuerungsebene und die Version des Knotenpools nicht kompatibel.

Aktualisieren Sie die Knotenpoolversion manuell auf eine Version, die mit der Steuerungsebene kompatibel ist, um dieses Problem zu beheben.

Wenn Sie befürchten, dass der Upgradeprozess zu Arbeitslasten führt, die auf den betroffenen Knoten ausgeführt werden, führen Sie die folgenden Schritte aus, um Ihre Arbeitslasten zu einem neuen Knotenpool zu migrieren:

  1. Erstellen Sie einen neuen Knotenpool mit einer kompatiblen Version.
  2. Cordon Knoten des bestehenden Knotenpools.
  3. Optional: Aktualisieren Sie die Arbeitslasten, die auf dem vorhandenen Knotenpool ausgeführt werden, um einen nodeSelector für das Label cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME hinzuzufügen. Ersetzen Sie NEW_NODE_POOL_NAME durch den Namen des neuen Knotenpools. So wird sichergestellt, dass GKE diese Arbeitslasten auf Knoten im neuen Knotenpool platziert.
  4. Leeren Sie den vorhandenen Knotenpool.
  5. Prüfen Sie, ob die Arbeitslasten im neuen Knotenpool ausgeführt werden. In diesem Fall können Sie den alten Knotenpool löschen. Wenn Sie Unterbrechungen bei der Arbeitslast bemerken, planen Sie die Arbeitslasten auf den vorhandenen Knoten neu, indem Sie die Knoten im vorhandenen Knotenpool entsperren und die neuen Knoten leeren.

Die CPU-Auslastung des Knotens ist höher als erwartet

Möglicherweise stoßen Sie auf ein Problem, bei dem einige Knoten mehr CPU verwenden, als von den ausgeführten Pods erwartet.

Dieses Problem kann auftreten, wenn Sie manuelle Upgrades verwenden und Ihre Cluster oder Knoten nicht auf eine unterstützte Version aktualisiert wurden. Lesen Sie die Versionshinweise, um sicherzustellen, dass die von Ihnen verwendeten Versionen verfügbar und unterstützt werden.

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: