Diese Seite wurde von der Cloud Translation API übersetzt.

Version beim Upgrade von Knotenpools überspringen

In Version 1.29 und höher 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 Version 1.16, 1.28 oder 1.29 haben. Außerdem können Sie in Google Distributed Cloud beim Upgrade von Knotenpools eine Nebenversion überspringen. Im vorherigen Beispiel können Sie Knotenpools mit Version 1.16 direkt auf Version 1.29 aktualisieren und das Upgrade auf Version 1.28 überspringen. Das Überspringen einer Nebenversion beim Upgraden von Knotenpools wird als Skip-Version-Upgrade bezeichnet.

Auf dieser Seite werden einige Vorteile eines Versionsüberspringungs-Upgrades erläutert und es wird beschrieben, wie Sie ein Versionsüberspringungs-Upgrade durchführen, indem Sie Konfigurationsdateien ändern 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-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 Dokumenten beschrieben:

Beschränkungen

Für das Überspringen von Versionen gelten die folgenden Einschränkungen:

Das Überspringen von Versionen bei Upgrades wird für Ubuntu- und COS-Knotenpools unterstützt, aber nicht für Windows-Knotenpools.
Version 1.31: Diese Funktion ist für erweiterte Cluster nicht verfügbar.
Version 1.32 und höher: Diese Funktion ist in erweiterten Clustern verfügbar.
Aufgrund von Kubernetes-Einschränkungen muss die Steuerungsebene eines Nutzerclusters jeweils um eine Nebenversion aktualisiert werden. Das Upgrade nur der Steuerungsebene dauert jedoch deutlich weniger Zeit und ist weniger riskant als das Upgrade von Knotenpools, auf denen Ihre Arbeitslasten ausgeführt werden.

Vorteile von Versionsüberspringungs-Upgrades

In diesem Abschnitt werden einige Vorteile von Versionsüberspringungs-Upgrades beschrieben.

Cluster lassen sich leichter in einer unterstützten Version halten

Alle vier Monate wird eine neue Nebenversion von Google Distributed Cloud veröffentlicht. Jede Nebenversion hat ein einjähriges Supportzeitfenster. Damit Ihre Cluster im unterstützten Zeitraum bleiben, müssen Sie ungefähr alle vier Monate ein Upgrade auf eine Nebenversion durchführen, wie im Folgenden 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 Validierungszeitfenster benötigen, um eine neue Nebenversion zu prüfen, und ein kurzes Wartungszeitfenster, um Ihre Cluster auf die neue Nebenversion zu aktualisieren. Um diese Herausforderungen zu meistern, können Sie ein Skip-Version-Upgrade verwenden. Dadurch können Ihre Cluster innerhalb des unterstützten Zeitraums bleiben, indem Sie einen Cluster alle acht statt alle vier Monate aktualisieren. In der folgenden Tabelle sehen Sie, dass Sie durch das Überspringen des Upgrades für 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 mit Überspringen von Versionen müssen Sie das Wartungsfenster nicht verlängern. Das Überspringen einer Nebenversion beim Aktualisieren von Knotenpools dauert genauso lange wie das Aktualisieren der Knotenpools auf die nächste Nebenversion, da jeder Knoten in einem Knotenpool einmal geleert und neu erstellt wird. Ein Skip-Version-Upgrade spart daher insgesamt Zeit und reduziert Unterbrechungen der Arbeitslast.

Zusammenfassung

Zusammenfassend bietet ein Upgrade mit Überspringen von Versionen die folgenden Vorteile:

Cluster auf eine unterstützte Version aktualisieren: Google Distributed Cloud unterstützt die drei letzten Nebenversionen. Wenn Ihre Cluster eine nicht unterstützte Version verwenden, können Sie je nach Clusterversion beim Upgrade von Knotenpools eine Nebenversion überspringen, um Ihre Cluster mit weniger Upgrades auf eine unterstützte Version zu aktualisieren.
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 mit Überspringen von Versionen etwa halb so lange wie das zweimalige Aktualisieren von Knotenpools. Bei einem Upgrade mit Versionsüberspringung haben Sie nur ein Validierungsfenster, während es bei regulären Upgrades zwei sind.
Weniger Unterbrechungen: 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.

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

