Versionsregeln für Upgrades

Wenn Sie wissen, wie sich Ihre aktuelle Version und die Zielversion auf Ihr Clusterupgrade auswirken, können Sie die Versionsabweichung, die Upgradereihenfolge und die Betriebssystemanforderungen prüfen, bevor Sie beginnen.

Versionsspezifische Upgrade-Informationen

In der folgenden Tabelle finden Sie versionsspezifische Upgrade-Informationen. Unter der Tabelle finden Sie Details zu bestimmten Releases. Die Versionen sind von der neuesten zur ältesten sortiert. Suchen Sie die Version, auf die Sie ein Upgrade ausführen, um die spezifischen Details und Regeln für Ihren Cluster zu finden.

Version Zuerst upgraden Versionen der Steuerungsebene Versionen von Worker-Knotenpools Erweiterter Clusterstatus Werden Legacy-Funktionen unterstützt? Standard- und erforderliche Betriebssystem-Images Verhalten beim Knotenupgrade mit Kubeception Gebündelt: cert-manager
1.36 Administratorcluster 1.36, 1.35, 1.34 1.36, 1.35, 1.34 Erforderlich Keine ubuntu_cgv2, cos_cgv2 Nicht unterstützt Gebündelt
1.35 Administratorcluster 1.35, 1.34, 1.33 1.35, 1.34, 1.33 Erforderlich Keine ubuntu_cgv2, cos_cgv2 obligatorisch (cgroup v1 wird nicht mehr unterstützt) Nicht unterstützt Gebündelt
1.34 Administratorcluster 1.34, 1.33, 1.32 1.34, 1.33, 1.32 Obligatorisch (keine Deaktivierung; nicht erweiterte Kampagnen werden automatisch umgestellt) Keine ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos Nicht unterstützt Gebündelt
1.33 Administratorcluster 1.33, 1.32, 1.31 1.33, 1.32, 1.31 Standard (automatische Konvertierung) (Deaktivierung nur für 1.32 bis 1.33) Keine ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos Nicht unterstützt Gebündelt für erweiterte Cluster
1.32 Administratorcluster 1.32, 1.31, 1.30 1.32, 1.31, 1.30 GA (Upgrades werden unterstützt; separate Knotenupgrades und Überspringen von Knotenupgrades werden unterstützt) Keine ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos Nicht unterstützt (Migration zu Steuerungsebene V2 erforderlich) Gebündelt für erweiterte Cluster
1.31 Administratorcluster 1.31, 1.30, 1.29 1.31, 1.30, 1.29 Vorabversion (kein Upgrade auf 1.32; keine separaten oder übersprungenen Knotenupgrades) Ja (Seesaw, F5, Kubeception, Nicht-HA); Migration zu empfohlenen Funktionen dringend empfohlen; Dataplane V2 obligatorisch ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos Admin-Knoten werden mit dem Administratorcluster aktualisiert, Nutzer-CP-Knoten mit dem Nutzercluster. Nicht im Bundle
1.30 Nutzercluster 1,30 1.30, 1.29, 1.28 Nicht verfügbar Ja (Seesaw, F5, Kubeception, nicht HA); Migration zu empfohlenen Funktionen dringend empfohlen ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos CP- und Admin-Knoten, die während des Upgrades des Administratorclusters aktualisiert werden Nicht im Bundle
1.29 Nutzercluster 1.29, 1.30 1.29, 1.28, 1.16 Nicht verfügbar Ja (Seesaw, F5, Kubeception, Nicht-HA) ubuntu_cgv2 (Standard), cos_cgv2, ubuntu_containerd, cos CP- und Admin-Knoten, die während des Upgrades des Administratorclusters aktualisiert werden Nicht im Bundle
1.28 Nutzercluster 1.28, 1.29, 1.30 1.28, 1.16, 1.15 Nicht verfügbar Ja (Seesaw, F5, Kubeception, Nicht-HA) ubuntu_containerd (Standard), cos, ubuntu_cgv2, cos_cgv2 CP- und Admin-Knoten, die während des Upgrades des Administratorclusters aktualisiert werden Nicht im Bundle

Bei allen Versionen müssen Sie die Versionen der Load-Balancer-Knotenpools (Knotenpools mit enableLoadBalancer: true) gleichzeitig und auf dieselbe Version wie die Steuerungsebene des Nutzerclusters aktualisieren.

Upgrade-Informationen nach Release-Version

Suchen Sie den Abschnitt für die Version, auf die Sie ein Upgrade durchführen möchten, um die spezifischen Informationen zu erhalten, die Sie für das Upgrade auf diese Version benötigen.

Version 1.36

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.36 kann Nutzercluster der Versionen 1.36, 1.35 und 1.34 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.36, 1.35 oder 1.34.
  • Worker-Knotenpool-Versionen: 1.36, 1.35 oder 1.34.

Erweiterter Clusterstatus: Erweiterte Cluster sind obligatorisch.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Nein. Blockiert das Upgrade.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2. Der Standardwert für osImageType für neue Konfigurationen ist ubuntu_cgv2.

Kubeception-Knotenupgradeverhalten: Nicht unterstützt. Blockiert Upgrade.

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.36, 1.37 und 1.38.
  • Terraform: Unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Google Cloud Console: Wird für Nutzercluster-Upgrades unterstützt.
  • Google Cloud CLI: Wird für Nutzercluster-Upgrades unterstützt.

Zusätzliche Anforderungen:

  • Sie können Administratorcluster-Upgrades asynchron mit gkectl upgrade admin --async ausführen.

Version 1.35

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.35 kann Nutzercluster der Versionen 1.35, 1.34 und 1.33 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.35, 1.34 oder 1.33.
  • Versionen von Worker-Knotenpools: 1.35, 1.34 oder 1.33.

Erweiterter Clusterstatus: Erweiterte Cluster sind obligatorisch.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Nein. Blockiert das Upgrade.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2 obligatorisch (cgroup v1 wird nicht mehr unterstützt). Der Standardwert für osImageType für neue Konfigurationen ist ubuntu_cgv2. Sie müssen Cluster zu cgroup v2 migrieren, bevor Sie ein Upgrade durchführen.

Kubeception-Knotenupgradeverhalten: Nicht unterstützt. Blockiert Upgrade.

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.35, 1.36 und 1.37.
  • Terraform: Unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Wird für Nutzercluster-Upgrades unterstützt.
  • gcloud CLI: Wird für Nutzercluster-Upgrades unterstützt.

