Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Cluster-Upgrade durchführen

Wenn Sie Ihre Administrator-Workstation, Nutzercluster und Administratorcluster für Google Distributed Cloud (nur Software) für VMware aktualisieren, können Sie unterstützte Kubernetes-Releases, Sicherheitspatches und Plattformfunktionen übernehmen. In diesem Dokument wird beschrieben, wie Sie die Steuerungsebene und die Knotenpools eines Nutzerclusters gemeinsam aktualisieren. Informationen zum separaten Aktualisieren finden Sie unter Knotenpools aktualisieren.

Bevor Sie beginnen, lesen Sie die Upgrade-Übersicht zur Toolauswahl und Upgrade-Reihenfolge, die Upgrade-Versionsregeln für releasespezifische Versionsabweichungen und Betriebssystemanforderungen sowie die Best Practices für Upgrades für Checklisten vor dem Upgrade.

Hinweis

Sie benötigen eine aktuelle Sicherung der Administrator- und Nutzercluster, bevor Sie mit dem Upgrade beginnen. Weitere Informationen finden Sie unter Nutzer- und Administratorcluster sichern.
Diagnostizieren Sie Ihren Cluster vor dem Upgrade. Führen Sie gkectl diagnose cluster aus, um zu prüfen, ob der Administratorcluster fehlerfrei ist, und beheben Sie alle Probleme, bevor Sie mit dem Upgrade beginnen.
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 ein Upgrade Ihres Administratorclusters durchführen können, finden Sie in den Versionsregeln für Ihre Version.
Achten Sie darauf, dass das Feld bundlepath in der Konfigurationsdatei für den Administratorcluster mit dem Pfad des Bundles übereinstimmt, auf das Sie ein Upgrade durchführen 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.

Firewallregeln prüfen

In Version 1.29 und später sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Für serverseitige Preflight-Prü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 Preflight-Prü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 ein Upgrade für einen Administratorcluster durchführen.

`stackdriver` aktivieren

Wenn Sie den Nutzercluster mit gkectl erstellt haben, muss vor dem Upgrade der Abschnitt stackdriver in der Konfigurationsdatei des Nutzerclusters ausgefüllt sein, damit stackdriver (für Logging und Monitoring erforderlich) aktiviert wird. Wenn stackdriver nicht aktiviert ist, füllen Sie den Abschnitt stackdriver in der Konfigurationsdatei des Nutzerclusters aus und aktualisieren Sie den Cluster, bevor Sie das Upgrade durchführen.

Wenn Sie den Cluster mit Terraform, der Google Cloud Console oder der gcloud CLI erstellt haben, wird stackdriver automatisch aktiviert.

Dataplane V2 aktivieren

Ab Version 1.31 muss Dataplane V2 auf allen Nutzerclustern aktiviert sein. Führen Sie vor dem Upgrade eines Nutzerclusters auf 1.31 die folgenden Schritte aus. Wenn Sie Bedenken hinsichtlich der vorübergehenden Entfernung der NetworkPolicy-Spezifikation haben, wenden Sie sich an den Google-Support.

Legen Sie in der Konfigurationsdatei für den Nutzercluster enableDataplaneV2 auf true fest.

Wenn Ihr Cluster einen NetworkPolicy verwendet, entfernen Sie die Spezifikation vorübergehend aus dem Cluster:

Prüfen Sie, ob auf Ihren Cluster ein nicht systembezogenes NetworkPolicy angewendet wurde:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
```
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Nutzercluster.

Wenn nur Standard-kube-system-Richtlinien vorhanden sind, gibt der Befehl No resources found zurück.
Wenn der vorherige Befehl NetworkPolicy-Objekte auflistet, speichern Sie jede NetworkPolicy-Spezifikation in einer Datei, damit Sie die Spezifikation nach dem Upgrade des Clusters wieder anwenden können:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Ersetzen Sie Folgendes:
- NETWORK_POLICY_NAME: der Name der NetworkPolicy, die Sie speichern.
- NETWORK_POLICY_NAMESPACE: der Namespace des NetworkPolicy.

Löschen Sie NetworkPolicy mit dem folgenden Befehl:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Fahren Sie mit dem Upgrade fort.
Wenn Sie nach dem Upgrade alle nicht systemeigenen NetworkPolicy-Spezifikationen entfernt haben, wenden Sie sie mit diesem Befehl wieder an:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Google API- und IAM-Anforderungen

Wenn Sie ein Upgrade eines Clusters 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. Diese Änderungen sind erforderlich, um Cloud Monitoring zu verwenden.

kubernetesmetadata.googleapis.com aktivieren:
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Ersetzen Sie PROJECT_ID durch die ID des Flotten-Hostprojekts, zu dem der Nutzercluster gehö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 in der Cluster-Konfigurationsdatei.
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.
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.

Legacy-Funktionen bei Upgrades blockiert

Die folgenden Legacy-Funktionen werden während des Clusterupgrades auf Version 1.32 blockiert:

Dataplane V1 (Calico)
Konfiguration des integrierten F5 Big-IP-Load-Balancers
Nicht-HA-Administratorcluster
Kubeception-Nutzercluster
Seesaw-Load-Balancer

Sie müssen Ihre Cluster zu empfohlenen Funktionen migrieren, bevor Sie ein Upgrade auf Version 1.32 durchführen.

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 ein Upgrade für einen Nutzercluster durchzuführen, und Sie kein Projektinhaber sind, muss Ihnen die Identity and Access Management-Rolle roles/gkeonprem.admin für das Google Cloud Projekt zugewiesen werden, 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 mindestens:

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.

Einschränkungen bei erweiterten Clustern

Beachten Sie die folgenden Einschränkungen, wenn Sie erweiterte Cluster aktiviert haben:

Wenn Sie Cluster von Version 1.32 auf 1.33 aktualisieren, müssen Sie gkectl verwenden. Die GKE On-Prem API-Clients (die Console, die gcloud CLI und Terraform) werden für diesen spezifischen Upgradepfad nicht unterstützt, aber für Upgrades ab Version 1.33.
Für erweiterte Cluster der Version 1.31 (Vorabversion) oder beim Konvertieren eines nicht erweiterten Administratorclusters in einen erweiterten Administratorcluster müssen Sie ein synchrones Upgrade ausführen. In Version 1.32 und höher können Sie das Flag --async mit den Befehlen gkectl upgrade admin und gkectl upgrade cluster für vorhandene erweiterte Cluster verwenden.

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 stillschweigend ignoriert oder führen dazu, dass das Upgrade fehlschlägt. Weitere Informationen finden Sie unter Nicht unterstützte Änderungen entfernen, um das Upgrade zu ermöglichen.

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

Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.

In der Ausgabe werden die aktuelle Version und die für ein Upgrade verfügbaren Versionen angezeigt.

Wenn Sie die Console, die gcloud CLI oder Terraform für das Upgrade verwenden möchten, dauert es nach einem Release etwa 7 bis 14 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. 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.

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

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

gkeadm

Erforderliche Dateien suchen

Vor dem Erstellen Ihrer Administrator-Workstation haben Sie eine Konfigurationsdatei für die Administrator-Workstation ausgefüllt, die von gkeadm create config generiert wurde. Der Standardname für diese 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. Siehe Neuerstellung einer Informationsdatei, falls sie fehlt.

Upgrade

Führen Sie ein Upgrade der Administrator-Workstation durch:

Prüfen Sie das Feld adminWorkstation.diskGB in der Konfigurationsdatei der Administrator-Workstation und achten Sie darauf, dass die angegebene Größe mindestens 100 beträgt, z. B.:
```
adminWorkstation:
  diskGB: 100
