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 sein als die Knotenpools im Cluster. Wenn die Steuerungsebene eines Nutzerclusters beispielsweise Version 1.29 hat, können die Knotenpools im Cluster die 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 für Ubuntu- und COS-Knotenpools unterstützt, aber nicht für Windows-Knotenpools. Außerdem ist diese Funktion nicht verfügbar, wenn Sie erweiterte Cluster aktiviert haben.

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 wird beschrieben, 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 vorherige Version 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. Dadurch 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 veranschaulicht, 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.

Zusammenfassung

Zusammenfassend bietet ein Upgrade auf eine übersprungene 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 von 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

Mit dem Feld nodePools[i].gkeOnPremVersion in der Konfigurationsdatei des Nutzerclusters kann 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.

Versionsregeln

Die Regeln für Upgrades hängen von der Nebenversion des Clusters ab.

  • Bei Version 1.30 und niedriger muss die Nebenversion des Nutzerclusters mindestens der Nebenversion des Administratorclusters entsprechen. Die Patchversion spielt keine Rolle. Wenn ein Nutzercluster beispielsweise Version 1.30.1 hat, kann der Administratorcluster auf eine höhere Patchversion wie 1.30.3 aktualisiert werden.

  • Bei Version 1.31 und höher muss die Version des Administratorclusters, einschließlich der Patchversion, mindestens der Version des Nutzerclusters entsprechen. Wenn ein Administratorcluster beispielsweise Version 1.31.1 hat, ist 1.31.1 die höchste Version, auf die der Nutzercluster aktualisiert werden kann.

Wenn Sie Ihre Cluster auf Version 1.31 aktualisieren möchten, müssen Sie zuerst alle Cluster auf Version 1.30 umstellen. Nachdem alle Cluster auf Version 1.30 sind, führen Sie ein Upgrade des Administratorclusters auf Version 1.31 durch. Anschließend können Sie die Nutzercluster auf dieselbe Patchversion 1.31 wie den Administratorcluster aktualisieren.

Upgrade-Sequenz für Versionsüberspringung

Die Reihenfolge, in der Sie Administrator- und Nutzercluster aktualisieren, hängt von der Clusterversion ab, auf die Sie ein Upgrade durchführen, die sogenannte Zielversion:

1,31

Verwenden Sie diese spezielle Sequenz, wenn der Nutzercluster Version 1.29 hat, was bedeutet, dass die Zielversion 1.31 ist. Wenn ein Nutzercluster die Version 1.29 hat, kann ein Administratorcluster, das den Nutzercluster verwaltet, die Version 1.27, 1.28 oder 1.29 haben.

  1. Wenn Ihr Administratorcluster Version 1.27 hat, führen Sie ein Upgrade auf Version 1.28 durch.
  2. Wenn Ihr Administratorcluster Version 1.28 hat, führen Sie ein Upgrade auf Version 1.29 durch.
  3. Aktualisieren Sie nur die Steuerungsebene des Nutzerclusters von der Quellversion 1.29 auf eine Zwischenversion 1.30. Lassen Sie die Knotenpools bei der Quellversion. Die Zwischenversion 1.30 ist erforderlich, da die Steuerungsebene jeweils nur auf eine Nebenversion aktualisiert werden kann.
  4. Führen Sie ein Upgrade des Administratorclusters von Version 1.29 auf die Zwischenversion 1.30 durch.
  5. Führen Sie ein Upgrade des Administratorclusters auf die Zielversion 1.31 durch.
  6. Führen Sie ein Upgrade der Steuerungsebene des Nutzerclusters und der Knotenpools auf die Zielversion 1.31 durch.

1.30 und niedriger

Verwenden Sie diese Sequenz, wenn die Zielversion 1.30 oder niedriger ist.

Angenommen, die Steuerungsebene Ihres Nutzerclusters und alle Knotenpools haben die Nebenversion 1.N. Im Groben funktioniert das Upgrade Ihres Clusters von 1.N auf 1.N+2 mit einem Versionssprung so:

  1. Nur die Steuerungsebene von der Quellversion 1.N auf eine Zwischenversion 1.N+1 aktualisieren. 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.

Hinweis

  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,31

Verwenden Sie diese spezielle Sequenz, wenn der Nutzercluster Version 1.29 hat, d. h. die Zielversion 1.31 ist. Diese Sequenz ist erforderlich, da sich die Versionsregeln in Version 1.31 geändert haben.

Wenn ein Nutzercluster Version 1.29 hat, kann ein Administratorcluster, das den Nutzercluster verwaltet, Version 1.27, 1.28 oder 1.29 haben.

  1. Wenn Ihr Administratorcluster die Version 1.27 verwendet, folgen Sie der Anleitung zum Upgrade Ihrer Administrator-Workstation und zum Upgrade Ihres Administratorclusters auf Version 1.28.

  2. Wenn Ihr Administratorcluster die Version 1.28 hat, folgen Sie der Anleitung zum Upgrade Ihrer Administrator-Workstation und zum Upgrade Ihres Administratorclusters auf Version 1.29.

  3. Entfernen Sie die heruntergeladenen Bundles, um Speicherplatz auf Ihrer Administrator-Workstation freizugeben:

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Wenn der Administratorcluster und alle Nutzercluster Version 1.29 haben, können Sie mit dem Upgrade beginnen, bei dem eine Version übersprungen wird.

  1. Definieren Sie die Quellversion (1.29), eine Zwischenversion (1.30) und die Zielversion (1.31) in den folgenden Platzhaltervariablen. Alle Versionen müssen die vollständige Versionsnummer im Format x.y.z-gke.N haben, z. B. 1.29.700-gke.110.

    Version
    Rufen Sie die Version 1.29 des aktuellen Nutzerclusters ab. Das ist die Quellversion. SOURCE_VERSION
    Wählen Sie eine Zwischenversion 1.30 aus. INTERMEDIATE_VERSION
    Wählen Sie die Zielversion 1.31 aus. Wählen Sie den empfohlenen Patch aus der Nebenversion 1.31 aus. TARGET_VERSION

  2. Führen Sie ein Upgrade Ihrer Administrator-Workstation auf die Zwischenversion 1.30, 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

  4. Führen Sie ein weiteres Upgrade der Administrator-Workstation durch, diesmal auf die Zielversion 1.31, 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 des Nutzerclusters auf die Zwischenversion durch:

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

      • Geben Sie im Feld gkeOnPremVersion die Zwischenversion ein, 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. Legen Sie in der Konfigurationsdatei für den Administratorcluster das Feld bundlePath auf die Zwischenversion 1.30 des Bundles fest:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. Führen Sie ein Upgrade des Administratorclusters auf die Zwischenversion 1.30 durch:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. Legen Sie in der Konfigurationsdatei für den Administratorcluster das Feld bundlePath auf die Zielversion 1.31 des Bundles fest:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Upgrade the admin cluster to the target 1.31 version:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. 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 alle nodePools[i].gkeOnPremVersion auf 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

1.30 und niedriger

Verwenden Sie diese Sequenz, wenn die Zielversion 1.30 oder niedriger ist.

  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 aus der Zielminorversion den empfohlenen Patch 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 kubeconfig-Datei des Administratorclusters.

  4. Führen Sie ein weiteres Upgrade Ihrer 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:

      • Geben Sie im Feld gkeOnPremVersion die Zwischenversion ein, 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 alle nodePools[i].gkeOnPremVersion auf 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

Wenn Sie keine weiteren Nutzercluster aktualisieren müssen, entfernen Sie die Bundles von Ihrer Administrator-Workstation, um Speicherplatz freizugeben:

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Nächste Schritte