Zusätzliche Anforderungen:

  • Sie können Administratorcluster-Upgrades asynchron mit gkectl upgrade admin --async ausführen.

Version 1.34

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.34 kann Nutzercluster der Versionen 1.34, 1.33 und 1.32 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.34, 1.33 oder 1.32.

  • Versionen von Worker-Knotenpools: 1.34, 1.33 oder 1.32.

Erweiterter Clusterstatus: Erweiterte Cluster sind obligatorisch.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Nein. Blockiert das Upgrade.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

Kubeception-Knotenupgradeverhalten: Nicht unterstützt. Blockiert Upgrade.

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Erforderlich, um nicht erweiterte Cluster in erweiterte Cluster umzuwandeln (obligatorisch in 1.34; die Binärversion von gkectl muss genau mit der Ziel-Release-Version übereinstimmen). Unterstützte Versionen sind 1.34, 1.35 und 1.36.
  • Terraform: Unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für erweiterte Nutzercluster-Upgrades.
  • gcloud CLI: Unterstützt für erweiterte Nutzercluster-Upgrades.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.34 gelten die folgenden zusätzlichen Anforderungen:

  • Nicht erweiterte Cluster werden beim Upgrade auf 1.34 automatisch in erweiterte Cluster umgewandelt. Informationen zu den spezifischen Regeln für Upgrades von nicht erweiterten auf erweiterte Cluster finden Sie unter Cluster auf einen erweiterten Cluster aktualisieren oder upgraden.

  • Das gebündelte cert-manager ist obligatorisch und wurde auf Version 1.19 aktualisiert. Dadurch werden bereits vorhandene benutzerdefinierte cert-manager-Installationen überschrieben. Weitere Informationen zu Upgrades auf cert-manager mit Upgradelizenz finden Sie unter cert-manager mit Upgradelizenz verwenden.

  • Die Containerlaufzeit des Knotens wurde auf containerd 2.0 aktualisiert. Dies kann folgende Auswirkungen haben:

    • containerd 2.0 unterstützt keine Legacy-Docker-Image-Manifest-v2- oder Schema 1-Images. Achten Sie darauf, dass Arbeitslasten Container-Images mit Docker Schema 2 oder einem OCI-konformen Format abrufen, bevor Sie ein Upgrade auf 1.34 ausführen.
    • Die Konfiguration des Registry-Spiegels wird in containerd 2.0 in das hosts.toml-Format migriert. Wenn Sie benutzerdefinierte Spiegelkonfigurationen oder Registry-Endpunkte mit Air Gap direkt auf Ihren Knoten verwalten, prüfen Sie, ob Ihre Konfiguration mit hosts.toml übereinstimmt.
    • Wenn Sie benutzerdefinierte DaemonSets oder Skripts verwenden, die /etc/containerd/config.toml patchen, achten Sie darauf, dass sie keine verworfenen containerd v1-Konfigurationsoptionen verwenden, da dies zu containerd-Startfehlern mit containerd 2.0 führen kann.

  • Der Standardwert des Felds nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate wurde in Version 1.34.300 geändert. Wenn Sie in Versionen ab 1.34.300 sequenzielle Knotenpoolupgrades durchführen möchten, legen Sie nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 in der Konfigurationsdatei des Nutzerclusters fest:

    • In den Versionen 1.34.0 bis 1.34.200 ist nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate standardmäßig auf 1 festgelegt, wodurch jeweils ein Knotenpool nacheinander aktualisiert wird.
    • Ab Version 1.34.300 ist nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate standardmäßig auf 0 festgelegt, wodurch alle Knotenpools gleichzeitig aktualisiert werden.

    Weitere Informationen finden Sie unter Richtlinie für Knotenpool-Updates konfigurieren.

  • Bei den Preflight-Prüfungen für Upgrades werden alle PodDisruptionBudget-Konfigurationen (PDB) im gesamten Cluster aktiv validiert. Prüfen Sie vor dem Upgrade, ob Ihre Arbeitslasten zu restriktive PDBs haben (z. B. maxUnavailable: 0 oder minAvailable, die mit der Gesamtzahl der Replikate übereinstimmen), die das Node-Draining blockieren oder dazu führen, dass Preflight-Prüfungen fehlschlagen.

  • Wenn ein Upgrade unterbrochen wird, führen Sie ein direktes Upgrade auf Version 1.34.300-gke.59 oder höher durch. Diese Version verhindert, dass der Bootstrap-Cluster gelöscht wird, wenn Sie gkectl upgrade admin nach einem Fehler noch einmal ausführen müssen. Weitere Informationen finden Sie unter Durch erneutes Ausführen von gkectl upgrade admin wird der Bootstrap-Cluster gelöscht.

  • Sie können Administratorcluster-Upgrades asynchron mit gkectl upgrade admin --async für erweiterte Cluster ausführen, außer wenn Sie von einem nicht erweiterten zu einem erweiterten Cluster konvertieren.

Version 1.33

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.33 kann Nutzercluster der Versionen 1.33, 1.32 und 1.31 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.33, 1.32 oder 1.31.

  • Worker-Knotenpoolversionen: 1.33, 1.32 oder 1.31.

Erweiterter Clusterstatus: Erweiterte Cluster sind der Standardclustertyp und werden automatisch konvertiert. Deaktivierung zulässig. Weitere Informationen finden Sie unter Nicht erweiterte Cluster aktualisieren und verwalten. Wenn Sie enableAdvancedCluster auf false setzen, schlägt die Erstellung neuer Cluster fehl.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Nein. Blockiert das Upgrade.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

Kubeception-Knotenupgradeverhalten: Nicht unterstützt. Blockiert Upgrade.

