Version beim Upgrade von Knotenpools überspringen

Ab Version 1.29 kann die Steuerungsebene eines Nutzerclusters in Google Distributed Cloud bis zu zwei Nebenversionen höher als die Knotenpools im Cluster sein. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise 1.29 ist, können die Knotenpools im Cluster Version 1.16, 1.28 oder 1.29 haben. Außerdem können Sie in Google Distributed Cloud beim Upgraden von Knotenpools eine Nebenversion überspringen. Mit dem vorherigen Beispiel können Sie Knotenpools, die Version 1.16 haben, direkt auf Version 1.29 aktualisieren und das Upgrade auf Version 1.28 überspringen. Wenn Sie beim Upgraden von Knotenpools eine Nebenversion überspringen, wird dies als Versionsupgrade überspringen bezeichnet.

Upgrades, bei denen eine Version übersprungen wird, werden nur für Ubuntu- und COS-Knotenpools unterstützt. Aufgrund von Kubernetes-Einschränkungen muss die Steuerungsebene eines Nutzerclusters jeweils nur um eine Nebenversion aktualisiert werden. Beachten Sie jedoch, dass das Upgrade nur der Steuerungsebene deutlich weniger Zeit in Anspruch nimmt und weniger riskant ist als das Upgrade von Knotenpools, in denen Ihre Arbeitslasten ausgeführt werden.

Auf dieser Seite werden einige Vorteile eines Upgrades übersprungener Versionen erläutert. Außerdem finden Sie hier eine Anleitung dazu, wie Sie ein solches Upgrade durchführen, indem Sie Änderungen an der Konfigurationsdatei vornehmen und gkectl upgrade cluster ausführen.

Diese Seite richtet sich an IT-Administratoren und ‑Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben. Auf dieser Seite wird davon ausgegangen, dass Sie mit der Planung und Ausführung von Google Distributed Cloud-Upgrades vertraut sind, wie in den folgenden Artikeln beschrieben:

Vorteile von Upgrades, bei denen Versionen übersprungen werden

In diesem Abschnitt werden einige Vorteile von Upgrades ohne Zwischenversion beschrieben.

Cluster einfacher auf einer unterstützten Version halten

Alle vier Monate wird eine neue Nebenversion von Google Distributed Cloud veröffentlicht. Jede Nebenversion wird ein Jahr lang unterstützt. Damit Ihre Cluster innerhalb des unterstützten Zeitraums bleiben, müssen Sie ungefähr alle vier Monate ein Upgrade auf eine Nebenversion durchführen, wie unten dargestellt:

Dez.

Jan

Feb.

März

Apr.

Mai

Juni

Juli

Aug.

Sept.

Okt.

Nov.

Dez.

Jan

Feb.

März

Apr.

Mai

Juni

Juli

Aug.

Sept.

Okt.

Nov.

Dez.

Jan

Feb.

März
1,14 Upgrade
1,15 Upgrade
1.16 Upgrade
1,28 Upgrade
1,29 Upgrade

Diese Anforderung stellt eine Herausforderung dar, wenn Sie ein langes Validierungsfenster für die Überprüfung einer neuen Nebenversion und ein kurzes Wartungsfenster für das Upgrade Ihrer Cluster auf die neue Nebenversion benötigen. Um diese Herausforderungen zu meistern, können Sie ein Upgrade auf eine übersprungene Version verwenden. So bleiben Ihre Cluster innerhalb des unterstützten Zeitraums, da ein Cluster alle acht Monate statt alle vier Monate aktualisiert wird. In der folgenden Tabelle wird gezeigt, dass Sie bei einem Überspringen des Upgrades auf Version 1.15 erst nach acht statt nach vier Monaten ein Upgrade durchführen.

Dez.

Jan

Feb.

März

Apr.

Mai

Juni

Juli

Aug.

Sept.

Okt.

Nov.

Dez.

Jan

Feb.

März

Apr.

Mai

Juni

Juli

Aug.

Sept.

Okt.

Nov.

Dez.

Jan

Feb.

März
1,14 Upgrade
1,15
1.16 Upgrade
1,28
1,29

Wenn Sie beim Upgrade Ihrer Knotenpools eine Nebenversion überspringen, verringert sich die Anzahl der Upgrades, die erforderlich sind, um eine unterstützte Version zu verwenden. Außerdem müssen Sie die übersprungene Nebenversion nicht qualifizieren, da sie nur vorübergehend von der Steuerungsebene verwendet wird.

Kürzeres Wartungsfenster

Bei einem Upgrade, bei dem eine Version übersprungen wird, müssen Sie das Wartungsfenster nicht verlängern. Das Überspringen einer Nebenversion beim Upgraden von Knotenpools dauert genauso lange wie das Upgrade der Knotenpools auf die nächste Nebenversion, da jeder Knoten in einem Knotenpool einmal geleert und neu erstellt wird. Daher spart ein Upgrade mit übersprungener Version insgesamt Zeit und reduziert Unterbrechungen der Arbeitslast.

Fazit

Zusammenfassend bietet ein Upgrade mit übersprungener Version folgende Vorteile:

  • Cluster auf eine unterstützte Version umstellen: Google Distributed Cloud unterstützt die drei neuesten Nebenversionen. Wenn Ihre Cluster eine nicht unterstützte Version verwenden, kann es je nach Clusterversion sein, dass Sie Ihre Cluster mit weniger Upgrades auf eine unterstützte Version umstellen können, wenn Sie beim Upgrade der Knotenpools eine Nebenversion überspringen.

  • Zeit sparen: Das Überspringen einer Nebenversion beim Upgrade von Knotenpools dauert genauso lange wie das Upgrade der Knotenpools auf die nächste Nebenversion. Daher dauert ein Upgrade der Versionsüberprüfung etwa halb so lange wie ein doppeltes Upgrade der Knotenpools. Bei einem Upgrade mit übersprungener Version haben Sie nur ein Validierungsfenster, verglichen mit zwei bei regulären Upgrades.

  • Unterbrechungen reduzieren: Längere Zeiträume zwischen Upgrades und weniger Zeit für Upgrades und Validierung bedeuten, dass Ihre Arbeitslasten länger und mit weniger Unterbrechungen ausgeführt werden.

