Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Cluster oder Knotenpool upgraden

In diesem Dokument wird erläutert, wie Sie Cluster und Knotenpools in Google Distributed Cloud aktualisieren. In diesem Dokument werden die Schritte zum Upgraden Ihrer Administratorworkstation, Nutzercluster und Administratorcluster beschrieben. Für Nutzercluster enthält dieses Dokument die Schritte, mit denen die Steuerungsebene und die Knotenpools gleichzeitig oder separat aktualisiert werden können.

Bevor Sie fortfahren, empfehlen wir Ihnen, die folgende Dokumentation zu lesen:

Upgrade-Übersicht
In diesem Dokument werden unter anderem die unterstützten Versionsabweichungen und Versionsregeln für Upgrades beschrieben, die sich ab Version 1.28 geändert haben.
Best Practices für das Upgrade
Dieses Dokument enthält Checklisten und Best Practices für das Upgrade von Clustern.

Firewallregeln überprüfen

In Version 1.29 und höher sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Für serverseitige Preflight-Prüfungen sind zusätzliche Firewallregeln erforderlich. Suchen Sie unter Firewallregeln für Administratorcluster nach „Preflight-Prüfungen“ und prüfen Sie, ob alle erforderlichen Firewallregeln konfiguriert sind.

Bei serverseitigen Preflight-Prüfungen werden beim Upgrade eines Nutzerclusters mit gkectl die Preflight-Prüfungen auf dem Administratorcluster und nicht lokal auf der Administratorworkstation ausgeführt. Serverseitige Preflight-Prüfungen werden auch im Administratorcluster ausgeführt, wenn Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden, um einen Cluster zu aktualisieren.

Wenn Sie einen Administratorcluster upgraden, stellt Google Distributed Cloud einen Kubernetes-in-Docker-Cluster (Typ) bereit, um die Kubernetes-Controller, die zum Upgrade des Administratorclusters erforderlich sind, vorübergehend zu hosten. Dieser temporäre Cluster wird als Bootstrap-Cluster bezeichnet. Serverseitige Preflight-Prüfungen werden im Bootstrap-Cluster ausgeführt, wenn Sie einen Administratorcluster aktualisieren.

Google API- und IAM-Anforderungen

Für ein Upgrade eines Clusters auf Version 1.28 und höher müssen Sie kubernetesmetadata.googleapis.com aktivieren und dem Logging-Monitoring-Dienstkonto die IAM-Rolle kubernetesmetadata.publisher zuweisen. Diese Änderungen sind für die Verwendung von Cloud Monitoring erforderlich.

kubernetesmetadata.googleapis.com aktivieren:
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Ersetzen Sie PROJECT_ID durch die ID des Flotten-Hostprojekts, in dem der Nutzercluster Mitglied ist. Dies ist das Projekt, das Sie beim Erstellen des Clusters angegeben haben. Wenn Sie den Cluster mit gkectl erstellt haben, ist dies die Projekt-ID im Feld gkeConnect.projectID der Clusterkonfigurationsdatei.
Wenn Ihre Organisation eine Zulassungsliste eingerichtet hat, damit Traffic von Google APIs und anderen Adressen über Ihren Proxyserver geleitet wird, fügen Sie kubernetesmetadata.googleapis.com der Zulassungsliste hinzu.
Weisen Sie dem Logging-Monitoring-Dienstkonto die Rolle kubernetesmetadata.publisher zu:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
Ersetzen Sie SERVICE_ACCOUNT_EMAIL durch die E-Mail-Adresse Ihres Logging-Monitoring-Dienstkontos.

IAM-Anforderungen für das Upgrade von Nutzerclustern

Überspringen Sie diesen Abschnitt, wenn Sie gkectl für das Nutzerclusterupgrade verwenden möchten.

Wenn Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden möchten, um einen Nutzercluster zu aktualisieren, und Sie kein Projektinhaber sind, muss Ihnen die Identity and Access Management-Rolle roles/gkeonprem.admin für das Google Cloud-Projekt gewährt werden, in dem der Cluster erstellt wurde. Ausführliche Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie unter GKE On-Prem-Rollen in der IAM-Dokumentation.

Damit Sie den Cluster über die Console aktualisieren können, benötigen Sie mindestens Folgendes:

roles/container.viewer: Mit dieser Rolle können Nutzer die Seite „GKE-Cluster“ und andere Containerressourcen in der Console ansehen. Einzelheiten zu den in dieser Rolle enthaltenen Berechtigungen oder zum Zuweisen einer Rolle mit Lese-/Schreibberechtigungen finden Sie unter Kubernetes Engine-Rollen in der IAM-Dokumentation.
roles/gkehub.viewer: Mit dieser Rolle können Nutzer Cluster in der Console ansehen. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen oder zum Zuweisen einer Rolle mit Lese-/Schreibberechtigungen finden Sie in der IAM-Dokumentation unter GKE-Hub-Rollen.

Konfigurationsänderungen vor oder nach einem Upgrade vornehmen

Wenn Sie Konfigurationsänderungen an Ihren Clustern vornehmen müssen, führen Sie die Clusteraktualisierung entweder vor oder nach dem Upgrade durch. Die einzige Änderung an der Clusterkonfiguration für ein Upgrade sollte die Version sein. Je nach Clusterversion und -typ werden andere Konfigurationsänderungen entweder unbemerkt ignoriert oder das Upgrade schlägt fehl. Weitere Informationen finden Sie unter Nicht unterstützte Änderungen entfernen, um die Blockierung des Upgrades aufzuheben.

Führen Sie ein Upgrade Ihrer Administrator-Workstation durch.

Sie müssen Ihre Administratorworkstation aktualisieren, wenn Sie gkectl zum Upgrade eines Nutzerclusters verwenden möchten.

Wenn Sie die Console, die gcloud CLI oder Terraform zum Aktualisieren eines Nutzerclusters verwenden möchten, können Sie das Upgrade der Administratorworkstation vorerst überspringen. Sie müssen jedoch die Administratorworkstation aktualisieren, wenn Sie für ein Upgrade des Administratorclusters bereit sind, da nur gkectl Administratorclusterupgrades unterstützt.

Wie Sie die Administrator-Workstation upgraden, hängt davon ab, wie Sie sie erstellt haben: gkeadm oder user-mmanaged.

gkeadm

Erforderliche Dateien suchen

Bevor Sie die Administratorworkstation erstellt haben, haben Sie eine Konfigurationsdatei für die Administratorworkstation ausgefüllt, die von gkeadm create config generiert wurde. Der Standardname dieser Datei ist admin-ws-config.yaml.