```
Für ein Upgrade auf Version 1.28 und höher sind 100 GB erforderlich. Das Clusterupgrade schlägt fehl, wenn die Administrator-Workstation nicht genügend Speicherplatz hat.
Laden Sie gkeadm von Ihrem Jump-Server herunter:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Ersetzen Sie TARGET_VERSION durch die Version, auf die Sie ein Upgrade ausführen. Sie müssen eine vollständige Versionsnummer im Format X.Y.Z-gke.N angeben. Eine Liste der Google Distributed Cloud-Versionen finden Sie unter Versionsverwaltung.

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

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

gkectl herunterladen:
```
 gcloud storage cp gs://gke-on-prem-release/gkectl/TARGET_VERSION/gkectl ./
 chmod +x gkectl
 
```
Ersetzen Sie TARGET_VERSION durch die Version, auf die Sie ein Upgrade ausführen möchten. Sie müssen eine vollständige Versionsnummer im Format X.Y.Z-gke.N angeben. Eine Liste der Google Distributed Cloud-Versionen finden Sie unter Versionsverwaltung.
Laden Sie das Google Distributed Cloud-Bundle herunter. Achten Sie darauf, dass die Version mit der Version übereinstimmt, die Sie zum Herunterladen von gkectl verwendet haben:
```
 gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz ./
 
```

Administratorcluster aktualisieren

Die Schritte zum Upgrade des Administratorclusters variieren je nach Nebenversion, auf die Sie ein Upgrade durchführen (Zielversion):

1.31 und höher

Wenn die Zielversion 1.31 oder höher ist, müssen Sie Ihren Administratorcluster aktualisieren, bevor Sie Ihre Nutzercluster auf die nächste Nebenversion aktualisieren. Ab Version 1.31 muss die Version des Administratorclusters, einschließlich der Patchversion, mindestens der Version des Nutzerclusters entsprechen. Wenn ein Administratorcluster beispielsweise die Version 1.31.1 hat, ist die höchste Version, auf die der Nutzercluster aktualisiert werden kann, 1.31.1.

Führen Sie den folgenden Befehl auf Ihrer Administrator-Workstation 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

Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.

1.30 und niedriger

Wenn die Zielversion 1.30 oder niedriger ist, müssen Sie alle Nutzercluster aktualisieren, bevor Sie den Administratorcluster aktualisieren. Die Nebenversion des Administratorclusters muss kleiner oder gleich der Nebenversion des Nutzerclusters sein. Die Patchversion spielt keine Rolle. Wenn ein Nutzercluster beispielsweise Version 1.30.1 hat, kann der Administratorcluster auf eine höhere Patch-Version wie 1.30.3 aktualisiert werden.

Führen Sie das Upgrade aus

gkectl

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 des gesamten Upgrades im Auge behalten. Stattdessen können Sie den Upgrade-Fortschritt 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 das Flag --async in den Befehl ein.

Anforderungen für asynchrone Upgrades:
- Wird nur für HA-Administratorcluster ab Version 1.29 unterstützt.
- Für alle Nutzercluster muss Controlplane V2 aktiviert sein.
- Version 1.31: Wird auf erweiterten Clustern nicht unterstützt.
- Version 1.32 und höher: Verfügbar in erweiterten Clustern.
Synchron:
Bei der synchronen Variante gibt der Befehl gkectl upgrade admin während des Upgrades Statusmeldungen an die Administrator-Workstation aus.

Asynchrones Upgrade

Diagnostizieren Sie den Cluster auf Ihrer Administrator-Workstation, bevor Sie ein Upgrade durchführen:
```
gkectl diagnose cluster \
   --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Wenn der Befehl Fehler oder Warnungen meldet, lesen Sie den Abschnitt Clusterprobleme diagnostizieren und beheben Sie die Probleme, bevor Sie fortfahren.