Steuerung der Versionen der Steuerungsebene und des Knotenpools während eines Upgrades

In der Konfigurationsdatei des Nutzerclusters kann mit dem Feld nodePools[i].gkeOnPremVersion für einen bestimmten Knotenpool eine andere Version als das Feld gkeOnPremVersion der obersten Ebene verwendet werden. Wenn Sie den Wert des Felds nodePools[i].gkeOnPremVersion ändern, können Sie festlegen, wann ein Knotenpool bei Ausführung von gkectl upgrade cluster aktualisiert wird. Wenn Sie nodePools[i].gkeOnPremVersion nicht in die Konfigurationsdatei aufnehmen oder das Feld auf einen leeren String festlegen, werden Knotenpools auf dieselbe Zielversion aktualisiert, die Sie in gkeOnPremVersion angeben.

Upgrade-Sequenz für Versionsüberspringung

Angenommen, die Steuerungsebene Ihres Clusters und alle Knotenpools haben die Nebenversion 1.N. Im Groben funktioniert das Upgrade Ihres Clusters von 1.N auf 1.N+2 mit einem Upgrade, bei dem eine Version übersprungen wird, so:

  1. Führen Sie nur ein Upgrade der Steuerungsebene von der Quellversion (1.N) auf eine Zwischenversion (1.N+1) durch. Lassen Sie die Knotenpools bei der Quellversion. Die Zwischenversion ist erforderlich, da die Steuerungsebene jeweils nur auf eine Nebenversion aktualisiert werden kann.
  2. Führen Sie ein Upgrade der Steuerungsebene und der Knotenpools auf die Zielversion (1.N+2) durch.

Upgrade überspringen

In diesem Abschnitt werden die Schritte zum Ausführen eines Upgrades übersprungener Versionen beschrieben.

Hinweise

  1. Die aktuelle Version (die Quellversion) des Clusters muss mindestens Version 1.16 sein. Prüfen Sie die Version der Steuerungsebene (gkeOnPremVersion) und aller Knotenpools (nodePools[i].gkeOnPremVersion).

  2. In Version 1.29 und später sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Prüfen Sie Ihre Firewallregeln und nehmen Sie gegebenenfalls Änderungen vor.

  3. Wenn Sie auf Version 1.28 oder höher umstellen möchten, müssen Sie kubernetesmetadata.googleapis.com aktivieren und dem Logging-Monitoring-Dienstkonto die IAM-Rolle kubernetesmetadata.publisher zuweisen. Weitere Informationen finden Sie unter Anforderungen an Google APIs und IAM.

Führen Sie das Upgrade aus

  1. Definieren Sie die Quellversion (1.N), die Zwischenversion (1.N+1) und die Zielversion (1.N+2) in den folgenden Platzhaltervariablen. Alle Versionen müssen die vollständige Versionsnummer im Format x.y.z-gke.N haben, z. B. 1.16.11-gke.25.

    Version
    Rufen Sie die aktuelle Clusterversion ab. Das ist die Quellversion (1.N). SOURCE_VERSION
    Wählen Sie eine Zwischenversion (1.N+1) aus. INTERMEDIATE_VERSION
    Wählen Sie die Zielversion (1.N+2) aus. Wählen Sie dann den empfohlenen Patch aus der Zielminorversion aus. TARGET_VERSION

  2. Führen Sie ein Upgrade Ihrer Administrator-Workstation auf die Zwischenversion INTERMEDIATE_VERSION durch. Warten Sie auf eine Meldung, dass das Upgrade erfolgreich war.

  3. Installieren Sie das entsprechende Bundle:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der Datei kubeconfig des Administratorclusters.

  4. Führen Sie ein weiteres Upgrade der Administrator-Workstation durch, diesmal auf die Zielversion TARGET_VERSION. Warten Sie auf eine Meldung, dass das Upgrade erfolgreich war.

  5. Installieren Sie das entsprechende Bundle:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Führen Sie ein Upgrade nur der Steuerungsebene auf die Zwischenversion durch:

    1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:

      • Legen Sie im Feld gkeOnPremVersion die Zwischenversion fest, also INTERMEDIATE_VERSION.

      • Legen Sie alle Knotenpoolversionen in nodePools[i].gkeOnPremVersion auf die Quellversion SOURCE_VERSION fest.

      Nach der Aktualisierung sollte Ihre Konfigurationsdatei in etwa so aussehen:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Führen Sie ein Upgrade der Steuerungsebene durch:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Ersetzen Sie USER_CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei Ihres Nutzerclusters.

  7. Führen Sie ein Upgrade der Steuerungsebene und der Knotenpools auf die Zielversion durch:

    1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:

      • Legen Sie im Feld gkeOnPremVersion die Zielversion fest, also TARGET_VERSION.

      • Legen Sie für alle nodePools[i].gkeOnPremVersion einen leeren String fest.

      Nach der Aktualisierung sollte Ihre Konfigurationsdatei in etwa so aussehen:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Führen Sie ein Upgrade der Steuerungsebene und der Knotenpools durch:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

Nächste Schritte