Darüber hinaus hat Ihre Workstation eine Informationsdatei. Der Standardname dieser Datei entspricht dem Namen Ihrer Administrator-Workstation.

Suchen Sie die Konfigurationsdatei für die Administrator-Workstation und die Informationsdatei. Sie benötigen sie für die Durchführung der Upgradeschritte. Wenn sich diese Dateien in Ihrem aktuellen Verzeichnis befinden und die Standardnamen haben, müssen Sie sie beim Ausführen der Upgrade-Befehle nicht angeben. Wenn sich diese Dateien in einem anderen Verzeichnis befinden oder Sie die Dateinamen geändert haben, geben Sie sie mit den Flags --config und --info-file an.

Wenn Ihre Ausgabe-Informationsdatei fehlt, können Sie sie neu erstellen. Weitere Informationen finden Sie unter Informationsdatei neu erstellen, falls fehlt.

Upgrade

So führen Sie ein Upgrade der Administrator-Workstation aus:

gkeadm herunterladen:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Ersetzen Sie TARGET_VERSION durch die Zielversion Ihres Upgrades. Sie müssen eine vollständige Versionsnummer im Format X.Y.Z-gke.N. angeben. Eine Liste der Versionen von Google Distributed Cloud finden Sie im Versionsverlauf.
Führen Sie ein Upgrade Ihrer Administrator-Workstation durch:
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE
```
Ersetzen Sie Folgendes:
- AW_CONFIG_FILE ist der Pfad zur Konfigurationsdatei der Administrator-Workstation. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet und den Namen admin-ws-config.yaml hat.
- INFO_FILE ist der Pfad zur Informationsdatei. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet. Der Standardname dieser Datei entspricht dem Namen Ihrer Administrator-Workstation.

Vom Nutzer verwaltet

Rufen Sie auf Ihrer Administrator-Workstation ein Verzeichnis auf, in dem Sie eine neue Version von gkectl installieren möchten.

gkectl herunterladen:

gsutil cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

Ersetzen Sie VERSION durch die Zielversion Ihres Upgrades. Beispiel: 1.29.100-gke.248

Laden Sie das Google Distributed Cloud-Bundle herunter. Die Version muss mit der Version übereinstimmen, die Sie zum Herunterladen von gkectl verwendet haben:

gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

Verfügbare Versionen für Clusterupgrades prüfen

Führen Sie den folgenden Befehl aus, um zu sehen, welche Versionen für Upgrades verfügbar sind:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe zeigt die aktuelle Version und die für ein Upgrade verfügbaren Versionen.

Wenn Sie die Console, die gcloud CLI oder Terraform für das Upgrade verwenden möchten, dauert es nach einem Release etwa sieben bis zehn Tage, bis die Version in der GKE On-Prem API in allen Google Cloud-Regionen verfügbar ist. In der Console werden nur die verfügbaren Versionen für das Nutzerclusterupgrade aufgeführt. Die Schritte zum Upgrade eines Nutzerclusters mit der gcloud CLI oder Terraform umfassen einen Schritt zum Ausführen von gcloud container vmware clusters query-version-config, um verfügbare Versionen für das Upgrade abzurufen.

Nutzercluster aktualisieren

Sie können einen Nutzercluster mit gkectl, der Console, der gcloud CLI oder Terraform aktualisieren. Informationen zur Entscheidung, welches Tool verwendet werden soll, finden Sie unter Tool für das Upgrade von Nutzerclustern auswählen.

gkectl

Upgrade eines Nutzerclusters vorbereiten

Führen Sie auf Ihrer Administratorworkstation die folgenden Schritte aus:

Führen Sie gkectl prepare aus, um Betriebssystem-Images in vSphere zu importieren:

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

Wenn der Cluster einen Windows-Knotenpool hat, führen Sie gkectl prepare windows aus und aktualisieren Sie das Feld osImage für den Knotenpool. Eine ausführliche Anleitung finden Sie unter Nutzercluster mit Windows-Knotenpools upgraden.
Legen Sie in der Konfigurationsdatei des Nutzerclusters für gkeOnPremVersion die Zielversion Ihres Upgrades fest.
Nur Ubuntu- und COS-Knotenpools: Geben Sie an, für welche Knotenpools Sie ein Upgrade ausführen möchten. Ein Upgrade von Knotenpools unabhängig von der Steuerungsebene wird für Ubuntu- und COS-Knotenpools unterstützt, jedoch nicht für Windows-Knotenpools.

Geben Sie in der Konfigurationsdatei des Nutzerclusters so an, welche Knotenpools Sie aktualisieren möchten:
- Entfernen Sie für jeden Knotenpool, den Sie aktualisieren möchten, das Feld nodePools.nodePool[i].gkeOnPremVersion oder geben Sie einen leeren String an.
- Legen Sie für jeden Knotenpool, den Sie nicht aktualisieren möchten, nodePools.nodePool[i].gkeOnPremVersion auf die aktuelle Version fest.
Angenommen, Ihr Nutzercluster hat die Version 1.15.5-gke.41 und hat zwei Knotenpools: pool-1 und pool-2. Angenommen, Sie möchten die Steuerungsebene und pool-1 auf 1.16.3-gke.45 aktualisieren, aber pool-2 soll bei Version 1.15.5-gke.41 bleiben. Der folgende Teil einer Nutzercluster-Konfigurationsdatei zeigt, wie dieses Beispiel angegeben wird:
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: 1.15.5-gke.41
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```

Preflight-Prüfungen ausführen

Wenn Sie ein Upgrade auf Version 1.29 und höher durchführen, können Sie die Preflight-Prüfungen ausführen, bevor Sie einen Nutzercluster upgraden:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --dry-run

Mit dem Flag --dry-run führt gkectl upgrade cluster die Preflight-Prüfungen aus, startet aber nicht den Upgradeprozess. Obwohl frühere Versionen von Google Distributed Cloud Preflight-Prüfungen ausführen, können sie nicht separat vom Upgrade ausgeführt werden. Durch Hinzufügen des Flags --dry-run können Sie alle Probleme finden und beheben, die die Preflight-Prüfungen vor dem Upgrade mit Ihrem Nutzercluster feststellen.

Führen Sie `gkectl upgrade cluster` aus

Es gibt zwei Varianten des Befehls gkectl upgrade cluster:

Asynchron: (empfohlen)
. Bei der asynchronen Variante startet der Befehl das Upgrade und wird dann abgeschlossen. Sie müssen die Ausgabe des Befehls nicht während der gesamten Dauer des Upgrades beobachten. Stattdessen können Sie den Fortschritt des Upgrades regelmäßig überprüfen, indem Sie gkectl list clusters und gkectl describe clusters ausführen. Um die asynchrone Variante zu verwenden, fügen Sie das Flag --async in den Befehl ein.
Synchron:
Bei der synchronen Variante gibt der Befehl gkectl upgrade cluster während des Upgrades Statusmeldungen an die Administrator-Workstation aus.

Asynchrones Upgrade

Überspringen Sie diesen Schritt, wenn Sie ein Upgrade auf eine Version nach 1.16 ausführen.

Wenn Sie vorbereitete Anmeldedaten und eine private Registry für den Nutzercluster verwenden, müssen die privaten Registry-Anmeldedaten vor dem Upgrade des Nutzerclusters vorbereitet werden. Informationen zum Vorbereiten der Anmeldedaten für die private Registry finden Sie unter Vorbereitete Anmeldedaten für Nutzercluster konfigurieren.
Starten Sie auf Ihrer Administrator-Workstation ein asynchrones Upgrade:
```
gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async
```
Der vorherige Befehl wird abgeschlossen und Sie können die Administrator-Workstation während des Upgrades weiter verwenden.
So rufen Sie den Status der Umstellung ab:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Die Ausgabe zeigt einen Wert für den Cluster STATE. Wenn für den Cluster noch ein Upgrade durchgeführt wird, lautet der Wert von STATE UPGRADING. Beispiel:
```
NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.29.0-gke.1
```
Die möglichen Werte für STATE sind PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR und UNKNOWN.

So erhalten Sie weitere Informationen zum Upgradefortschritt und zu Clusterereignissen:

gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

Die Ausgabe zeigt die benutzerdefinierte OnPremUserCluster-Ressource für den angegebenen Nutzercluster, die Clusterstatus, Bedingungen und Ereignisse enthält.

Wir zeichnen zu Beginn und zum Ende jeder kritischen Upgradephase Ereignisse auf, darunter:

ControlPlaneUpgrade
MasterNodeUpgrade
AddonsUpgrade
NodePoolsUpgrade

Beispielausgabe:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

Wenn das Upgrade abgeschlossen ist, zeigt gkectl list clusters eine STATUS von RUNNING an:
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.29.0-gke.1
```
Wenn das Upgrade abgeschlossen ist, zeigt gkectl describe clusters außerdem unter Status das Feld Last GKE On Prem Version an. Beispiel:
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.29.0-gke.1
```

Fehlerbehebung beim asynchronen Upgrade

Normalerweise ist ein Zeitlimit das Ergebnis eines Deadlocks, das durch ein PodDisruptionBudget (PDB) verursacht wird. In diesem Fall können Pods nicht von alten Knoten entfernt und die alten Knoten können nicht per Drain beendet werden. Wenn die Pod-Bereinigung länger als 10 Minuten dauert, wird ein Ereignis in das OnPremUserCluster-Objekt geschrieben. Sie können das Ereignis erfassen, indem Sie gkectl describe clusters ausführen. Anschließend können Sie das PDB so anpassen, dass der Knoten per Drain beendet wird. Danach kann das Upgrade fortgesetzt und schließlich abgeschlossen werden.

Beispielereignis:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Wenn ein Upgrade blockiert ist oder fehlschlägt, können Sie außerdem gkectl diagnose ausführen, um nach häufigen Clusterproblemen zu suchen. Basierend auf dem Ergebnis können Sie entscheiden, ob Sie eine manuelle Korrektur vornehmen oder das Anthos-Supportteam kontaktieren möchten, um weitere Unterstützung zu erhalten.

Synchrones Upgrade

Mit dem Befehl gkectl upgrade werden Preflight-Prüfungen ausgeführt. Wenn die Preflight-Prüfungen fehlschlagen, wird der Befehl blockiert. Sie müssen die Fehler beheben oder das Flag --skip-preflight-check-blocking verwenden. Sie sollten die Preflight-Prüfungen nur überspringen, wenn Sie sicher sind, dass keine kritischen Fehler vorliegen.

Führen Sie die folgenden Schritte auf Ihrer Administrator-Workstation aus:

Überspringen Sie diesen Schritt, wenn Sie ein Upgrade auf eine Version nach 1.16 ausführen.

Wenn Sie vorbereitete Anmeldedaten und eine private Registry für den Nutzercluster verwenden, müssen die privaten Registry-Anmeldedaten vor dem Upgrade des Nutzerclusters vorbereitet werden. Informationen zum Vorbereiten der Anmeldedaten für die private Registry finden Sie unter Vorbereitete Anmeldedaten für Nutzercluster konfigurieren.

Aktualisieren Sie den Cluster:

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

Wenn Sie ein Upgrade auf Version 1.14.0 oder höher durchführen, wird für den Nutzercluster eine neue kubeconfig-Datei generiert, die alle vorhandenen Dateien überschreibt. Führen Sie den folgenden Befehl aus, um Clusterdetails in der Datei anzusehen:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Zusätzliche Knotenpools upgraden

Wenn Sie nur die Steuerungsebene des Nutzerclusters aktualisiert oder ein Upgrade für die Steuerungsebene und einige, aber nicht alle Knotenpools durchgeführt haben, führen Sie die folgenden Schritte aus, um ein Upgrade der Knotenpools durchzuführen:

Bearbeiten Sie die Konfigurationsdatei des Nutzerclusters. Entfernen Sie für jeden Knotenpool, den Sie aktualisieren möchten, das Feld nodePools.nodePool[i].gkeOnPremVersion oder legen Sie es auf den leeren String fest, wie im folgenden Beispiel gezeigt:

gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd

Führen Sie gkectl update cluster aus, um die Änderung zu übernehmen:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei Ihres Administratorclusters
- USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Wenn nach dem Upgrade eines Knotenpools ein Problem auftritt, können Sie ein Rollback zur vorherigen Version durchführen. Weitere Informationen finden Sie unter Rollback eines Knotenpools nach einem Upgrade durchführen.

Upgrade fortsetzen

Wenn das Upgrade eines Nutzerclusters unterbrochen wird, können Sie das Upgrade des Nutzerclusters fortsetzen, indem Sie denselben Upgradebefehl mit dem Flag --skip-validation-all ausführen:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE \
  --skip-validation-all

Console

Für ein Upgrade eines Nutzerclusters sind einige Änderungen am Administratorcluster erforderlich. Die Console führt automatisch folgende Schritte aus:

Registriert den Administratorcluster in der GKE On-Prem API, falls er noch nicht registriert ist.
Lädt ein Komponenten-Bundle herunter und stellt es im Administratorcluster bereit. Die Version der Komponenten entspricht der Version, die Sie für das Upgrade angeben. Mit diesen Komponenten kann der Administratorcluster Nutzercluster mit dieser Version verwalten.

So aktualisieren Sie einen Nutzercluster:

Rufen Sie in der Console die Übersichtsseite für Google Kubernetes Engine-Cluster auf.

Zu GKE-Clustern
Wählen Sie das Google Cloud-Projekt und dann den Cluster aus, den Sie upgraden möchten.
Klicken Sie im Bereich Details auf Mehr Details.
Klicken Sie im Abschnitt Clustergrundlagen auf Upgrade.
Wählen Sie in der Liste Zielversion auswählen die Version aus, auf die Sie ein Upgrade ausführen möchten. Die Liste enthält nur die neuesten Patchreleases.
Klicken Sie auf Upgrade.

Vor dem Upgrade des Clusters werden Preflight-Prüfungen ausgeführt, um den Clusterstatus und Knotenzustand zu validieren. Wenn die Preflight-Prüfungen bestanden sind, wird der Nutzercluster aktualisiert. Es dauert etwa 30 Minuten, bis das Upgrade abgeschlossen ist.

Klicken Sie auf dem Tab Clusterdetails auf Details anzeigen, um den Status des Upgrades anzusehen.

gcloud-CLI

Für ein Upgrade eines Nutzerclusters sind einige Änderungen am Administratorcluster erforderlich. Der Befehl gcloud container vmware clusters upgrade führt automatisch folgende Schritte aus:

Registriert den Administratorcluster in der GKE On-Prem API, falls er noch nicht registriert ist.
Lädt ein Komponenten-Bundle herunter und stellt es im Administratorcluster bereit. Die Version der Komponenten entspricht der Version, die Sie für das Upgrade angeben. Mit diesen Komponenten kann der Administratorcluster Nutzercluster mit dieser Version verwalten.

So aktualisieren Sie einen Nutzercluster:

