Cluster oder Knotenpool aktualisieren

In diesem Dokument wird beschrieben, wie Sie Cluster und Knotenpools in Google Distributed Cloud (nur Software) für VMware aktualisieren. Hier finden Sie eine Anleitung zum Upgrade Ihrer Administrator-Workstation, Ihrer Nutzercluster und Ihrer Administratorcluster. Für Nutzercluster finden Sie in diesem Dokument eine Anleitung zum gleichzeitigen oder separaten Upgrade der Steuerungsebene und der Knotenpools.

Diese Seite richtet sich an IT-Administratoren und Betreiber, die den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur 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.

Bevor Sie fortfahren, empfehlen wir Ihnen, sich die folgenden Dokumente anzusehen:

• Upgrade-Übersicht
  In diesem Dokument werden unter anderem die unterstützten Versionsabweichungen und Versionsregeln für Upgrades beschrieben, die sich für Version 1.28 und höher geändert haben.

• Best Practices für Upgrades
  Dieses Dokument enthält Checklisten und Best Practices für das Upgrade von Clustern.

Firewallregeln prüfen

In Version 1.29 und später sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Für serverseitige Vorabprüfungen sind zusätzliche Firewallregeln erforderlich. Suchen Sie in den Firewallregeln für Administratorcluster nach „Preflight-Prüfungen“ und achten Sie darauf, dass alle erforderlichen Firewallregeln konfiguriert sind.

Bei serverseitigen Preflight-Prüfungen werden die Preflight-Prüfungen bei der Erstellung eines Nutzerclusters mit gkectl auf dem Administratorcluster und nicht lokal auf der Administrator-Workstation ausgeführt. Serverseitige Vorabprüfungen werden auch auf dem Administratorcluster ausgeführt, wenn Sie einen Cluster mit der Google Cloud Console, der Google Cloud CLI oder Terraform aktualisieren.

Wenn Sie einen Administratorcluster aktualisieren, wird in Google Distributed Cloud ein Kubernetes in Docker-Cluster (Art) bereitgestellt, der vorübergehend die Kubernetes-Controller hostet, die zum Aktualisieren des Administratorclusters erforderlich sind. Dieser vorübergehende Cluster wird als Bootstrap-Cluster bezeichnet. Serverseitige Preflight-Prüfungen werden auf dem Bootstrap-Cluster ausgeführt, wenn Sie einen Administratorcluster aktualisieren.

Google API- und IAM-Anforderungen

Wenn Sie einen Cluster auf Version 1.28 oder höher aktualisieren möchten, müssen Sie kubernetesmetadata.googleapis.com aktivieren und dem Logging-Monitoring-Dienstkonto die IAM-Rolle kubernetesmetadata.publisher zuweisen. Diese Änderungen sind erforderlich, um Cloud Monitoring verwenden zu können.

1. 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 in der Cluster-Konfigurationsdatei.

2. Wenn Ihre Organisation eine Zulassungsliste eingerichtet hat, mit der Traffic von Google APIs und anderen Adressen über Ihren Proxyserver geleitet werden kann, fügen Sie der Zulassungsliste kubernetesmetadata.googleapis.com hinzu.

3. Weisen Sie dem Dienstkonto für das Logging-Monitoring 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 Upgrade des Nutzerclusters verwenden möchten.

Wenn Sie einen Nutzercluster mit der Google Cloud Console, der Google Cloud CLI oder Terraform aktualisieren möchten und kein Projektinhaber sind, müssen Sie die Rolle „Identity and Access Management“ roles/gkeonprem.admin für das Google Cloud-Projekt haben, in dem der Cluster erstellt wurde. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie in der IAM-Dokumentation unter GKE On-Prem-Rollen.

Wenn Sie den Cluster mit der Console aktualisieren möchten, benötigen Sie außerdem mindestens Folgendes:

• roles/container.viewer. Mit dieser Rolle können Nutzer die GKE-Clusterseite und andere Containerressourcen in der Console aufrufen. Ausführliche Informationen zu den in dieser Rolle enthaltenen Berechtigungen und zum Zuweisen einer Rolle mit Lese-/Schreibberechtigungen finden Sie in der IAM-Dokumentation unter Kubernetes Engine-Rollen.

• roles/gkehub.viewer Mit dieser Rolle können Nutzer Cluster in der Console aufrufen. Ausführliche Informationen zu den in dieser Rolle enthaltenen Berechtigungen und 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 das Cluster-Update entweder vor oder nach dem Upgrade aus. Die einzige Änderung an der Clusterkonfiguration für ein Upgrade sollte die Version sein. Je nach Clusterversion und -typ werden andere Konfigurationsänderungen entweder stillschweigend ignoriert oder führen zum Abbruch des Upgrades. Weitere Informationen finden Sie unter Nicht unterstützte Änderungen entfernen, um ein Upgrade zu ermöglichen.

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

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

Wenn Sie einen Nutzercluster mit der Console, der gcloud CLI oder Terraform aktualisieren möchten, können Sie das Upgrade der Administrator-Workstation vorerst überspringen. Sie müssen die Administrator-Workstation jedoch aktualisieren, wenn Sie bereit sind, das Upgrade des Administratorclusters durchzuführen, da nur gkectl Administratorcluster-Upgrades unterstützt.

Wie Sie Ihre Administrator-Workstation aktualisieren, hängt davon ab, wie Sie sie erstellt haben: mit gkeadm oder vom Nutzer verwaltet.

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

gcloud storage 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 ein Upgrade verfügbar sind:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe enthält die aktuelle Version und die Versionen, die für ein Upgrade verfügbar sind.