Starten Sie ein asynchrones Upgrade:
```
gkectl upgrade admin \
   --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config ADMIN_CLUSTER_CONFIG_FILE \
   --async
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
- ADMIN_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Administratorclusters.
Der vorherige Befehl wird ausgeführt und Sie können Ihre Administrator-Workstation während des Upgrades weiter verwenden.
So rufen Sie den Status des Upgrades auf:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Die Ausgabe zeigt einen Wert für den Cluster STATE. Wenn das Upgrade des Clusters noch läuft, lautet der Wert von STATE UPGRADING. Beispiel:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.36.100-gke.144
```
Die möglichen Werte für STATE sind RUNNING, UPGRADING, RECONCILING, ERROR und UNKNOWN.

So rufen Sie weitere Informationen zum Upgradefortschritt und zu Clusterereignissen ab:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe zeigt die benutzerdefinierte OnPremAdminCluster-Ressource für den angegebenen Administratorcluster, einschließlich Clusterstatus und -bedingungen.

Klicken Sie hier, um die Beispielausgabe anzusehen

Status:
 Cluster State:  RUNNING
 Conditions:
   Last Transition Time:    2026-08-10T20:22:58Z
   Message:                 Operator NodePool is ready
   Observed Generation:     2
   Reason:                  OperatorNodePoolReady
   Status:                  True
   Type:                    ControlPlaneReady
   Last Transition Time:    2026-08-10T20:22:59Z
   Message:                 Cluster is running
   Observed Generation:     2
   Reason:                  ClusterRunning
   Status:                  True
   Type:                    Ready
   Last Transition Time:    2026-08-10T20:23:00Z
   Message:
   Observed Generation:     2
   Reason:                  Reconciling
   Status:                  False
   Type:                    OperatorClusterKubeProxyCleanedUp
   Last Transition Time:    2026-08-10T20:22:58Z
   Message:
   Observed Generation:     2
   Reason:                  PreflightCheckPassed
   Status:                  True
   Type:                    OperatorClusterPreflightCheckSuccessful
   Last Transition Time:    2026-08-10T15:56:50Z
   Message:
   Observed Generation:     2
   Reason:                  ProvisioningStarted
   Status:                  True
   Type:                    OperatorClusterProvisioningStarted
   Last Transition Time:    2026-08-10T15:56:50Z
   Message:
   Observed Generation:     2
   Reason:                  RemoteTrackerSetupComplete
   Status:                  True
   Type:                    OperatorClusterRemoteTrackerSetupSuccessful
   Last Transition Time:    2026-08-10T15:56:50Z
   Message:
   Observed Generation:     2
   Reason:                  Reconciling
   Status:                  False
   Type:                    OperatorClusterStalled
   Last Transition Time:    2026-08-10T15:56:50Z
   Message:
   Observed Generation:     2
   Reason:                  NotPresent
   Status:                  False
   Type:                    OperatorClusterWaitingOnPendingClusterID
   Last Transition Time:    2026-08-10T20:22:59Z
   Message:                 Operator Cluster is ready
   Observed Generation:     2
   Reason:                  OperatorClusterReady
   Status:                  True
   Type:                    OperatorClusterReady
   Last Transition Time:    2026-08-10T15:56:50Z
   Message:                 Component provisioner job is completed
   Observed Generation:     2
   Reason:                  ComponentProvisionerJobCompleted
   Status:                  True
   Type:                    ComponentProvisionerSystemProfileInstalled
   Last Transition Time:    2026-08-10T15:58:20Z
   Message:                 Component provisioner job is completed
   Observed Generation:     2
   Reason:                  ComponentProvisionerJobCompleted
   Status:                  True
   Type:                    ComponentProvisionerAdminProfileInstalled
 Gke On Prem Version:       1.36.0-gke.527
 Last Gke On Prem Version:  1.35.300-gke.87
 Management Conditions:
   Last Transition Time:  2026-08-10T15:58:20Z
   Message:               Component provisioner job is completed
   Observed Generation:   2
   Reason:                ComponentProvisionerJobCompleted
   Status:                True
   Type:                  ManagementProfilesReady
   Last Transition Time:  2026-08-10T15:56:29Z
   Message:               Component provisioner job is completed
   Observed Generation:   2
   Reason:                ComponentProvisionerJobCompleted
   Status:                True
   Type:                  ComponentProvisionerSystemManagementProfileInstalled
   Last Transition Time:  2026-08-10T15:58:20Z
   Message:               Component provisioner job is completed
   Observed Generation:   2
   Reason:                ComponentProvisionerJobCompleted
   Status:                True
   Type:                  ComponentProvisionerManagementProfileInstalled
 Operator Cluster Status:
   Control Plane Node Pool Status:
     Anthos Bare Metal Version:  1.36.0-gke.527
     Anthos Bare Metal Versions:
       1.36.0-gke.527:  3
     Conditions:
       Last Transition Time:  2026-08-10T20:18:20Z
       Observed Generation:   11
       Reason:                PreflightCheckPassed
       Status:                True
       Type:                  PreflightCheckSuccessful
       Last Transition Time:  2026-08-10T20:22:58Z
       Observed Generation:   11
       Reason:                NodepoolReady
       Status:                True
       Type:                  Ready
       Last Transition Time:  2026-08-10T20:22:22Z
       Observed Generation:   11
       Reason:                ReconciliationCompleted
       Status:                False
       Type:                  Reconciling
     Gke Versions:
       v1.36.0-gke.2800:        3
     Last Reconciliation Time:  2026-08-10T20:25:07Z
     Maintenance Nodes:         0
     Managed Fields:
       Label Keys:
         kubernetes.googleapis.com/cluster-name
         node.kubernetes.io/control-plane
         node.kubernetes.io/master
       Node Label Keys:
         vsphere://abcdef-1:
           onprem.gke.io/failure-domain-name
           vmware.cluster.gke.io/machine-name
         vsphere://abcdef-2:
           onprem.gke.io/failure-domain-name
           vmware.cluster.gke.io/machine-name
         vsphere://abcdef-3:
           onprem.gke.io/failure-domain-name
           vmware.cluster.gke.io/machine-name
       Taints:
         Effect:         PreferNoSchedule
         Key:            node-role.kubernetes.io/control-plane
     Ready Nodes:        3
     Ready Timestamp:    2026-08-10T15:54:01Z
     Reconciling Nodes:  0
     Stalled Nodes:      0
     Unknown Nodes:      0
   Data Plane Load Balancer Status:
     Conditions:
       Last Transition Time:  2026-08-10T15:39:16Z
       Observed Generation:   1
       Reason:                ReconciliationCompleted
       Status:                False
       Type:                  Reconciling
     Node Pool Location:      control-plane-nodepool
   External Manifests Conditions:
     Last Transition Time:  2026-08-10T15:56:32Z
     Observed Generation:   2
     Reason:                ReconciliationCompleted
     Status:                False
     Type:                  Reconciling
   Gke Connect Conditions:
     Last Transition Time:  2026-08-10T20:13:39Z
     Observed Generation:   2
     Reason:                AnthosBareMetalVersion
     Status:                True
     Type:                  1.36.0-gke.527
     Last Transition Time:  2026-08-10T20:13:39Z
     Observed Generation:   2
     Reason:                ReconciliationCompleted
     Status:                False
     Type:                  Reconciling
   Gke Connect Dependent System Service Conditions:
     Last Transition Time:  2026-08-10T15:56:32Z
     Observed Generation:   2
     Reason:                ReconciliationCompleted
     Status:                False
     Type:                  Reconciling
   Gke Hub Registration Status:
     Membership:
       Description:  description
       Name:         name
   Gke Versions:
     v1.36.0-gke.2800:  3
   Kernel Version Conditions:
     Last Transition Time:  2026-08-10T15:39:23Z
     Reason:                kernelVersionCheckPassed
     Status:                True
     Type:                  kernelVersionCheckSuccessful
   System Service Conditions:
     Last Transition Time:  2026-08-10T20:12:26Z
     Observed Generation:   2
     Reason:                ReconciliationCompleted
     Status:                False
     Type:                  Reconciling