Aktualisieren Sie die Google Cloud CLI-Komponenten:
```
gcloud components update
```
Nur Ubuntu- und COS-Knotenpools: Wenn Sie nur für die Steuerungsebene des Nutzerclusters ein Upgrade ausführen und alle Knotenpools in der aktuellen Version belassen möchten, ändern Sie die Upgraderichtlinie für den Cluster:
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True
```
Ersetzen Sie Folgendes:
- USER_CLUSTER_NAME: Der Name des Nutzerclusters, der aktualisiert werden soll.
- PROJECT_ID: Die ID des Flotten-Hostprojekts, in dem der Nutzercluster Mitglied ist. Dies ist das Projekt, das Sie beim Erstellen des Clusters angegeben haben. Wenn Sie den Cluster mit gkectl erstellt haben, ist dies die Projekt-ID im Feld gkeConnect.projectID der Clusterkonfigurationsdatei.
- REGION: Die Google Cloud-Region, in der die GKE On-Prem API ausgeführt wird und ihre Metadaten speichert. Wenn Sie den Cluster mit einem GKE On-Prem API-Client erstellt haben, ist dies die Region, die Sie beim Erstellen des Clusters ausgewählt haben. Wenn Sie den Cluster mit gkectl erstellt haben, ist dies die Region, die Sie bei der Registrierung des Clusters in der GKE On-Prem API angegeben haben.

Rufen Sie eine Liste der verfügbaren Versionen ab, auf die Sie upgraden können:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Die Ausgabe dieses Befehls sieht in etwa so aus:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Sie können die Meldung nach der Liste der Versionen ignorieren. Dabei spielt es keine Rolle, ob die Version, auf die Sie ein Upgrade durchführen, auf dem Administratorcluster installiert ist. Mit dem Befehl upgrade wird ein Komponenten-Bundle heruntergeladen und bereitgestellt, das der Version entspricht, die Sie im Befehl upgrade angeben.

Aktualisieren Sie den Cluster. Wenn Sie die Upgraderichtlinie mit dem Befehl update in control-plane-only=True geändert haben, wird nur die Steuerungsebene des Clusters aktualisiert. Andernfalls werden die Steuerungsebene des Clusters und alle Knotenpools aktualisiert.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Ersetzen Sie VERSION durch die Google Distributed Cloud-Version, auf die Sie ein Upgrade ausführen möchten. Geben Sie eine Version aus der Ausgabe des vorherigen Befehls an. Wir empfehlen ein Upgrade auf die neueste Patchversion.

Die Ausgabe des Befehls sieht in etwa so aus:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
In der Beispielausgabe ist der String operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 die OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs ermitteln, indem Sie den folgenden Befehl in einem anderen Terminalfenster ausführen:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

Upgrade für Knotenpools durchführen

Wenn Sie nur die Steuerungsebene des Nutzerclusters upgraden möchten, führen Sie die folgenden Schritte aus, um die Knotenpools nach dem Upgrade der Steuerungsebene des Nutzerclusters zu aktualisieren:

Rufen Sie eine Liste der Knotenpools im Nutzercluster ab:

gcloud container vmware node-pools list
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION

Führen Sie für jeden Knotenpool, den Sie aktualisieren möchten, den folgenden Befehl aus:

gcloud container vmware node-pools update NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

Terraform

Aktualisieren Sie die Google Cloud CLI-Komponenten:
```
gcloud components update
```
Registrieren Sie den Administratorcluster bei der GKE On-Prem API, falls noch nicht geschehen. Nachdem der Cluster bei der GKE On-Prem API registriert wurde, müssen Sie diesen Schritt nicht noch einmal ausführen.

Rufen Sie eine Liste der verfügbaren Versionen ab, auf die Sie upgraden können:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Ersetzen Sie Folgendes:

USER_CLUSTER_NAME: Der Name des Nutzerclusters.
PROJECT_ID: Die ID des Flottenprojekts, dem dieser Nutzercluster angehört. Dies ist das Projekt, das Sie beim Erstellen des Clusters angegeben haben. Wenn Sie den Cluster mit gkectl erstellt haben, ist dies die Projekt-ID im Feld gkeConnect.projectID der Clusterkonfigurationsdatei.
REGION: Die Google Cloud-Region, in der die GKE On-Prem API ausgeführt wird und ihre Metadaten speichert. In der Datei main.tf, die Sie zum Erstellen des Nutzerclusters verwendet haben, befindet sich die Region im Feld location der Clusterressource.

Die Ausgabe dieses Befehls sieht in etwa so aus:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Laden Sie die neue Version der Komponenten herunter und stellen Sie sie im Administratorcluster bereit:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Mit diesem Befehl wird die Version der Komponenten, die Sie in --required-platform-version angeben, auf den Administratorcluster heruntergeladen und dann die Komponenten bereitgestellt. Mit diesen Komponenten kann der Administratorcluster Nutzercluster mit dieser Version verwalten.
Ändern Sie in der Datei main.tf, die Sie zum Erstellen des Nutzerclusters verwendet haben, on_prem_version in der Clusterressource auf die neue Version.
Nur Ubuntu- und COS-Knotenpools: Wenn Sie nur die Steuerungsebene des Nutzerclusters upgraden und alle Knotenpools in der aktuellen Version belassen möchten, fügen Sie der Clusterressource Folgendes hinzu:
```
upgrade_policy {
  control_plane_only = true
}
```
Initialisieren und erstellen Sie den Terraform-Plan:
```
terraform init
```
Terraform installiert alle erforderlichen Bibliotheken, z. B. den Google Cloud-Anbieter.
Überprüfen Sie die Konfiguration und nehmen Sie bei Bedarf Änderungen vor:
```
terraform plan
```
Wenden Sie den Terraform-Plan an, um den Nutzercluster zu erstellen:
```
terraform apply
```

Upgrade für Knotenpools durchführen

Wenn Sie nur die Steuerungsebene des Nutzerclusters upgraden möchten, führen Sie die folgenden Schritte aus, um zusätzliche Knotenpools nach dem Upgrade der Steuerungsebene des Nutzerclusters zu aktualisieren:

Fügen Sie in main.tf der Ressource für jeden Knotenpool, den Sie aktualisieren möchten, Folgendes hinzu:

on_prem_version = "VERSION"

Beispiel:

resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" {
name = "my-nodepool"
location = "us-west1"
vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name
config {
  replicas = 3
  image_type = "ubuntu_containerd"
  enable_load_balancer = true
}
on_prem_version = "1.16.0-gke.0"
}

Initialisieren und erstellen Sie den Terraform-Plan:
```
terraform init
```
Überprüfen Sie die Konfiguration und nehmen Sie bei Bedarf Änderungen vor:
```
terraform plan
```
Wenden Sie den Terraform-Plan an, um den Nutzercluster zu erstellen:
```
terraform apply
```

Administratorcluster aktualisieren

Nachdem Sie ein Upgrade Ihrer Nutzercluster durchgeführt haben, können Sie Ihren Administratorcluster upgraden.

Hinweis

Ermitteln Sie, ob Ihre Zertifikate auf dem neuesten Stand sind, und verlängern Sie sie bei Bedarf.
Wenn Sie ein Upgrade auf Version 1.13 oder höher ausführen, müssen Sie zuerst den Administratorcluster registrieren. Füllen Sie dazu den Abschnitt gkeConnect in der Konfigurationsdatei des Administratorclusters aus. Führen Sie den Befehl gkectl update cluster mit den Änderungen an der Konfigurationsdatei aus.
Prüfen Sie, ob gkectl und Cluster die geeignete Version für ein Upgrade haben und dass Sie das entsprechende Bundle heruntergeladen haben. Die Versionsverzerrung zwischen Ihren Administrator- und Nutzerclustern hängt von der Google Distributed Cloud-Version ab. Informationen dazu, ob Sie Ihren Administratorcluster upgraden können, finden Sie unter Versionsabweichungen zwischen Administrator- und Nutzerclustern.
Achten Sie darauf, dass das Feld bundlepath in der Konfigurationsdatei des Administratorclusters mit dem Pfad des Bundles übereinstimmt, auf das Sie ein Upgrade ausführen möchten.

Wenn Sie andere Änderungen an den Feldern in der Konfigurationsdatei des Administratorclusters vornehmen, werden diese während des Upgrades ignoriert. Damit diese Änderungen wirksam werden, müssen Sie zuerst den Cluster aktualisieren und dann den Befehl update cluster mit den Änderungen an der Konfigurationsdatei ausführen, um andere Änderungen am Cluster vorzunehmen.

Führen Sie `gkectl upgrade admin` aus

Führen Sie die Schritte in diesem Abschnitt auf Ihrer neuen Administrator-Workstation aus. Es gibt zwei Varianten des Befehls gkectl upgrade admin:

Asynchron:
. Bei der asynchronen Variante startet der Befehl das Upgrade und wird dann abgeschlossen. Sie müssen die Ausgabe des Befehls nicht während der gesamten Dauer des Upgrades beobachten. Stattdessen können Sie den Fortschritt des Upgrades regelmäßig überprüfen, indem Sie gkectl list admin und gkectl describe admin ausführen. Um die asynchrone Variante zu verwenden, fügen Sie das Flag --async in den Befehl ein.

Anforderungen für das asynchrone Upgrade:
- Wird nur für Hochverfügbarkeits-Administratorcluster ab Version 1.29 unterstützt.
- Für alle Nutzercluster muss Steuerungsebene V2 aktiviert sein.
Synchron:
Bei der synchronen Variante gibt der Befehl gkectl upgrade admin während des Upgrades Statusmeldungen an die Administrator-Workstation aus.

Asynchrones Upgrade

Starten Sie auf Ihrer Administrator-Workstation ein asynchrones Upgrade:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    --async \
    FLAGS
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
- ADMIN_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Administratorclusters.
- FLAGS: ein optionaler Satz Flags. Sie können beispielsweise das Flag --skip-validation-infra einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.
Der vorherige Befehl wird abgeschlossen und Sie können die Administrator-Workstation während des Upgrades weiter verwenden.
So rufen Sie den Status der Umstellung ab:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Die Ausgabe zeigt einen Wert für den Cluster STATE. Wenn für den Cluster noch ein Upgrade durchgeführt wird, lautet der Wert von STATE UPGRADING. Beispiel:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.29.100-gke.248
```
Die möglichen Werte für STATE sind RUNNING, UPGRADING, RECONCILING, ERROR und UNKNOWN.

So erhalten Sie weitere Informationen zum Upgradefortschritt und zu Clusterereignissen:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe zeigt die benutzerdefinierte OnPremAdminCluster-Ressource für den angegebenen Administratorcluster, die Clusterstatus, Bedingungen und Ereignisse enthält.

Wir zeichnen Ereignisse zu Beginn und am Ende jeder kritischen Upgradephase auf.

Beispielausgabe:

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