Upgrade-Tools:

  • gkectl: Erforderlich, um nicht erweiterte Cluster in erweiterte Cluster zu konvertieren (die Binärversion von gkectl muss genau mit der Ziel-Release-Version übereinstimmen). Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.33, 1.34 und 1.35.
  • Terraform: Unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für erweiterte Nutzercluster-Upgrades.
  • gcloud CLI: Unterstützt für erweiterte Nutzercluster-Upgrades.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.33 gelten die folgenden zusätzlichen Anforderungen:

  • Bei Upgrades von 1.32 auf 1.33 werden nicht erweiterte Cluster standardmäßig automatisch in erweiterte Cluster umgewandelt. Sie können Cluster nicht erweitert lassen. Weitere Informationen dazu, wie Sie Cluster nicht erweitert halten, finden Sie unter Nicht erweiterte Cluster aktualisieren und verwalten.

  • Bei erweiterten Clustern wird cert-manager v1.18 automatisch installiert und gebündelt. Vorhandene benutzerdefinierte cert-manager-Installationen werden dabei überschrieben. Weitere Informationen zu Upgrades auf cert-manager mit Upgradelizenz finden Sie unter cert-manager mit Upgradelizenz verwenden.

  • Wenn Sie in diesem Release ein Upgrade auf erweiterte Cluster durchführen, muss die Binärversion von gkectl genau mit der Ziel-Release-Version übereinstimmen, wenn Sie von nicht erweiterten zu erweiterten Clustern konvertieren. Diese Anforderung gilt nur während des Upgrades auf einen erweiterten Cluster. Für alle anderen Upgrades Ihres erweiterten Clusters gelten die Standardregeln für Versionsabweichungen.

  • Wenn ein Upgrade unterbrochen wird, führen Sie ein direktes Upgrade auf Version 1.33.700-gke.71 oder höher durch. Diese Version verhindert, dass der Bootstrap-Cluster gelöscht wird, wenn Sie gkectl upgrade admin nach einem Fehler noch einmal ausführen müssen.

  • Sie können Administratorcluster-Upgrades asynchron mit gkectl upgrade admin --async für erweiterte Cluster und nicht erweiterte HA-Cluster ausführen, wenn auf allen Nutzerclustern Controlplane V2 ausgeführt wird. Sie können das Flag --async nicht verwenden, wenn Sie einen nicht erweiterten Cluster in einen erweiterten Cluster konvertieren.

Version 1.32

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.32 kann Nutzercluster der Versionen 1.32, 1.31 und 1.30 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.32, 1.31 oder 1.30.

  • Versionen von Worker-Knotenpools: 1.32, 1.31 oder 1.30.

Erweiterter Clusterstatus: Unterstützt.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Nein. Blockiert das Upgrade.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

Kubeception-Knotenupgradeverhalten: Nicht unterstützt. Blockiert Upgrade. Muss zu Steuerungsebene V2 migriert werden.

Upgrade-Tools:

  • gkectl: Erforderlich, um nicht erweiterte Cluster in erweiterte Cluster zu konvertieren (die Binärversion von gkectl muss genau mit der Ziel-Release-Version übereinstimmen). Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.32, 1.33 und 1.34.
  • Terraform: Unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für erweiterte Nutzercluster-Upgrades.
  • gcloud CLI: Unterstützt für erweiterte Nutzercluster-Upgrades.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.32 gelten die folgenden zusätzlichen Anforderungen:

  • Dies ist die erste Version, die ein optionales Upgrade auf einen vollständig unterstützten erweiterten GA-Cluster ermöglicht. Sie können zwischen diesen Optionen auswählen:

    • Führen Sie ein Upgrade auf einen nicht erweiterten Cluster durch und verwalten Sie den nicht erweiterten Cluster. Wenn Sie diese Option auswählen, können Sie ab dieser Version Folgendes tun:

      • Aktualisieren Sie die Steuerungsebene des Nutzerclusters und die Worker-Knotenpools separat. Die Worker-Knotenpools können bis zu zwei Nebenversionen hinter der Steuerungsebene liegen.
      • Führen Sie das Upgrade für Administrator- und Nutzercluster asynchron aus.

    • Führen Sie ein Upgrade auf einen nicht erweiterten Cluster durch und konvertieren Sie den nicht erweiterten Cluster dann in einen erweiterten Cluster. Wenn Sie diese Option auswählen, können Sie ab dieser Version Folgendes tun:

      • Aktualisieren Sie die Steuerungsebene des Nutzerclusters und die Worker-Knotenpools separat, wenn Sie ein Upgrade des nicht erweiterten Clusters durchführen, aber nicht, wenn Sie ihn in einen erweiterten Cluster konvertieren. Die Worker-Knotenpools können bis zu zwei Nebenversionen hinter der Steuerungsebene liegen.
      • Führen Sie das Upgrade für Administrator- und Nutzercluster asynchron aus, wenn Sie ein Upgrade des nicht erweiterten Clusters durchführen.
      • Wenn Sie zum erweiterten Cluster konvertieren, führen Sie ein Upgrade auf die Release-Version 1.32.1000-gke.57 oder höher durch, da diese eine Korrektur für ein bekanntes Problem enthält, das das Löschen des Bootstrap-Clusters verhindert.

    • Führen Sie ein direktes Upgrade auf einen erweiterten Cluster durch. Wenn Sie diese Option auswählen, gilt ab dieser Version Folgendes:

      • Sie müssen die Steuerungsebene und alle Knotenpools zusammen aktualisieren.
      • Sie können das Upgrade für Nutzercluster asynchron ausführen, aber nicht für Administratorcluster.
      • Führen Sie ein Upgrade auf die Release-Version 1.32.1000-gke.57 oder höher durch, da diese eine Fehlerbehebung für ein bekanntes Problem enthält, das das Löschen des Bootstrap-Clusters verhindert.

  • Die folgenden Legacy-Funktionen werden ab dieser Version nicht mehr unterstützt. Weitere Informationen finden Sie unter Legacy-Funktionen:

    • Dataplane V1 (Calico). Führen Sie ein Upgrade auf Dataplane V2 durch, bevor Sie ein Upgrade auf 1.32 durchführen.
    • Seesaw. Führen Sie ein Upgrade auf einen alternativen Load Balancer durch, bevor Sie ein Upgrade auf 1.32 durchführen.
    • Integrierte F5 BIG-IP. Führen Sie ein Upgrade auf einen alternativen Load Balancer durch, bevor Sie ein Upgrade auf 1.32 durchführen.
    • Kubeception. Führen Sie ein Upgrade auf einen Nicht-Kubeception-Cluster durch, bevor Sie ein Upgrade auf 1.32 durchführen.
    • Nicht-HA-Administratorcluster. Führen Sie ein Upgrade auf einen HA-Administratorcluster durch, bevor Sie ein Upgrade auf 1.32 durchführen.

  • Die Binärversion von gkectl muss genau mit der Ziel-Release-Version übereinstimmen, wenn Sie von nicht erweiterten zu erweiterten Clustern konvertieren. Diese Anforderung gilt nur während des Upgrades auf einen erweiterten Cluster. Für alle anderen Upgrades Ihres erweiterten Clusters gelten die Standardregeln für Versionsabweichungen.

  • Wenn ein Upgrade unterbrochen wird, führen Sie ein Upgrade direkt auf Version 1.32.1000-gke.57 oder höher durch. Diese Version verhindert, dass der Bootstrap-Cluster gelöscht wird, wenn Sie gkectl upgrade admin nach einem Fehler noch einmal ausführen müssen.

  • Ab Version 1.32 können Sie Upgrades von Administratorclustern asynchron mit gkectl upgrade admin --async für erweiterte Cluster und nicht erweiterte HA-Cluster ausführen, wenn alle Nutzercluster Controlplane V2 ausführen. Sie können das Flag --async nicht verwenden, wenn Sie einen nicht erweiterten Cluster in einen erweiterten Cluster konvertieren.