Wenn das Upgrade abgeschlossen ist, wird für gkectl list admin der STATE RUNNING angezeigt:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.36.100-gke.144
```
Wenn das Upgrade abgeschlossen ist, wird in gkectl describe admin außerdem ein Last GKE On Prem Version-Feld unter Status angezeigt. Beispiel:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.36.0-gke.1
```

Fehlerbehebung bei asynchronen Upgrades

Bei einem asynchronen Upgrade hängt die Zeitlimitdauer von der Anzahl der Knoten im Cluster ab. Wenn das Upgrade länger als die Zeitüberschreitung dauert, wird der Clusterstatus von UPGRADING in ERROR geändert. Es wird ein Ereignis ausgegeben, in dem steht, dass der Upgradevorgang abgelaufen ist. Der Status ERROR bedeutet hier, dass das Upgrade länger als erwartet dauert, aber nicht beendet wurde. Der Controller setzt den Abgleich fort und wiederholt den Vorgang. Wenn ein Upgrade blockiert wird oder fehlschlägt, können Sie gkectl diagnose ausführen, um nach häufigen Clusterproblemen zu suchen. Anhand des Ergebnisses können Sie entscheiden, ob Sie Fehler manuell beheben oder sich an den Google Cloud -Support wenden möchten, um weitere Unterstützung zu erhalten.

Synchrones Upgrade

Diagnostizieren Sie den Cluster auf Ihrer Administrator-Workstation, bevor Sie ein Upgrade durchführen:
```
gkectl diagnose cluster \
   --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Wenn der Befehl Fehler oder Warnungen meldet, lesen Sie den Abschnitt Clusterprobleme diagnostizieren und beheben Sie die Probleme, bevor Sie fortfahren.
Administratorcluster aktualisieren.
```
gkectl upgrade admin \
   --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config ADMIN_CLUSTER_CONFIG_FILE
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.
- ADMIN_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Administratorclusters.
Mit dem Befehl gkectl upgrade werden Preflight-Prüfungen ausgeführt. Wenn die Preflight-Prüfungen fehlschlagen, wird der Befehl blockiert. Korrigieren Sie die Fehler oder verwenden Sie das Flag --skip-preflight-check-blocking mit dem Befehl, um die Blockierung aufzuheben.
Wenn Sie auf Version 1.14.0 oder höher aktualisieren, wird eine neue kubeconfig-Datei für den Administratorcluster generiert, die alle vorhandenen Dateien überschreibt. Führen Sie den folgenden Befehl aus, um die Clusterdetails in der Datei aufzurufen:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