Wenn das Upgrade abgeschlossen ist, zeigt gkectl list admin eine STATUS von RUNNING an:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.29.100-gke.248
```
Wenn das Upgrade abgeschlossen ist, zeigt gkectl describe admin außerdem unter Status das Feld Last GKE On Prem Version an. Beispiel:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.29.0-gke.1
```

Fehlerbehebung beim asynchronen Upgrade

Bei einem asynchronen Upgrade basiert die Zeitüberschreitungsdauer auf der Anzahl der Knoten im Cluster. Wenn das Upgrade länger dauert als das Zeitlimit, wird der Clusterstatus von UPGRADING in ERROR geändert. Dabei wird ein Ereignis angezeigt, das eine Zeitüberschreitung beim Upgradevorgang angibt. Der Status ERROR bedeutet hier, dass das Upgrade länger als erwartet dauert, aber nicht beendet wurde. Der Controller fährt den Abgleich fort und wiederholt den Vorgang. Wenn ein Upgrade blockiert ist oder fehlschlägt, können Sie gkectl diagnose ausführen, um nach häufigen Clusterproblemen zu suchen. Auf der Grundlage des Ergebnisses können Sie entscheiden, ob Sie eine manuelle Korrektur vornehmen oder sich an den Google Cloud-Support wenden möchten, um weitere Unterstützung zu erhalten.

Synchrones Upgrade

Führen Sie dazu diesen Befehl aus:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters
- ADMIN_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Administratorclusters.
- FLAGS: ein optionaler Satz Flags. Sie können beispielsweise das Flag --skip-validation-infra einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.
Mit dem Befehl gkectl upgrade werden Preflight-Prüfungen ausgeführt. Wenn die Preflight-Prüfungen fehlschlagen, wird der Befehl blockiert. Sie müssen die Fehler beheben oder das Flag --skip-preflight-check-blocking mit dem Befehl verwenden, um die Blockierung aufzuheben.
Wenn Sie ein Upgrade auf Version 1.14.0 oder höher ausführen, wird für den Administratorcluster eine neue kubeconfig-Datei generiert, die alle vorhandenen Dateien überschreibt. Führen Sie den folgenden Befehl aus, um Clusterdetails in der Datei anzusehen:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Vollständiges Set entfernen

Wenn Sie ein vollständiges Bundle heruntergeladen und die Befehle gkectl prepare und gkectl upgrade admin erfolgreich ausgeführt haben, sollten Sie das gesamte Bundle löschen, um Speicherplatz auf der Administrator-Workstation zu sparen. Führen Sie den folgenden Befehl aus, um das vollständige Bundle zu löschen:

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

Upgrade eines Administratorclusters fortsetzen

Wenn das Upgrade eines Administratorclusters unterbrochen wird oder fehlschlägt, kann das Upgrade fortgesetzt werden, falls der Prüfpunkt des Administratorclusters den Status enthält, der zur Wiederherstellung des Zustands vor der Unterbrechung erforderlich ist.

Warnung: Reparieren Sie den Administrator-Master nach einem fehlgeschlagenen Upgradeversuch nicht mit gkectl repair admin-master. Dies führt dazu, dass der Administratorcluster in einen fehlerhaften Zustand versetzt wird.

Gehen Sie so vor:

Prüfen Sie, ob die Administratorsteuerungsebene fehlerfrei ist, bevor Sie mit dem ersten Upgradeversuch beginnen. Siehe Clusterprobleme diagnostizieren. Führen Sie wie in diesem Thema beschrieben den Befehl gkectl diagnose cluster für den Administratorcluster aus.
Wenn die Administratorsteuerungsebene vor dem ersten Upgradefehler fehlerhaft ist, reparieren Sie die Administratorsteuerungsebene mit dem Befehl gkectl repair admin-master.
Wenn Sie den Upgradebefehl noch einmal ausführen, nachdem ein Upgrade unterbrochen wurde oder fehlgeschlagen ist, verwenden Sie dasselbe Bundle und dieselbe Zielversion wie beim vorherigen Upgradeversuch.

Wenn Sie den Upgradebefehl noch einmal ausführen, wird der Status des Administratorclusters vom Prüfpunkt aus neu erstellt und das gesamte Upgrade wird noch einmal ausgeführt. Wenn ab Version 1.12.0 die Administrator-Steuerungsebene fehlerhaft ist, wird der Upgradeprozess direkt auf die Zielversion aktualisiert, ohne zu versuchen, den Administratorcluster in der Quellversion wiederherzustellen, bevor mit dem Upgrade fortgefahren wird.

Das Upgrade wird ab dem Punkt fortgesetzt, an dem es fehlgeschlagen ist oder beendet wurde, sofern der Prüfpunkt des Administratorclusters verfügbar ist. Wenn der Prüfpunkt nicht verfügbar ist, greift das Upgrade auf die Administratorsteuerungsebene zurück. Daher muss die Administratorsteuerungsebene fehlerfrei sein, um mit dem Upgrade fortfahren zu können. Nach einem erfolgreichen Upgrade wird der Prüfpunkt neu generiert.

Wenn gkectl während eines Upgrade des Administratorclusters unerwartet beendet wird, wird der Typcluster nicht bereinigt. Bevor Sie den Upgradebefehl noch einmal ausführen, um das Upgrade fortzusetzen, löschen Sie den Typcluster:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Führen Sie nach dem Löschen des Typclusters den Upgradebefehl noch einmal aus.

Rollback einer Administrator-Workstation nach einem Upgrade

Sie können die Administrator-Workstation auf die Version zurücksetzen, die vor dem Upgrade verwendet wurde.

Während des Upgrades erfasst gkeadm die vor dem Upgrade verwendete Version in der Ausgabeinformationsdatei. Während des Rollbacks verwendet gkeadm die aufgelistete Version, um die ältere Datei herunterzuladen.

So führen Sie ein Rollback Ihrer Administrator-Workstation auf die vorherige Version durch:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Sie können --config=AW_CONFIG_FILE weglassen, wenn die Konfigurationsdatei der Administrator-Workstation der Standard-admin-ws-config.yaml ist. Andernfalls ersetzen Sie AW_CONFIG_FILE durch den Pfad zur Konfigurationsdatei der Administrator-Workstation.

Der Rollback-Befehl führt folgende Schritte aus:

Die Rollback-Version von gkeadm wird heruntergeladen.
Sie sichert das Basisverzeichnis der aktuellen Administrator-Workstation.
Erstellt eine neue Administrator-Workstation mit der Rollback-Version von gkeadm.
Löscht die ursprüngliche Administrator-Workstation.