In der Konfigurationsdatei des Nutzerclusters kann mit dem Feld nodePools[i].gkeOnPremVersion für einen bestimmten Knotenpool eine andere Version als das Feld gkeOnPremVersion auf oberster Ebene verwendet werden. Durch Ändern des Werts des Felds nodePools[i].gkeOnPremVersion können Sie steuern, wann ein Knotenpool aktualisiert wird, wenn Sie gkectl upgrade cluster ausführen. 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 Versionen 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, kann der Nutzercluster höchstens auf Version 1.31.1 aktualisiert werden.

Wenn Sie Ihre Cluster auf Version 1.31 aktualisieren möchten, müssen Sie zuerst alle Ihre Cluster auf Version 1.30 aktualisieren. Wenn alle Cluster die Version 1.30 haben, führen Sie ein Upgrade des Administratorclusters auf Version 1.31 durch. Danach können Sie die Nutzercluster auf dieselbe 1.31-Patchversion wie den Administratorcluster aktualisieren.

Upgrade-Sequenz zum Überspringen von Versionen

Die Reihenfolge, in der Sie Administrator- und Nutzercluster aktualisieren, hängt von der Clusterversion ab, auf die Sie aktualisieren, der Zielversion:

1.32 und höher

Verwenden Sie diese Sequenz, wenn die Zielversion 1.32 oder höher ist. Angenommen, die Steuerungsebene Ihres Nutzerclusters und alle Knotenpools haben die Nebenversion 1.N. Auf übergeordneter Ebene funktioniert das Upgrade Ihres Clusters von 1.N auf 1.N+2 mit einem Skip-Version-Upgrade so:

Führen Sie ein Upgrade des Administratorclusters von Version 1.N auf eine Zwischenversion, 1.N+1, durch.
Führen Sie ein Upgrade des Administratorclusters von der Zwischenversion 1.N+1 auf die Zielversion 1.N+2 durch.
Aktualisieren Sie nur die Steuerungsebene des Nutzerclusters von der Quellversion 1.N auf eine Zwischenversion 1.N+1. Lassen Sie die Knotenpools in der Quellversion. Die Zwischenversion ist erforderlich, da die Steuerungsebene jeweils nur um eine Nebenversion aktualisiert werden kann.
Führen Sie ein Upgrade der Steuerungsebene und der Knotenpools auf die Zielversion 1.N+2 durch.

1,31

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

Wenn Ihr Administratorcluster Version 1.27 hat, führen Sie ein Upgrade auf Version 1.28 durch.
Wenn Ihr Administratorcluster Version 1.28 hat, führen Sie ein Upgrade auf Version 1.29 durch.
Führen Sie nur für die Steuerungsebene des Nutzerclusters ein Upgrade von der Quellversion 1.29 auf eine Zwischenversion 1.30 durch. Lassen Sie die Knotenpools in der Quellversion. Die Zwischenversion 1.30 ist erforderlich, da die Steuerungsebene jeweils nur um eine Nebenversion aktualisiert werden kann.
Aktualisieren Sie den Administratorcluster von Version 1.29 auf die Zwischenversion 1.30.
Aktualisieren Sie den Administratorcluster auf die Zielversion 1.31.
Aktualisieren Sie die Steuerungsebene des Nutzerclusters und die Knotenpools auf die Zielversion 1.31.

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. Auf übergeordneter Ebene funktioniert das Upgrade Ihres Clusters von 1.N auf 1.N+2 mit einem Skip-Version-Upgrade so:

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

Upgrade mit Überspringen von Versionen durchführen

In diesem Abschnitt finden Sie die Schritte für ein Upgrade, bei dem eine Version übersprungen wird.

Hinweise

Die aktuelle Version (die Quellversion) des Clusters muss Version 1.16 oder höher sein. Prüfen Sie die Version der Steuerungsebene (gkeOnPremVersion) und aller Knotenpools (nodePools[i].gkeOnPremVersion).
In Version 1.29 und später sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Prüfen Sie Ihre Firewallregeln und nehmen Sie die erforderlichen Änderungen vor.
Wenn Sie ein Upgrade auf Version 1.28 oder höher durchführen 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 Google API- und IAM-Anforderungen.