gcloud-CLI

Aktualisieren Sie den Administratorcluster mithilfe der gcloud CLI.

Aktualisieren Sie die Plattformversion auf die Zielversion:
```
gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --location=REGION \
    --required-platform-version=VERSION \
    --async
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_NAME: der Name Ihres Administratorclusters.
- REGION: die Google Cloud -Region, in der der Administratorcluster verwaltet wird.
- VERSION: die Zielversion, auf die Sie ein Upgrade ausführen.
Dieser Befehl gibt eine Vorgangs-ID zurück. Sie können den Fortschritt mit gcloud container vmware operations describe überwachen.
Nachdem Sie die Plattformversion aktualisiert haben, aktualisieren Sie die Version des Administratorclusters:
```
gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --location=REGION \
    --version=VERSION \
    --async
```
Mit diesem Schritt wird das Upgrade des Administratorclusters auf die Zielversion abgeschlossen.

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 Clustern auswählen.

Console

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

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

So führen Sie ein Upgrade für einen Nutzercluster durch:

Rufen Sie in der Console die Seite Google Kubernetes Engine-Cluster – Übersicht auf.

Zu GKE-Clustern
Wählen Sie das Projekt Google Cloud und dann den Cluster aus, den Sie aktualisieren möchten.
Klicken Sie im Bereich Details auf Weitere Details.
Klicken Sie im Abschnitt Clustergrundlagen auf Upgrade.
Wählen Sie in der Liste Zielversion auswählen die Version aus, auf die Sie upgraden möchten. Die kuratierte Liste enthält nur die neuesten Patch-Releases.
Klicken Sie auf Upgrade.

Vor dem Upgrade des Clusters werden Preflight-Prüfungen ausgeführt, um den Cluster- und den Knotenstatus zu validieren. Sind die Preflight-Prüfungen erfolgreich, wird der Administratorcluster aktualisiert. Das Upgrade dauert etwa 30 Minuten.

Klicken Sie auf dem Tab Clusterdetails auf Details ansehen, um den Status der Aktualisierung anzuzeigen.

gcloud-CLI

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

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

So führen Sie ein Upgrade für einen Nutzercluster durch:

Aktualisieren Sie die Google Cloud CLI-Komponenten:
```
gcloud components update
```

Rufen Sie eine Liste der verfügbaren Versionen auf, auf die ein Upgrade möglich ist:

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 Nachricht nach der Liste der Versionen ignorieren. Es spielt keine Rolle, ob die Version, die Sie aktualisieren, auf dem Administratorcluster installiert ist. Mit dem Befehl upgrade wird ein Paket der Komponenten heruntergeladen und bereitgestellt, das der Version entspricht, die Sie im Befehl upgrade angeben.

Aktualisieren Sie den Cluster.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Ersetzen Sie VERSION durch die Version von Google Distributed Cloud, auf die Sie aktualisieren möchten. Geben Sie eine Version aus der Ausgabe des vorherigen Befehls an. Wir empfehlen, ein Upgrade auf die aktuelle Patch-Version durchzuführen.

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 der 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
```

gkectl

Upgrade eines Nutzerclusters vorbereiten

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

Prüfen Sie, ob der Nutzercluster fehlerfrei ist, bevor Sie mit dem ersten Upgradeversuch beginnen. Siehe Clusterprobleme diagnostizieren. Führen Sie gkectl diagnose cluster auf dem Nutzercluster aus und beheben Sie alle Probleme.
Führen Sie diesen Schritt nur aus, wenn die TARGET_VERSION-Version 1.30 oder niedriger ist oder wenn Sie ein Upgrade des Nutzerclusters auf eine andere Version als die des Administratorclusters durchführen. 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 Ihr Cluster einen Windows-Knotenpool hat, führen Sie gkectl prepare windows aus und aktualisieren Sie das Feld osImage für den Knotenpool. Eine detaillierte Anleitung finden Sie unter Nutzercluster mit Windows-Knotenpools aktualisieren.
Legen Sie in der Konfigurationsdatei des Nutzerclusters gkeOnPremVersion auf die Zielversion des Upgrades fest.

Preflight-Prüfungen ausführen

Wenn Sie ein Upgrade auf Version 1.29 oder höher ausführen, können Sie die Preflight-Prüfungen vor dem Upgrade eines Nutzerclusters ausführen:

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

Ersetzen Sie USER_CLUSTER_CONFIG durch den Pfad zur Konfigurationsdatei des Nutzerclusters.

Mit dem Flag --dry-run führt gkectl upgrade cluster die Preflight-Prüfungen aus, startet aber nicht den Upgradeprozess. In früheren Versionen von Google Distributed Cloud werden zwar Preflight-Prüfungen ausgeführt, diese können jedoch nicht unabhängig vom Upgrade ausgeführt werden. Wenn Sie das Flag --dry-run hinzufügen, können Sie alle Probleme ermitteln und beheben, die bei den Preflight-Prüfungen mit Ihrem Nutzercluster vor dem Upgrade festgestellt werden.

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 des gesamten Upgrades im Auge behalten. Stattdessen können Sie den Upgrade-Fortschritt regelmäßig prüfen, indem Sie gkectl list clusters und gkectl describe clusters ausführen. Wenn Sie die asynchrone Variante verwenden möchten, fügen Sie das Flag --async in den Befehl ein.
- Version 1.31: Nicht für erweiterte Cluster verfügbar.
- Version 1.32 und höher: Verfügbar in erweiterten Clustern.
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 auf eine Version aktualisieren, die höher als 1.16 ist.