Bundle mit einer anderen Version für das Upgrade installieren

Wenn Sie ein Upgrade Ihrer Workstation durchführen, wird dort ein Bundle mit einer entsprechenden Version installiert. Wenn Sie eine andere Version verwenden möchten, führen Sie die folgenden Schritte aus, um ein Bundle für TARGET_VERSION zu installieren. Dies ist die Version, auf die Sie ein Upgrade ausführen möchten.

Führen Sie den folgenden Befehl aus, um die aktuelle gkectl und die Clusterversionen zu prüfen. Mit dem Flag --details/-d erhalten Sie genauere Informationen.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
Die Ausgabe enthält Informationen zu Ihren Clusterversionen.
Prüfen Sie anhand der ausgegebenen Ausgabe, ob folgende Probleme vorliegen, und beheben Sie sie gegebenenfalls.
- Wenn die aktuelle Version des Administratorclusters um mehr als eine Nebenversion tiefer als die TARGET_VERSION ist, aktualisieren Sie alle Cluster auf genau eine Nebenversion tiefer als TARGET_VERSION.
- Wenn die gkectl-Version niedriger als 1.11 ist und Sie ein Upgrade auf 1.12.x durchführen möchten, müssen Sie mehrere Upgrades ausführen. Upgraden Sie jeweils eine Nebenversion auf einmal bis Sie zu 1.11.x gelangen und fahren Sie dann mit der Anleitung in diesem Thema fort.
- Wenn die gkectl-Version niedriger als TARGET_VERSION ist, aktualisieren Sie die Administrator-Workstation auf TARGET_VERSION.
Wenn Sie festgestellt haben, dass die gkectl- und Clusterversionen für ein Upgrade geeignet sind, laden Sie das Bundle herunter.

Prüfen Sie, ob das Bundle-Tarball bereits auf der Administrator-Workstation vorhanden ist.
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
Wenn sich das Bundle nicht auf der Administrator-Workstation befindet, laden Sie es herunter.
```
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
Installieren Sie das Bundle.
```
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad Ihrer kubeconfig-Datei. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet und den Namen kubeconfig hat.

Hinweis: Standardmäßig wird das reguläre Bundle und nicht das gesamte Bundle heruntergeladen. Das vollständige Bundle enthält alle Container- und VM-Images. Das reguläre Bundle lädt während der Installation die Container- und VM-Images von der Google Cloud Platform auf die Administrator-Workstation herunter. Wenn Sie stattdessen das vollständige Bundle verwenden möchten, lautet der Installationspfad im Installationsbefehl gke-onprem-vsphere-TARGET_VERSION-full.tgz.
Listen Sie die verfügbaren Clusterversionen auf und prüfen Sie, ob die Zielversion in den verfügbaren Nutzerclusterversionen enthalten ist.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

Sie können jetzt einen Nutzercluster in der Zielversion erstellen oder einen Nutzercluster auf die Zielversion aktualisieren.

Fehlerbehebung beim Upgrade

Sollten bei der empfohlenen Umstellung Probleme auftreten, beachten Sie bitte diese Empfehlungen, um sie zu beheben. Diese Vorschläge setzen voraus, dass Sie mit der Version 1.11.x.-Einrichtung begonnen haben und das empfohlene Upgrade-Verfahren durchlaufen.

Siehe auch Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Fehlerbehebung bei Problemen mit dem Nutzercluster-Upgrade

Angenommen, Sie finden beim Upgraden eines Nutzerclusters ein Problem mit der Upgradeversion. Sie stellen fest, dass das Problem in einer zukünftigen Patchversion behoben wird. Gehen Sie dazu so vor:

Für die Produktion verwenden Sie weiterhin die aktuelle Version.
Testen Sie den Patchrelease in einem Nicht-Produktionscluster, wenn er veröffentlicht wird.
Aktualisieren Sie alle Produktionsnutzercluster auf die Patchrelease-Version, wenn Sie sicher sind.
Aktualisieren Sie den Administratorcluster auf die Patchrelease-Version.

Fehlerbehebung bei Problemen mit dem Upgrade eines Administratorclusters

Wenn beim Upgrade des Administratorclusters ein Problem auftritt, wenden Sie sich bitte an den Google-Support, um das Problem mit dem Administratorcluster zu beheben.

Mit dem neuen Upgrade-Ablauf können Sie weiterhin von neuen Nutzerclusterfunktionen profitieren, ohne von der Aktualisierung des Administratorclusters zu profitieren. So können Sie die Upgradehäufigkeit des Administratorclusters bei Bedarf verringern. Das Upgrade kann so ausgeführt werden:

Führen Sie ein Upgrade der Produktionsnutzercluster auf 1.12.x durch.
Behalten Sie die frühere Version des Administratorclusters bei und erhalten Sie weiterhin Sicherheitspatches.
Testen Sie das Upgrade des Administratorclusters in einer Testumgebung von 1.11.x auf 1.12.x und melden Sie Probleme, falls vorhanden.
Wenn das Problem durch eine Patch-Version 1.12.x behoben wurde, können Sie den Produktions-Administratorcluster auf diese Patch-Version aktualisieren, falls gewünscht.

Bekannte Probleme bei aktuellen Versionen

Die folgenden bekannten Probleme können Auswirkungen auf Upgrades haben, wenn Sie ein Upgrade von Version 1.7 oder höher ausführen.

Weitere Informationen finden Sie im Hilfeartikel Bekannte Probleme.

Das Upgrade der Administrator-Workstation kann fehlschlagen, wenn das Datenlaufwerk fast voll ist

Wenn Sie die Administrator-Workstation mit dem Befehl gkectl upgrade admin-workstation aktualisieren, schlägt das Upgrade möglicherweise fehl, wenn das Datenlaufwerk fast voll ist. Dies liegt daran, dass das System versucht, die aktuelle Administrator-Workstation lokal zu sichern, während ein Upgrade auf eine neue Administrator-Workstation durchgeführt wird. Wenn Sie nicht genügend Speicherplatz auf dem Datenlaufwerk löschen können, verwenden Sie den Befehl gkectl upgrade admin-workstation mit dem zusätzlichen Flag --backup-to-local=false, um eine lokale Sicherung der aktuellen Administrator-Workstation zu verhindern.

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

Derzeit kann das Upgrade von Clustern zu Unterbrechungen oder Ausfallzeiten bei Arbeitslasten führen, die PodDisruptionBudgets (PDBs) verwenden.