Version 1.31

Zuerst aktualisieren: Administratorcluster

Regeln für Versionsabweichungen:

  • Ein Administratorcluster der Version 1.31 kann Nutzercluster der Versionen 1.31, 1.30 und 1.29 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.31, 1.30 oder 1.29.
  • Versionen von Worker-Knotenpools: 1.31, 1.30 oder 1.29. (Wird auf erweiterten 1.31-Clustern nicht unterstützt).
  • Wenn Sie ein Upgrade von 1.29/1.30 auf 1.31 durchführen möchten, müssen Sie alle Cluster auf Version 1.30 aktualisieren, bevor Sie den Administratorcluster auf 1.31 aktualisieren.

Erweiterter Clusterstatus: Nur Vorschau. Ein Upgrade auf höhere Versionen ist nicht möglich.

Knotenupgrades überspringen: Unterstützt.

Unterstützte Legacy-Funktionen: Dataplane V2 ist obligatorisch; Kubeception, Seesaw und F5 werden weiterhin unterstützt.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

Kubeception-Knotenupgradeverhalten: Admin-Knoten werden mit dem Admin-Cluster aktualisiert; Nutzer-CP-Knoten werden mit dem Nutzercluster aktualisiert.

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster, nicht erweiterte Cluster und erweiterte Cluster (Vorabversion für diesen Release). Unterstützte Versionen sind 1.31, 1.32 und 1.33.
  • Terraform: Wird für registrierte Nutzercluster unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für Upgrades registrierter Nutzercluster.
  • gcloud CLI: Wird für Upgrades registrierter Nutzercluster unterstützt.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.31 gelten die folgenden zusätzlichen Anforderungen:

  • In dieser Version wurden erweiterte Cluster im Vorschaumodus eingeführt. In dieser Version können Sie keine nicht erweiterten Cluster zu erweiterten Clustern migrieren. Sie können neue Cluster als erweiterte Cluster erstellen, aber diese erweiterten Cluster der Vorabversion nicht auf eine höhere Version aktualisieren. Wir raten davon ab, in dieser Version erweiterte Cluster zu erstellen. Weitere Informationen zu den Phasen der Produkteinführung, z. B. zur Vorabversion, finden Sie unter Phasen der Produkteinführung.

  • In Version 1.31 und höher wurde die Architektur von Upgrades auf ein Modell umgestellt, bei dem der Administratorcluster jetzt höher oder gleich seinen Nutzerclustern sein muss. Bisher konnten Nutzercluster bis zu zwei Nebenversionen vor dem Administratorcluster liegen.

  • Sie müssen den Administratorcluster aktualisieren, bevor Sie die vom Administratorcluster verwalteten Nutzercluster aktualisieren. Administratorcluster können Nutzercluster mit derselben Nebenversion oder bis zu zwei Nebenversionen niedriger verwalten. Ein Administratorcluster der Version 1.31 kann beispielsweise Nutzercluster der Versionen 1.31, 1.30 und 1.29 verwalten.

  • Wenn Sie ein Upgrade von 1.29 auf 1.31 durchführen möchten, müssen Sie das 1.30-Bundle als Zwischenschritt bereitstellen. Sie müssen sowohl das Bundle 1.30 als auch das Bundle 1.31 auf die Administrator-Workstation herunterladen, um ein Upgrade auf 1.31 durchzuführen. So führen Sie ein Upgrade von Version 1.29 auf Version 1.31 durch:

    1. Aktualisieren Sie nur die Steuerungsebene des Nutzerclusters von 1.29 auf 1.30 (Worker-Knotenpools bleiben bei 1.29).
    2. Aktualisieren Sie den Administratorcluster von 1.29 auf 1.30.
    3. Aktualisieren Sie den Administratorcluster von 1.30 auf die Zielversion 1.31.
    4. Führen Sie ein Upgrade der Steuerungsebene und der Worker-Knotenpools des Nutzerclusters auf Version 1.31 durch.

  • Wenn Sie Kubeception verwenden, werden die Knoten des Administratorclusters während des Upgrades des Administratorclusters und die Knoten der Steuerungsebene des Nutzerclusters während des Upgrades des Nutzerclusters aktualisiert.

  • Wenn Sie ein Upgrade auf 1.31 ausführen möchten, müssen Sie Dataplane V2 aktivieren. Um Konflikte mit Netzwerkrichtlinien und Traffic-Ausfälle während der CNI-Migration zu vermeiden, müssen Sie alle NetworkPolicy-Objekte manuell speichern und dann löschen und nach dem Upgrade wiederherstellen. So stellen Sie auf Dataplane V2 um:

    1. Exportieren und speichern Sie alle benutzerdefinierten Netzwerkrichtlinien:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml

      Ersetzen Sie Folgendes:

      • USER_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für den Nutzercluster
      • POLICY_NAME: der Name des NetworkPolicy-Objekts
      • NAMESPACE: der Namespace des NetworkPolicy-Objekts

    2. Löschen Sie die Netzwerkrichtlinien aus dem Cluster:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE

    3. Legen Sie enableDataplaneV2: true in der Konfigurationsdatei des Nutzerclusters fest und führen Sie das Upgrade auf 1.31 durch.

    4. Wenden Sie die gespeicherten Richtlinien nach Abschluss des Upgrades auf Version 1.31 an, damit Cilium sie sauber in eBPF (extended Berkeley Packet Filter) kompiliert:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml

  • Wenn Sie HA-Administratorcluster haben und auf allen Nutzerclustern Controlplane V2 ausgeführt wird, können Sie das Upgrade asynchron mit dem Befehl gkectl upgrade admin --async ausführen.

  • Dataplane V2 ist für alle Nutzercluster erforderlich. Bevor Sie ein Upgrade eines Nutzerclusters auf Version 1.31 durchführen, folgen Sie der Anleitung unter Dataplane V2 aktivieren.

  • Legacy-Funktionen werden in 1.32 nicht unterstützt. Sie können sie in 1.30 und 1.31 ersetzen, um Probleme beim Upgrade auf 1.32 zu vermeiden.