Wenn Sie vorbereitete Anmeldedaten und eine private Registry für den Nutzercluster verwenden, müssen Sie die Anmeldedaten für die private Registry vorbereiten, bevor Sie den Nutzercluster aktualisieren. Informationen zum Vorbereiten der Anmeldedaten für die private Registry finden Sie unter Vorbereitete Anmeldedaten für Nutzercluster konfigurieren.
Führen Sie eine Diagnose Ihres Clusters durch, um sicherzustellen, dass er fehlerfrei ist:
```
gkectl diagnose cluster \
    --kubeconfig <var>ADMIN_CLUSTER_KUBECONFIG</var>
```
Wenn der Befehl Fehler oder Warnungen meldet, lesen Sie den Abschnitt Clusterprobleme diagnostizieren und beheben Sie die Probleme, bevor Sie fortfahren.
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 ausgeführt und Sie können Ihre Administrator-Workstation während des Upgrades weiter verwenden.
So rufen Sie den Status des Upgrades auf:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Die Ausgabe zeigt einen Wert für den Cluster STATE. Wenn das Upgrade des Clusters noch läuft, lautet der Wert von STATE UPGRADING. Beispiel:
```
NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.36.0-gke.1
```
Die möglichen Werte für STATE sind UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR und UNKNOWN.

So rufen Sie weitere Informationen zum Upgradefortschritt und zu Clusterereignissen ab:

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, einschließlich Clusterstatus, Bedingungen und Ereignissen.

Klicken Sie hier, um die Beispielausgabe anzusehen

Status: Cluster State: RUNNING Conditions: Last Transition Time: 2026-08-10T21:29:07Z Message: Cluster is running Observed Generation: 2 Reason: ClusterRunning Status: True Type: Ready Last Transition Time: 2026-08-10T21:12:05Z Message: Operator NodePool is ready Observed Generation: 2 Reason: OperatorNodePoolReady Status: True Type: ControlPlaneReady Last Transition Time: 2026-08-10T16:25:08Z Message: Component provisioner job is completed Observed Generation: 2 Reason: ComponentProvisionerJobCompleted Status: True Type: ComponentProvisionerUserProfileInstalled Last Transition Time: 2026-08-10T21:29:07Z Message: Node pools are running Observed Generation: 2 Reason: NodePoolsRunning Status: True Type: NodePoolsReady Last Transition Time: 2026-08-10T21:29:56Z Message: Observed Generation: 2 Reason: Reconciling Status: False Type: OperatorClusterKubeProxyCleanedUp Last Transition Time: 2026-08-10T16:27:48Z Message: Observed Generation: 2 Reason: PreflightCheckPassed Status: True Type: OperatorClusterPreflightCheckSuccessful Last Transition Time: 2026-08-10T16:27:48Z Message: Observed Generation: 2 Reason: ProvisioningStarted Status: True Type: OperatorClusterProvisioningStarted Last Transition Time: 2026-08-10T16:27:48Z Message: Observed Generation: 2 Reason: RemoteTrackerSetupComplete Status: True Type: OperatorClusterRemoteTrackerSetupSuccessful Last Transition Time: 2026-08-10T16:27:48Z Message: Observed Generation: 2 Reason: Reconciling Status: False Type: OperatorClusterStalled Last Transition Time: 2026-08-10T16:27:48Z Message: Observed Generation: 2 Reason: NotPresent Status: False Type: OperatorClusterWaitingOnPendingClusterID Last Transition Time: 2026-08-10T18:23:16Z Message: Operator Cluster is ready Observed Generation: 2 Reason: OperatorClusterReady Status: True Type: OperatorClusterReady Gke On Prem Version: 1.36.0-gke.527 Last Gke On Prem Version: 1.35.300-gke.87 Operator Cluster Status: Control Plane Node Pool Status: Anthos Bare Metal Version: 1.36.0-gke.527 Anthos Bare Metal Versions: 1.36.0-gke.527: 3 Conditions: Last Transition Time: 2026-08-10T21:07:22Z Observed Generation: 11 Reason: PreflightCheckPassed Status: True Type: PreflightCheckSuccessful Last Transition Time: 2026-08-10T21:12:05Z Observed Generation: 11 Reason: NodepoolReady Status: True Type: Ready Last Transition Time: 2026-08-10T21:11:24Z Observed Generation: 11 Reason: ReconciliationCompleted Status: False Type: Reconciling Gke Versions: v1.36.0-gke.2800: 3 Last Reconciliation Time: 2026-08-10T21:28:02Z Maintenance Nodes: 0 Managed Fields: Label Keys: node.kubernetes.io/control-plane node.kubernetes.io/master Node Label Keys: vsphere://abcdef-1: onprem.gke.io/failure-domain-name vmware.cluster.gke.io/machine-name vsphere://abcdef-2: onprem.gke.io/failure-domain-name vmware.cluster.gke.io/machine-name vsphere://abcdef-3: onprem.gke.io/failure-domain-name vmware.cluster.gke.io/machine-name Ready Nodes: 3 Ready Timestamp: 2026-08-10T16:24:02Z Reconciling Nodes: 0 Stalled Nodes: 0 Unknown Nodes: 0 Data Plane Load Balancer Status: Conditions: Last Transition Time: 2026-08-10T16:08:47Z Observed Generation: 1 Reason: ReconciliationCompleted Status: False Type: Reconciling Node Pool Location: load-balancer-nodepool External Manifests Conditions: Last Transition Time: 2026-08-10T16:12:25Z Observed Generation: 2 Reason: ReconciliationCompleted Status: False Type: Reconciling Gke Connect Conditions: Last Transition Time: 2026-08-10T21:11:33Z Observed Generation: 2 Reason: AnthosBareMetalVersion Status: True Type: 1.36.0-gke.527 Last Transition Time: 2026-08-10T21:11:33Z Observed Generation: 2 Reason: ReconciliationCompleted Status: False Type: Reconciling Gke Connect Dependent System Service Conditions: Last Transition Time: 2026-08-10T16:25:26Z Observed Generation: 2 Reason: ReconciliationCompleted Status: False Type: Reconciling Gke Hub Registration Status: Membership: Description: description Name: name Gke Versions: v1.36.0-gke.2800: 6 Kernel Version Conditions: Last Transition Time: 2026-08-10T16:08:53Z Reason: kernelVersionCheckPassed Status: True Type: kernelVersionCheckSuccessful System Service Conditions: Last Transition Time: 2026-08-10T21:04:39Z Observed Generation: 2 Reason: ReconciliationCompleted Status: False Type: Reconciling Events: Type Reason Age From Message