Führen Sie das Upgrade aus

1,31

Verwenden Sie diese spezielle Sequenz, wenn der Nutzercluster Version 1.29 hat. Die Zielversion ist dann 1.31. 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, der den Nutzercluster verwaltet, Version 1.27, 1.28 oder 1.29 haben.

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.
Wenn Ihr Administratorcluster die Version 1.28 hat, folgen Sie der Anleitung zum Aktualisieren Ihrer Administrator-Workstation und zum Aktualisieren Ihres Administratorclusters auf Version 1.29.
So sparen Sie Speicherplatz auf Ihrer Administrator-Workstation:
```
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
```

Wenn der Administratorcluster und alle Nutzercluster Version 1.29 haben, können Sie das Upgrade mit Überspringen von Versionen starten.

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 aktuelle Version 1.29 des 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`

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

Installieren Sie das entsprechende Bundle:

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

Führen Sie noch einmal ein Upgrade Ihrer Administrator-Workstation durch, diesmal auf die Zielversion 1.31, TARGET_VERSION. Warten Sie auf eine Meldung, die angibt, dass das Upgrade erfolgreich war.

Installieren Sie das entsprechende Bundle:

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

Führen Sie nur für die Steuerungsebene des Nutzerclusters ein Upgrade auf die Zwischenversion durch:
1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:
  - Setzen Sie das Feld gkeOnPremVersion auf die Zwischenversion 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. Upgrade der Steuerungsebene durchführen:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Ersetzen Sie USER_CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei des Nutzerclusters.
Legen Sie das Feld bundlePath in der Konfigurationsdatei des Administratorclusters auf die Zwischenversion 1.30 des Bundles fest:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
```

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

Legen Sie das Feld bundlePath in der Konfigurationsdatei für den Administratorcluster auf die Zielversion 1.31 des Bundles fest:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
```

Upgrade the admin cluster to the target 1.31 version:

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

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 für das Feld gkeOnPremVersion die Zielversion TARGET_VERSION fest.
  - Setzen Sie alle nodePools[i].gkeOnPremVersion auf einen leeren String.
  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.

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. Dies 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 Ziel-Nebenversion den empfohlenen Patch aus.	`TARGET_VERSION`

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

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 Ihrer kubeconfig-Datei für den Administratorcluster.

Führen Sie noch einmal ein Upgrade Ihrer Administrator-Workstation durch, diesmal auf die Zielversion TARGET_VERSION. Warten Sie auf eine Meldung, die angibt, dass das Upgrade erfolgreich war.

Installieren Sie das entsprechende Bundle:

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

Führen Sie nur für die Steuerungsebene ein Upgrade auf die Zwischenversion durch:
1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:
  - Setzen Sie das Feld gkeOnPremVersion auf die Zwischenversion 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. Upgrade der Steuerungsebene durchführen:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Ersetzen Sie USER_CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei des Nutzerclusters.
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 für das Feld gkeOnPremVersion die Zielversion TARGET_VERSION fest.
  - Setzen Sie alle nodePools[i].gkeOnPremVersion auf einen leeren String.
  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 upgraden müssen, entfernen Sie die Bundles von Ihrer Administrator-Workstation, um Speicherplatz zu sparen:

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

Version beim Upgrade von Knotenpools überspringen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Beschränkungen

Vorteile von Versionsüberspringungs-Upgrades

Cluster lassen sich leichter in einer unterstützten Version halten

Kürzeres Wartungsfenster

Zusammenfassung

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

Versionsregeln

Upgrade-Sequenz zum Überspringen von Versionen

1.32 und höher

1,31

1.30 und niedriger

Upgrade mit Überspringen von Versionen durchführen

Hinweise

Führen Sie das Upgrade aus

1,31

1.30 und niedriger

Nächste Schritte

Version beim Upgrade von Knotenpools überspringen