Version 1.30

Zuerst aktualisieren: Nutzercluster

Regeln für Versionsabweichungen:

  • Nutzercluster der Version 1.30 können von einem Administratorcluster der Version 1.30, 1.29 oder 1.28 verwaltet werden.
  • Ein Administratorcluster mit Version 1.30 kann nur Nutzercluster mit Version 1.30 verwalten. Alle Nutzercluster und der Administratorcluster müssen Version 1.30 erreichen, bevor Sie den Administratorcluster auf Version 1.31 aktualisieren können. Außerdem müssen Sie den Administratorcluster auf Version 1.31 aktualisieren, bevor ein Nutzercluster auf Version 1.31 aktualisiert werden kann.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.30.
  • Worker-Knotenpool-Versionen: 1.30, 1.29 oder 1.28.

Erweiterter Clusterstatus: Nicht verfügbar.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Unterstützt. Die Migration zu empfohlenen Funktionen wird dringend empfohlen.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

  • Kubeception-Knotenupgrade-Verhalten:** Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.30, 1.31 und 1.32.
  • Terraform: Wird für registrierte Nutzercluster unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für Upgrades registrierter Nutzercluster.
  • gcloud CLI: Wird für Upgrades registrierter Nutzercluster unterstützt.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.30 gelten die folgenden zusätzlichen Anforderungen:

  • Für diese Version und alle vorherigen Versionen müssen Sie alle Nutzercluster migrieren, bevor Sie ein Upgrade des verwaltenden Administratorclusters durchführen. Der Administratorcluster muss dieselbe oder eine niedrigere Nebenversion als alle verwalteten Nutzercluster haben.

  • Wenn Sie Kubeception verwenden, geschieht während eines Upgrades Folgendes:

    1. Führen Sie das Nutzercluster-Upgrade durch. Da sich die Nutzersteuerungsebene im Administratorcluster befindet, werden durch Ausführen von gkectl upgrade cluster nur die Worker-Knotenpools aktualisiert.
    2. Administratorcluster aktualisieren. Beim Upgrade des Administratorclusters werden die Admin-Knoten aktualisiert und gleichzeitig alle Steuerungsebenen des Nutzerclusters automatisch aktualisiert.

  • Wenn Sie Controlplane V2 verwenden, geschieht während des Upgrades Folgendes:

    1. Führen Sie das Nutzercluster-Upgrade durch. Dadurch werden die Steuerungsebene und die Worker-Knotenpools aktualisiert.
    2. Administratorcluster aktualisieren. Dadurch werden die Admin-Knoten aktualisiert.

  • Wenn Sie einen neuen Nutzercluster erstellen, müssen Sie das Feld enableControlplaneV2 auf true setzen. Dies ist ab diesem Release der Standardwert. Wenn Sie das Feld enableControlplaneV2 auf false setzen, lehnt gkectl die Datei ab und erstellt den Cluster nicht.

  • Wenn Sie HA-Administratorcluster haben und auf allen Nutzerclustern Controlplane V2 ausgeführt wird, können Sie das Upgrade asynchron mit dem Befehl gkectl upgrade admin --async ausführen.

  • Legacy-Funktionen werden in 1.32 nicht unterstützt. Sie können sie in 1.30 und 1.31 ersetzen, um Probleme beim Upgrade auf 1.32 zu vermeiden.

Version 1.29

Zuerst aktualisieren: Nutzercluster

Regeln für Versionsabweichungen:

  • Nutzercluster der Version 1.29 können von einem Administratorcluster der Version 1.29, 1.28 oder 1.16 verwaltet werden.
  • Ein Administratorcluster der Version 1.29 kann Nutzercluster der Versionen 1.29 und 1.30 verwalten. Ein Administratorcluster der Version 1.29 kann keine Nutzercluster der Version 1.31 verwalten, da alle Cluster zuerst die Version 1.30 erreichen müssen und der Administratorcluster auf Version 1.31 aktualisiert werden muss, bevor ein Nutzercluster auf Version 1.31 aktualisiert werden kann.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.29 oder 1.30, also bis zu eine Nebenversion höher.
  • Versionen von Worker-Knotenpools: 1.29, 1.28 oder 1.16.

Erweiterter Clusterstatus: Nicht verfügbar.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Unterstützt.

Standard- und erforderliche Betriebssystem-Images: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. Der Standardwert für osImageType ist ubuntu_cgv2.

Kubeception-Knotenupgrade-Verhalten: Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.29, 1.30 und 1.31.
  • Terraform: Wird für registrierte Nutzercluster unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für Upgrades registrierter Nutzercluster.
  • gcloud CLI: Wird für Upgrades registrierter Nutzercluster unterstützt.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.29 gelten die folgenden zusätzlichen Anforderungen:

  • Worker-Knoten können bis zu zwei Nebenversionen hinter der Steuerungsebene (n+2) liegen.
  • Sie können eine Nebenversion überspringen, wenn Sie Worker-Knotenpools aktualisieren. Sie können beispielsweise einen Worker-Knotenpool von 1.28 auf 1.30 aktualisieren.
  • Preflight-Prüfungen werden als Pods im Administratorcluster oder in einem temporären Bootstrap-Kind-Cluster und nicht auf der Administrator-Workstation ausgeführt.
  • Ab dieser Version können Sie eine Preflight-Prüfung ausführen, ohne den Cluster mit gkectl upgrade cluster --dry-run zu aktualisieren.
  • Wenn Sie HA-Administratorcluster haben und auf allen Nutzerclustern Controlplane V2 ausgeführt wird, können Sie das Upgrade asynchron mit dem Befehl gkectl upgrade admin --async ausführen.

Version 1.28

Zuerst aktualisieren: Nutzercluster

Regeln für Versionsabweichungen:

  • Nutzercluster der Version 1.28 können von einem Administratorcluster der Version 1.28, 1.16 oder 1.15 verwaltet werden.
  • Ein Administratorcluster der Version 1.28 kann Nutzercluster der Versionen 1.28, 1.29 und 1.30 verwalten.
  • Versionen der Steuerungsebene des Nutzerclusters: 1.28, 1.29 oder 1.30, also bis zu zwei Nebenversionen höher.
  • Worker-Knotenpool-Versionen: 1.28, 1.16 oder 1.15, also bis zu zwei Nebenversionen niedriger.

Erweiterter Clusterstatus: Nicht verfügbar.

Knotenupgrades überspringen: Unterstützt.