Normal StatusChanged 58m onprem-user-cluster-controller OnPremUserCluster status changed:

New ClusterState condition: UPGRADING Normal ControlPlaneUpgradeStarted 58m onprem-user-cluster-controller Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:43:53 +0000 UTC Normal StatusChanged 58m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:43:53 +0000 UTC Normal ControlPlaneUpgradeStarted 58m onprem-user-cluster-controller Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:43:54 +0000 UTC Normal StatusChanged 58m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:43:54 +0000 UTC Normal ControlPlaneUpgradeStarted 58m onprem-user-cluster-controller Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:44:38 +0000 UTC Normal StatusChanged 58m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:44:38 +0000 UTC Normal StatusChanged 56m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:46:33 +0000 UTC Normal StatusChanged 54m (x2 over 56m) onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePoolClaim is currently in the progress of rolling update: Condition "NodeRecreationUpdateInProgress" ready, reason: "NodeRecreationUpdateInProgress", message: "Cannot further mark old InventoryMachines for recreation due to MinReadyNodesRequired requirement. Current process: There are still old InventoryMachines: [my-uc-cp-99cc4wxzvx8ww829-2 my-uc-cp-99cc4wxzvx8ww829-1]; New ready count (0) does not match desired count (3)" Normal StatusChanged 53m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" generation 7 hasn't been observed Normal StatusChanged 53m onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateOperatorNodePool, Creating or updating operator NodePool: NodePool is not ready: Condition "Ready" status "False" is not "True", reason: "Reconciling", message: "", lastTransitionTime: 2026-08-10 20:48:58 +0000 UTC Normal StatusChanged 30m (x3 over 58m) onprem-user-cluster-controller OnPremUserCluster status changed:
New Ready condition: True, ClusterRunning, Cluster is running Normal ControlPlaneUpgradeFinished 30m (x3 over 58m) onprem-user-cluster-controller Operator NodePool is ready Normal StatusChanged 29m (x9 over 47m) onprem-user-cluster-controller (combined from similar events): OnPremUserCluster status changed:
New Ready condition: False, CreateOrUpdateNodePools, Creating or updating node pools, unready node pools: [my-uc-gke-onprem-mgmt/my-uc], in deletion node pools: [] Normal NodePoolsUpgradeStarted 29m onprem-user-cluster-controller Creating or updating node pools, unready node pools: [my-uc-gke-onprem-mgmt/my-uc], in deletion node pools: [] Normal StatusChanged 13m onprem-user-cluster-controller OnPremUserCluster status changed:
New GKEOnPremVersion: "1.36.0-gke.527"
New ClusterState condition: RUNNING
New Ready condition: True, ClusterRunning, Cluster is running

Wenn das Upgrade abgeschlossen ist, wird für gkectl list clusters der STATE RUNNING angezeigt:
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.36.0-gke.1
```
Wenn das Upgrade abgeschlossen ist, wird in gkectl describe clusters außerdem ein Last GKE On Prem Version-Feld unter Status angezeigt. Beispiel:
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.36.0-gke.1
```

Fehlerbehebung bei asynchronen Upgrades

Bei einem asynchronen Upgrade hängt die Zeitüberschreitung von der Anzahl der Knoten im Cluster ab. Wenn das Upgrade länger als die Zeitüberschreitung dauert, wird der Clusterstatus von UPGRADING in ERROR geändert. Es wird ein Ereignis ausgegeben, in dem steht, dass der Upgradevorgang abgelaufen ist. Der Status ERROR bedeutet hier, dass das Upgrade länger als erwartet dauert, aber nicht beendet wurde. Der Controller setzt den Abgleich fort und wiederholt den Vorgang.

In der Regel ist ein Zeitüberschreitungsfehler auf einen Deadlock zurückzuführen, der durch ein PodDisruptionBudget (PDB) verursacht wird. In diesem Fall können Pods nicht von alten Knoten entfernt und die alten Knoten nicht geleert werden. Wenn die Pod-Entfernung länger als 10 Minuten dauert, wird ein Ereignis in das OnPremUserCluster-Objekt geschrieben. Sie können das Ereignis mit gkectl describe clusters erfassen. Anschließend können Sie das PDB so anpassen, dass der Knoten entladen werden kann. 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 wird oder fehlschlägt, können Sie außerdem gkectl diagnose ausführen, um nach häufigen Clusterproblemen zu suchen. Anhand des Ergebnisses können Sie entscheiden, ob Sie Fehler manuell beheben oder sich an den Google Cloud -Support wenden 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. Korrigieren Sie die Fehler oder verwenden Sie das Flag --skip-preflight-check-blocking. Sie sollten die Preflight-Prüfungen nur überspringen, wenn Sie sicher sind, dass keine Fehler existieren.

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