Knoten schließen ihren Upgradeprozess nicht ab

Wenn Sie PodDisruptionBudget-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment oder HorizontalPodAutoscaler, damit der Knoten unter Berücksichtigung der PodDisruptionBudget-Konfiguration entleert wird.

So rufen Sie alle PodDisruptionBudget-Objekte auf, die keine Störungen zulassen:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Anhang

Informationen zu den in Version 1.1.0-gke.6 aktivierten DRS-Regeln von VMware

Ab Version 1.1.0-gke.6 erstellt GKE on VMware automatisch die DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) für die Knoten Ihres Nutzerclusters, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden. Ab Version 1.1.0-gke.6 wird diese Funktion automatisch für neue und vorhandene Cluster aktiviert.

Prüfen Sie vor dem Upgrade, ob Ihre vSphere-Umgebung die folgenden Bedingungen erfüllt:

VMware DRS ist aktiviert. Für VMware DRS ist die vplaner Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter VMware DRS in einem Cluster aktivieren.
Der in der Datei mit den Anmeldedatenkonfiguration angegebene vSphere-Nutzername hat die Berechtigung Host.Inventory.EditCluster.
Es sind mindestens drei physische Hosts verfügbar.

Wenn Ihre vSphere-Umgebung nicht die vorherigen Bedingungen erfüllt, können Sie trotzdem ein Upgrade ausführen. Wenn Sie jedoch einen Nutzercluster von 1.3.x auf 1.4.x aktualisieren möchten, müssen Sie Anti-Affinitätsgruppen deaktivieren. Weitere Informationen finden Sie in diesem bekannten Problem in den Versionshinweisen zu Google Distributed Cloud.

Informationen zu Ausfallzeiten bei Upgrades

Ressource	Beschreibung
Administratorcluster	Wenn ein Administratorcluster ausfällt, werden die Steuerungsebenen und Arbeitslasten von Nutzerclustern weiterhin ausgeführt, es sei denn, sie sind von einem Fehler betroffen, der die Ausfallzeit verursacht hat.
Nutzercluster-Steuerungsebene	Normalerweise sollten Sie keine nennenswerten Ausfallzeiten für Nutzercluster-Steuerungsebenen erwarten. Lang andauernde Verbindungen zum Kubernetes API-Server können jedoch unterbrochen werden und müssen neu hergestellt werden. In diesen Situationen sollte der API-Aufrufer noch einmal versuchen, eine Verbindung herzustellen. Im schlimmsten Fall kann es während eines Upgrades bis zu einer Minute dauern. Hinweis: Wenn Nutzercluster-Knoten während des Upgrades die Nutzersteuerungsebene nicht erreichen können, werden keine neuen Arbeitslasten für den Cluster geplant. Vorhandene Arbeitslasten sind davon nicht betroffen.
Nutzerclusterknoten	Wenn für ein Upgrade eine Änderung an Nutzerclusterknoten erforderlich ist, erstellt GKE on VMware die Knoten rollierend neu und plant die auf diesen Knoten ausgeführten Pods neu. Sie können Auswirkungen auf Ihre Arbeitslasten verhindern, wenn Sie die entsprechenden PodDisruptionBudgets und Anti-Affinitätsregeln konfigurieren.

Neuerstellung einer Informationsdatei, falls sie fehlt

Wenn die Ausgabeinformationsdatei für Ihre Administrator-Workstation fehlt, müssen Sie diese Datei neu erstellen, damit Sie mit dem Upgrade fortfahren können. Diese Datei wurde bei der anfänglichen Erstellung Ihrer Workstation erstellt. Wenn Sie seitdem ein Upgrade ausgeführt haben, wurde sie mit neuen Informationen aktualisiert.

Die Datei mit den Ausgabeinformationen hat folgendes Format:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Hier sehen Sie ein Beispiel für eine Ausgabeinformationsdatei:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Erstellen Sie die Datei in einem Editor und ersetzen Sie die entsprechenden Parameter. Speichern Sie die Datei mit einem Dateinamen, der mit dem VM-Namen in dem Verzeichnis übereinstimmt, in dem gkeadm ausgeführt wird. Wenn der VM-Name beispielsweise admin-ws-janedoe lautet, speichern Sie die Datei als admin-ws-janedoe.

Nächste Schritte

Referenzdokumentation zur gcloud CLI
Terraform-Referenzdokumentation
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Cluster oder Knotenpool upgraden

Firewallregeln überprüfen

Google API- und IAM-Anforderungen

IAM-Anforderungen für das Upgrade von Nutzerclustern

Konfigurationsänderungen vor oder nach einem Upgrade vornehmen

Führen Sie ein Upgrade Ihrer Administrator-Workstation durch.

gkeadm

Erforderliche Dateien suchen

Upgrade

Vom Nutzer verwaltet

Verfügbare Versionen für Clusterupgrades prüfen

Nutzercluster aktualisieren

gkectl

Upgrade eines Nutzerclusters vorbereiten

Preflight-Prüfungen ausführen

Führen Sie gkectl upgrade cluster aus

Asynchrones Upgrade

Fehlerbehebung beim asynchronen Upgrade

Synchrones Upgrade

Zusätzliche Knotenpools upgraden

Upgrade fortsetzen

Console

gcloud-CLI

Upgrade für Knotenpools durchführen

Terraform

Upgrade für Knotenpools durchführen

Administratorcluster aktualisieren

Hinweis

Führen Sie gkectl upgrade admin aus

Asynchrones Upgrade

Fehlerbehebung beim asynchronen Upgrade

Synchrones Upgrade

Vollständiges Set entfernen

Upgrade eines Administratorclusters fortsetzen

Rollback einer Administrator-Workstation nach einem Upgrade

Bundle mit einer anderen Version für das Upgrade installieren

Fehlerbehebung beim Upgrade

Fehlerbehebung bei Problemen mit dem Nutzercluster-Upgrade

Fehlerbehebung bei Problemen mit dem Upgrade eines Administratorclusters

Bekannte Probleme bei aktuellen Versionen

Das Upgrade der Administrator-Workstation kann fehlschlagen, wenn das Datenlaufwerk fast voll ist

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

Knoten schließen ihren Upgradeprozess nicht ab

Anhang

Informationen zu den in Version 1.1.0-gke.6 aktivierten DRS-Regeln von VMware

Informationen zu Ausfallzeiten bei Upgrades

Neuerstellung einer Informationsdatei, falls sie fehlt

Nächste Schritte

Führen Sie `gkectl upgrade cluster` aus

Führen Sie `gkectl upgrade admin` aus