Legacy-Funktionen unterstützt: Unterstützt.

Standard- und erforderliche Betriebssystem-Images: ubuntu_containerd, cos, ubuntu_cgv2, cos_cgv2. Der Standardwert für osImageType ist ubuntu_containerd.

Kubeception-Knotenupgrade-Verhalten: Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters

Upgrade-Tools:

  • gkectl: Erforderlich für Administratorcluster. Unterstützte Versionen sind 1.28, 1.29 und 1.30.
  • Terraform: Wird für registrierte Nutzercluster unterstützt, wenn Sie den Nutzercluster mit Terraform erstellt haben.
  • Console: Unterstützt für Upgrades registrierter Nutzercluster.
  • gcloud CLI: Wird für Upgrades registrierter Nutzercluster unterstützt.

Zusätzliche Anforderungen:

Für Upgrades auf Version 1.28 gelten die folgenden zusätzlichen Anforderungen:

  • Sie müssen kubernetesmetadata.googleapis.com aktivieren und dem Logging-Monitoring-Dienstkonto roles/kubernetesmetadata.publisher gewähren. Andernfalls können Preflight-Prüfungen fehlschlagen oder es werden möglicherweise 403 PERMISSION_DENIED-Fehler angezeigt. Aktivieren Sie die API und weisen Sie dem vorhandenen Dienstkonto für das Logging-Monitoring die Rolle zu:

    gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Die ID des Flotten-Hostprojekts, zu dem der Nutzercluster gehört.
    • LOGGING_SA: die E-Mail-Adresse Ihres Logging-Monitoring-Dienstkontos.

  • Obwohl es technisch möglich ist, Versionen während eines Knotenpool-Upgrades zu überspringen, wurde diese Funktion als Funktion in der Vorabversion eingeführt und wird für diese Version nicht empfohlen. Weitere Informationen zu den Phasen der Produkteinführung, z. B. zur Vorabversion, finden Sie unter Phasen der Produkteinführung.

  • Knotenpools mit einem gebündelten Load Balancer müssen genau mit der Clusterversion übereinstimmen.

  • Sie können mehrere Knoten gleichzeitig aktualisieren, indem Sie das Feld nodePools[i].updateStrategy.rollingUpdate.maxSurge festlegen. Ihr vSphere-Cluster muss über genügend CPU, RAM und verfügbare IP-Adressen verfügen, um die zusätzlichen Surge-VMs während des Upgrades aufzunehmen:

    • Legen Sie maxSurge: 1 (Standard) fest, um jeweils einen Knoten zu aktualisieren (per Drain beenden, ersetzen, prüfen und dann wiederholen).
    • Legen Sie maxSurge: N (wobei N > 1) fest, um bis zu N Worker-Knoten gleichzeitig bereitzustellen und zu leeren (z. B. aktualisiert maxSurge: 3 3 Worker-Knoten gleichzeitig).

  • Sie benötigen mindestens 100 GB freien Speicherplatz auf Ihrer Administrator-Workstation, um ein Upgrade der Administrator-Workstation durchzuführen.

  • Die gkectl-Version, die Sie für das Upgrade verwenden, kann bis zu zwei Nebenversionen höher sein als der aktuelle Cluster. Sie können keine niedrigere Nebenversion verwenden.

Versionen vor 1.28

Für Upgrades auf Releases vor Version 1.28 gelten die folgenden zusätzlichen Anforderungen. Zwischen 1.16 und 1.28 gab es keine Release-Versionen:

Version 1.16:

  • Die Versionsabweichung zwischen Administrator- und Nutzerclustern sowie zwischen Steuerungsebene und Knotenpools darf nur eine Nebenversion betragen. Ein Administratorcluster der Version 1.15 kann beispielsweise nur Nutzercluster der Versionen 1.15 oder 1.16 verwalten. Eine auf Version 1.16 aktualisierte Nutzercluster-Steuerungsebene kann Worker-Knotenpools mit Version 1.15 oder 1.16 verwalten. Ein Pool mit Version 1.14 muss auf 1.15 aktualisiert werden, bevor die Steuerungsebene auf Version 1.16 verschoben werden kann. Weitere Informationen zu Versionsabweichungen finden Sie unter Regeln für Versionsabweichungen.
  • Cluster werden automatisch in der GKE On-Prem API registriert, wenn sie erstellt oder auf Version 1.16 aktualisiert werden. Mit dieser Änderung können Sie Nutzercluster über die Console, die gcloud CLI und Terraform ansehen, überwachen und aktualisieren, anstatt nur über die Shell der Administrator-Workstation.

Version 1.14:

  • Sie können zuerst nur die Steuerungsebene des Nutzerclusters aktualisieren, damit Sie nicht alle Worker-Knotenpools gleichzeitig leeren und aktualisieren müssen.
  • Während des Upgrades werden die vorhandenen kubeconfig-Dateien für Administrator- und Nutzercluster auf der Workstation automatisch geprüft und aktualisiert. Die Anmeldedaten werden automatisch erneuert.

Version 1.13:

  • Vor dieser Version konnten Sie einen Offline-Administratorcluster haben. In dieser Version müssen Sie Ihren Administratorcluster bei Google Cloudregistrieren. Informationen zum Registrieren eines Clusters finden Sie unter Vorhandenen Cluster registrieren.
  • Wenn Sie ein Upgrade eines Clusters auf Google Distributed Cloud (nur Software) für VMware Version 1.13 oder höher durchführen möchten, müssen Sie zuerst alle Nutzercluster-Knotenpools, die noch Docker Engine verwenden, auf containerd aktualisieren.

Gebündeltes cert-manager verwenden

Sie müssen das gebündelte cert-manager verwenden, das automatisch auf erweiterten Clustern installiert wird. Wenn Sie von einem nicht erweiterten Cluster zu einem erweiterten Cluster migrieren, überschreibt die integrierte cert-manager automatisch alle vom Kunden installierten Versionen von cert-manager. Achten Sie darauf, dass Sie keine kritischen benutzerdefinierten Konfigurationen oder Funktionen auf Ihre vorhandenen cert-manager angewendet haben, bevor Sie ein Update oder Upgrade auf erweiterte Cluster durchführen.