Überspringen Sie diesen Schritt, wenn Sie auf eine Version aktualisieren, die höher als 1.16 ist.

Wenn Sie vorbereitete Anmeldedaten und eine private Registry für den Nutzercluster verwenden, müssen Sie die Anmeldedaten für die private Registry vorbereiten, bevor Sie den Nutzercluster aktualisieren. Informationen zum Vorbereiten der Anmeldedaten für die private Registry finden Sie unter Vorbereitete Anmeldedaten für Nutzercluster konfigurieren.
Führen Sie eine Diagnose Ihres Clusters durch, um sicherzustellen, dass er fehlerfrei ist:
```
gkectl diagnose cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
Wenn der Befehl Fehler oder Warnungen meldet, lesen Sie den Abschnitt Clusterprobleme diagnostizieren und beheben Sie die Probleme, bevor Sie fortfahren.

Aktualisieren Sie den Cluster:

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

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

Upgrade fortsetzen

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

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

Terraform

Aktualisieren Sie die Google Cloud CLI-Komponenten:
```
gcloud components update
```
Falls noch nicht geschehen, registrieren Sie den Administratorcluster in der GKE On-Prem API. Nachdem der Cluster in 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 auf, auf die ein Upgrade möglich ist:

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, zu dem Nutzercluster gehö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 in der Cluster-Konfigurationsdatei.
REGION: Die Google Cloud -Region, in der die GKE On-Prem API ausgeführt wird und Metadaten speichert. In der main.tf-Datei, mit der Sie den Nutzercluster erstellt 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 container 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 anschließend bereitgestellt. Mit diesen Komponenten kann der Administratorcluster Nutzercluster dieser Version verwalten.
Ändern Sie in der main.tf-Datei, mit der Sie den Nutzercluster erstellt haben, on_prem_version in der Clusterressource auf die neue Version.
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
```

Komplettes Bundle entfernen

Wenn Sie ein vollständiges Bundle heruntergeladen haben und gkectl prepare erfolgreich ausgeführt und den Administratorcluster und alle Nutzercluster aktualisiert haben, sollten Sie das vollständige 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 die Administratorsteuerungsebene nach einem fehlgeschlagenen Upgradeversuch nicht mit gkectl repair admin-master. Andernfalls wechselt der Administratorcluster in einen fehlerhaften Zustand.

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 Upgradeversuch 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, 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 einer fehlerhaften Administrator-Steuerungsebene direkt auf die Zielversion aktualisiert, ohne dass versucht wird, den Administratorcluster vor dem Upgrade auf der Quellversion wiederherzustellen.

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 Administrator-Steuerungsebene zurück. Daher muss die Administrator-Steuerungsebene fehlerfrei sein, damit das Upgrade fortgesetzt werden kann. 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.
```
gcloud storage 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

Das Upgrade von Clustern kann 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 Knoten 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.

Listen Sie alle PodDisruptionBudget-Objekte im Nutzercluster auf, die keine Störungen zulassen:

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

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Nutzercluster.

Die Standard-PDBs kube-system/log-aggregator und kube-system/prometheus werden in der Ausgabe mit disruptionsAllowed: 0 angezeigt, wenn sie keine übereinstimmenden Pods haben und status.expectedPods den Wert 0 hat. Da diese PDBs das Beenden von Knoten per Drain nicht blockieren, können Sie sie ignorieren.

Weitere Informationen zum Upgrade

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 vSphere Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter Enabling VMware DRS in a cluster.
Der in der Konfigurationsdatei für Anmeldedaten 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 den Versionshinweisen zu Google Distributed Cloud unter Bekanntes Problem.

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 die Knoten des Nutzerclusters während des Upgrades die Steuerungsebene des Nutzers 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 Google Distributed Cloud die Knoten nacheinander 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: /home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /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
Terraform-Referenzdokumentation
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Cluster-Upgrade durchführen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

Firewallregeln prüfen

stackdriver aktivieren

Dataplane V2 aktivieren

Google API- und IAM-Anforderungen

Legacy-Funktionen bei Upgrades blockiert

IAM-Anforderungen für das Upgrade von Nutzerclustern

Einschränkungen bei erweiterten Clustern

Konfigurationsänderungen vor oder nach einem Upgrade vornehmen

Verfügbare Versionen für Clusterupgrades prüfen

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

gkeadm

Erforderliche Dateien suchen

Upgrade

Vom Nutzer verwaltet

Administratorcluster aktualisieren

1.31 und höher

1.30 und niedriger

Führen Sie das Upgrade aus

gkectl

Asynchrones Upgrade

Fehlerbehebung bei asynchronen Upgrades

Synchrones Upgrade

gcloud-CLI

Nutzercluster aktualisieren

Console

gcloud-CLI

gkectl

Upgrade eines Nutzerclusters vorbereiten

Preflight-Prüfungen ausführen

Führen Sie gkectl upgrade cluster aus

Asynchrones Upgrade

Fehlerbehebung bei asynchronen Upgrades

Synchrones Upgrade

Upgrade fortsetzen

Terraform

Komplettes Bundle 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

Weitere Informationen zum Upgrade

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

Cluster-Upgrade durchführen

`stackdriver` aktivieren

Führen Sie `gkectl upgrade cluster` aus