Wenn Sie die Console, die gcloud CLI oder Terraform für das Upgrade verwenden möchten, dauert es nach einer Veröffentlichung etwa 7 bis 10 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 Upgrade des Nutzerclusters aufgeführt. Beim Upgrade eines Nutzerclusters mit der gcloud CLI oder Terraform müssen Sie gcloud container vmware clusters query-version-config ausführen, um die verfügbaren Versionen für das Upgrade abzurufen.

Nutzercluster aktualisieren

Sie können gkectl, die Console, die gcloud CLI oder Terraform verwenden, um einen Nutzercluster zu aktualisieren. Informationen zur Auswahl des Tools finden Sie unter Tool zum Upgrade von Nutzerclustern auswählen.

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

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

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

Administratorcluster aktualisieren

Nachdem Sie Ihre Nutzercluster aktualisiert haben, können Sie Ihren Administratorcluster aktualisieren.

Hinweise:

1. Wenn Sie auf Version 1.13 oder höher aktualisieren, 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.

2. Achten Sie darauf, dass gkectl und Ihre Cluster in der richtigen Version für ein Upgrade gespeichert sind und dass Sie das entsprechende Bundle heruntergeladen haben. Die Versionsabweichung zwischen Ihren Administrator- und Nutzerclustern hängt von der Google Distributed Cloud-Version ab. Informationen dazu, ob Sie Ihren Administratorcluster aktualisieren können, finden Sie unter Abweichungen bei der Version des Administrator- und Nutzerclusters.

3. Achten Sie darauf, dass das Feld bundlepath in der Konfigurationsdatei für den Administratorcluster mit dem Pfad des Bundles übereinstimmt, auf das Sie aktualisieren möchten.

   Wenn Sie weitere Änderungen an den Feldern in der Konfigurationsdatei des Administratorclusters vornehmen, werden diese Änderungen während des Upgrades ignoriert. Damit diese Änderungen wirksam werden, müssen Sie zuerst den Cluster aktualisieren und dann einen Aktualisierungsbefehl mit den Änderungen 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 führt es dann aus. Sie müssen die Ausgabe des Befehls nicht während des gesamten Upgrades im Auge behalten. Stattdessen können Sie den Fortschritt des Upgrades regelmäßig prüfen, indem Sie gkectl list admin und gkectl describe admin ausführen. Wenn Sie die asynchrone Variante verwenden möchten, fügen Sie dem Befehl das Flag --async hinzu.

  Anforderungen für ein asynchrones Upgrade:

  • Unterstützt nur für HA-Administratorcluster mit Version 1.29 oder höher.
  • Bei allen Nutzerclustern muss Controlplane V2 aktiviert sein.

• Synchron:
  Bei der synchronen Variante gibt der Befehl gkectl upgrade admin während des Upgrades Statusmeldungen an die Administrator-Workstation aus.

Komplettes Bundle entfernen

Wenn Sie ein vollständiges Bundle heruntergeladen haben und die Befehle gkectl prepare und gkectl upgrade admin erfolgreich ausgeführt wurden, sollten Sie nun das vollständige Bundle löschen, um Speicherplatz auf der Administrator-Workstation zu sparen. Führen Sie den folgenden Befehl aus, um das gesamte 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 Admin-Master nach einem fehlgeschlagenen Upgradeversuch nicht mit gkectl repair admin-master. Dies führt dazu, dass der Administratorcluster in einen fehlerhaften Zustand gerät.

Gehen Sie so vor:

1. 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.

2. Wenn die Administratorsteuerungsebene vor dem ersten Upgradefehler fehlerhaft ist, reparieren Sie die Administratorsteuerungsebene mit dem Befehl gkectl repair admin-master.

3. 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, erstellt das fortgesetzte Upgrade den Status des Administratorclusters vom Prüfpunkt neu und führt das gesamte Upgrade noch einmal durch. Ab Version 1.12.0 wird bei einem fehlerhaften Zustand der Administrator-Steuerungsebene direkt auf die Zielversion umgestellt, ohne dass versucht wird, 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:

1. Die Rollback-Version von gkeadm wird heruntergeladen.
2. Sie sichert das Basisverzeichnis der aktuellen Administrator-Workstation.
3. Erstellt eine neue Administrator-Workstation mit der Rollback-Version von gkeadm.
4. 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.

1. 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.

2. 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.

3. 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.

   gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
   

4. 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.

5. 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:

1. Für die Produktion verwenden Sie weiterhin die aktuelle Version.
2. Testen Sie den Patchrelease in einem Nicht-Produktionscluster, wenn er veröffentlicht wird.
3. Aktualisieren Sie alle Produktionsnutzercluster auf die Patchrelease-Version, wenn Sie sicher sind.
4. 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:

1. Führen Sie ein Upgrade der Produktionsnutzercluster auf 1.12.x durch.
2. Behalten Sie die frühere Version des Administratorclusters bei und erhalten Sie weiterhin Sicherheitspatches.
3. Testen Sie das Upgrade des Administratorclusters in einer Testumgebung von 1.11.x auf 1.12.x und melden Sie Probleme, falls vorhanden.
4. 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 Google Distributed Cloud automatisch Anti-Affinitätsregeln des Typs Distributed Resource Scheduler (DRS) für die Knoten Ihres Nutzerclusters, sodass 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 der Google Distributed Cloud-Versionshinweise.

Informationen zu Ausfallzeiten bei Upgrades

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

• gcloud CLI-Referenzdokumentation

  • gcloud container vmware clusters
  • gcloud container vmware node-pools
  • gcloud container vmware admin-clusters

• Terraform-Referenzdokumentation

  • google_gkeonprem_vmware_cluster
  • google_gkeonprem_vmware_node_pool