So prüfen Sie, ob Sie kritische benutzerdefinierte Konfigurationen oder Features auf Ihre cert-manager angewendet haben:

  • Tools für die kontinuierliche Bereitstellung aussetzen Wenn Sie cert-manager mit GitOps-Tools wie Config Sync, ArgoCD oder Flux verwalten, sollten Sie die Synchronisierung vor dem Upgrade aussetzen oder cert-manager-Manifeste aus Ihrem Repository entfernen. Wenn ein GitOps-Controller versucht, cert-manager auf eine ältere Version oder ein benutzerdefiniertes Manifest zurückzusetzen, während das Clusterupgrade ausgeführt wird, wird eine Abgleichschleife erstellt, die das Clusterupgrade blockieren kann.
  • Deinstallieren oder löschen Sie cert-manager-Pods, -Namespaces oder -CRDs vor dem Upgrade nicht manuell. gkectl verwaltet diese Upgrades direkt.
  • Wenn Sie die cert-manager-Bereitstellungs-Flags, Knotenauswahl oder Pod-Ressourcenlimits geändert haben, machen Sie diese Änderungen rückgängig. Erweiterte Cluster unterstützen keine benutzerdefinierten Binärargumente oder Überschreibungen auf Bereitstellungsebene für cert-manager.
  • Wenn Sie spezialisierte externe Aussteller, private ACME-DNS-01-Webhook-Plug-ins oder benutzerdefinierte Webhooks verwenden, prüfen Sie, ob Ihre Drittanbieter-Plug-ins mit der gebündelten cert-manager-Version für das Release kompatibel sind, auf das Sie ein Upgrade ausführen.

Weitere Informationen finden Sie unter Upgrade auf cert-manager im Paket mit erweiterten Clustern.

In der folgenden Tabelle sind die Release-Versionen aufgeführt, für die gebündelte cert-manager erforderlich sind:

Version Status für neue Cluster Status für vorhandene Clusterupgrades Gebündeltes cert-manager erforderlich?
1.34+ Erforderlich Obligatorische Konvertierung (v1.19 gebündelt) Für alle Kunden erforderlich. Nicht erweiterte Cluster können nicht mehr vorhanden sein.
1.33 Standard für alle neuen Cluster Wird standardmäßig automatisch in erweiterte Cluster konvertiert (v1.18 im Paket enthalten) Erforderlich für fast alle Cluster, sofern nicht explizit mit enableAdvancedCluster: false deaktiviert (nur 1.32 → 1.33).
1.32 (GA) Standardmäßig aktiviert Optionale Konvertierung in erweiterte Cluster Erforderlich, wenn erweiterte Cluster aktiviert sind.
1.31 (Vorabversion) Optional (enableAdvancedCluster: true) Nicht unterstützt Erforderlich, wenn erweiterte Cluster aktiviert sind.

Informationen dazu, welche cert-manager-Version in den einzelnen unterstützten Releases enthalten ist, finden Sie unter Gebündelte cert-manager-Versionen.

Steuerungsebene v2

Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt. Bei Controlplane V2 werden die Knoten der Steuerungsebene des Nutzerclusters während des Upgrades des Nutzerclusters aktualisiert. Die Knoten der Steuerungsebene des Administratorclusters werden während des Upgrades des Administratorclusters aktualisiert.

Legacy-Funktionen

In der folgenden Tabelle sind Legacy-Funktionen aufgeführt, die in Version 1.32 und höher blockiert sind. Wenn Sie diese Funktionen verwenden, müssen Sie zu den empfohlenen Alternativen migrieren, bevor Sie ein Upgrade auf Version 1.32 oder höher durchführen können.

| Legacy-Funktion (in 1.32 blockiert) | Ersetzen durch (empfohlen) | Link zur Migrationsanleitung | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium / eBPF) | Zu Dataplane V2 migrieren| | Kubeception | Controlplane V2 | Zu Controlplane V2 migrieren | | Nicht-HA-Administratorcluster (1 Replikat) | HA-Administratorcluster (3 Replikate) | Zu HA-Administratorcluster migrieren | | Seesaw-Load-Balancer | MetalLB oder ManualLB | Zu MetalLB migrieren oder Load-Balancer-Typ migrieren| | Integrierte F5 BIG-IP (loadBalancer.kind: „F5BigIP“) | ManualLB (gepaart mit F5 Big-IP Controller oder CCGI) | Zu ManualLB migrieren |

Weitere Informationen zur Migration von Legacy-Funktionen zu empfohlenen Funktionen finden Sie unter Clustermigration zu empfohlenen Funktionen planen.

Kubeception-Migration und Versionsverhalten

Kubeception ist eine Legacy-Funktion, die zu Controlplane V2 migriert werden muss, bevor Sie ein Upgrade auf Version 1.32 oder höher durchführen können.

Upgrades verhalten sich bei Clustern mit Kubeception je nach Version unterschiedlich:

  • Für 1.28: Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters
  • Für 1.29: Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters

  • Für 1.30: Upgrade der Steuerungsebene und der Admin-Knoten während des Upgrades des Administratorclusters. Wenn Sie Kubeception verwenden, geschieht während eines Upgrades Folgendes:

    1. Führen Sie das Nutzercluster-Upgrade durch. Da sich die Nutzersteuerungsebene im Administratorcluster befindet, werden durch Ausführen von gkectl upgrade cluster nur die Worker-Knotenpools aktualisiert.
    2. Administratorcluster aktualisieren. Beim Upgrade des Administratorclusters werden die Admin-Knoten aktualisiert und gleichzeitig alle Steuerungsebenen des Nutzerclusters automatisch aktualisiert.

  • Für 1.31: Admin-Knoten werden mit dem Administratorcluster aktualisiert; Knoten der Nutzersteuerungsebene werden mit dem Nutzercluster aktualisiert.

  • Ab Version 1.32: Kubeception wird nicht unterstützt. Sie müssen zu Controlplane V2 migrieren, bevor Sie ein Upgrade auf Version 1.32 oder höher durchführen können.

    Weitere Informationen zur Migration von Kubeception zu Controlplane V2 finden Sie unter Clustermigration zu empfohlenen Funktionen planen.

Versionsabweichung im Vergleich zum Überspringen einer Version während des Upgrades

Die Versionsabweichung ist der zulässige Unterschied zwischen den Nebenversionen eines Administratorclusters und seiner verwalteten Nutzercluster oder der Unterschied zwischen den Nebenversionen der Steuerungsebene eines Nutzerclusters und den Knotenpools im Nutzercluster.

Die Versionsabweichung unterscheidet sich vom Überspringen einer Nebenversion beim Upgrade.

Sie können eine Nebenversion nur überspringen, wenn Sie Worker-Knotenpools aktualisieren, nachdem Sie die Steuerungsebene aktualisiert haben. Dies gilt für Advanced- und Nicht-Advanced-Cluster, mit Ausnahme von Advanced-Clustern mit Version 1.31 und Versionen vor 1.28. Wenn ein Worker-Knotenpool beispielsweise Version 1.29 hat, aktualisieren Sie die Steuerungsebene des Nutzerclusters auf 1.30 und dann auf 1.31. Nachdem die Steuerungsebene auf Version 1.31 aktualisiert wurde, aktualisieren Sie den Worker-Knotenpool direkt von Version 1.29 auf Version 1.31, ohne ein Upgrade auf Version 1.30 durchzuführen. Weitere Informationen finden Sie unter Version beim Upgrade von Knotenpools überspringen.

Wenn Sie ein Upgrade auf eine höhere Nebenversion als die nächste sequenzielle Nebenversion durchführen möchten, führen Sie zuerst ein Upgrade auf die nächste Nebenversion und dann auf die höhere Nebenversion durch. Beim Upgrade von Steuerungsebenen von Administrator- und Nutzerclustern können Sie keine Nebenversion überspringen. Wenn Sie beispielsweise ein Upgrade von Version 1.34.x auf Version 1.36.x durchführen möchten, ist ein direktes Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.34.x auf 1.35.x und dann ein Upgrade auf 1.36.x ausführen.

Die Steuerungsebene eines Nutzerclusters kann bis zu zwei Nebenversionen höher sein als die Worker-Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.36 hat, können die Worker-Knotenpools im Cluster die Version 1.34, 1.35 oder 1.36 haben.

Welche Versionsabweichungen sind zulässig?

Ein Administratorcluster kann Nutzercluster verwalten, die bis zu zwei Nebenversionen niedriger sind. Wenn ein Administratorcluster beispielsweise Version 1.31 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.29, 1.30 oder 1.31 haben.

Vor Version 1.31 gelten die folgenden Regeln für die Versionsabweichung:

  • In den Versionen 1.28 bis 1.30 können Nutzercluster bis zu zwei Nebenversionen höher sein als ihr Administratorcluster. Wenn ein Administratorcluster beispielsweise Version 1.15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.15, 1.16 oder 1.28 haben. Sie können einen Nutzercluster der Version 1.28 erst auf Version 1.29 aktualisieren, wenn der Administratorcluster mindestens auf Version 1.16 aktualisiert wurde. Da sich in Version 1.31 die Upgradereihenfolge ändert und zuerst der Administratorcluster aktualisiert werden muss, kann ein Administratorcluster der Version 1.29 oder 1.30 keine Nutzercluster der Version 1.31 oder 1.32 verwalten. Alle Nutzercluster und der Administratorcluster müssen Version 1.30 erreichen, bevor Sie den Administratorcluster auf Version 1.31 aktualisieren können.
  • In Version 1.16 und niedriger können Nutzercluster nur eine Nebenversion höher sein als der Administratorcluster. Wenn ein Administratorcluster beispielsweise Version 1.15 hat, können die von diesem Administratorcluster verwalteten Nutzercluster Version 1.15 oder 1.16 haben.

Muss ich alle Nutzercluster auf einmal aktualisieren?

Wenn Sie ein Upgrade für Nutzercluster durchführen, können Sie eine der folgenden Optionen auswählen:

  • Aktualisieren Sie den gesamten Nutzercluster mit der Steuerungsebene und allen Knotenpools im Cluster gleichzeitig.
  • Aktualisieren Sie die Steuerungsebene des Nutzerclusters und belassen Sie die Knotenpools bei der aktuellen Version.
  • Führen Sie ein Upgrade der Steuerungsebene des Nutzerclusters und selektiv ein Upgrade der Knotenpools durch.

Welchen Ansatz Sie wählen, hängt von mehreren Faktoren ab, unter anderem:

  • Umgebung (Produktion oder Nicht-Produktion), in der sich der Cluster befindet
  • Länge des Wartungsfensters
  • Version des Nutzerclusters

In einer Entwicklungsumgebung ist es wahrscheinlich sinnvoll, sowohl die Steuerungsebene des Nutzerclusters als auch alle Knotenpools zu aktualisieren. In einer Produktionsumgebung mit einem kurzen Wartungsfenster sollten Sie jedoch nur die Steuerungsebene aktualisieren, da dies weniger Zeit in Anspruch nimmt und das Upgrade der Steuerungsebene die Arbeitslasten der Nutzer nicht beeinträchtigen sollte.

Load-Balancer-Knotenpools (Knotenpools mit enableLoadBalancer: true) müssen für jede Version dieselbe Version wie der Cluster haben.

Versionsregeln für gkectl

Die Version von gkectl, die Sie für das Upgrade verwenden können, hängt von der Zielclusterversion ab, also der Version des Clusters, auf die Sie ein Upgrade ausführen. In der Regel verwenden Sie dieselbe Version von gkectl wie die Zielversion des Clusters. Während des Upgrades werden die folgenden Regeln erzwungen:

  • Die gkectl-Version muss gleich oder höher als die Ziel-Cluster-Nebenversion sein. Wenn Sie beispielsweise ein Upgrade eines Clusters der Version 1.29 auf Version 1.30 durchführen, müssen Sie gkectl 1.30 oder höher verwenden. Patchversionen spielen keine Rolle.

  • Die gkectl-Version kann bis zu zwei Nebenversionen höher sein als die aktuelle Clusterversion. Wenn Sie beispielsweise einen 1.28-Cluster auf 1.29 aktualisieren möchten, verwenden Sie die gkectl-Version 1.29 oder 1.30, aber nicht die Version 1.31, da diese drei Nebenversionen höher als die Clusterversion ist.

Die Binärversion von gkectl muss genau mit der Ziel-Release-Version übereinstimmen, wenn Sie von nicht erweiterten zu erweiterten Clustern konvertieren. Diese strenge Versionsanforderung gilt nur während des Upgrades auf einen erweiterten Cluster. Für alle anderen erweiterten Clusterupgrades gelten die Standardregeln für Versionsabweichungen.

Regeln für Upgrades der Patchversion

Führen Sie nach Möglichkeit ein Upgrade auf die neueste Patchversion durch, damit Ihre Cluster die neuesten Sicherheitsupdates haben. Patchversionen wirken sich nicht auf die Versionsabweichung und die Upgraderegeln aus. Für eine Nebenversion können Sie ein Upgrade auf eine höhere Patchversion ausführen. Beispielsweise können Sie ein Upgrade von 1.35.0 auf 1.35.1 und von 1.35.1 auf 1.35.3 durchführen.

Nächste Schritte