Version 1.1. Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Verfügbare Versionen

Upgrade von GKE On-Prem

In diesem Thema wird gezeigt, wie Sie GKE On-Prem aktualisieren.

Zum Aktualisieren von GKE On-Prem führen Sie ein Upgrade Ihrer Administrator-Workstation aus. Anschließend aktualisieren Sie Ihre Cluster.

Hinweis

Befolgen Sie diese Anweisungen von Ihrer lokalen Workstation oder Ihrem Laptop aus. Folgen Sie ihnen nicht auf Ihrer bestehenden Administrator-Workstation.
Prüfen Sie die aktuelle Version des Clusters.
Lesen Sie die Versionshinweise.
Prüfen Sie die Versionen

Lesen Sie außerdem die folgenden Punkte:

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.
Steuerungsebene der Nutzercluster	Normalerweise sollten Sie keine nennenswerten Ausfallzeiten für Nutzercluster-Steuerungsebenen erwarten. Lang andauernde Verbindungen zum Kubernetes API-Server können jedoch unterbrochen werden und müssen neu hergestellt werden. In diesen Situationen sollte der API-Aufrufer noch einmal versuchen, eine Verbindung herzustellen. Im schlimmsten Fall kann es während eines Upgrades bis zu einer Minute dauern. Hinweis: Wenn Nutzercluster-Knoten während des Upgrades die Nutzersteuerungsebene nicht erreichen können, werden keine neuen Arbeitslasten für den Cluster geplant. Vorhandene Arbeitslasten sind davon nicht betroffen.
Nutzerclusterknoten	Wenn ein Upgrade eine Änderung an Nutzerclusterknoten erfordert, erstellt GKE On-Prem die Knoten rollierend neu und plant die auf diesen Knoten ausgeführten Pods neu. Sie können Auswirkungen auf Ihre Arbeitslasten verhindern, wenn Sie die entsprechenden PodDisruptionBudgets und Anti-Affinitätsregeln konfigurieren.

Sequenzielles Upgrade

GKE On-Prem unterstützt sequenzielle Upgrades. Damit ein Cluster auf eine neue Version aktualisiert werden kann, muss für den Cluster die letzte Version gültig sein.

Sie können Ihre Cluster nicht direkt auf die neueste Version aktualisieren, wenn die aktuelle Version mehr als eine Version zurückliegt. In diesem Fall müssen Sie den Cluster sequenziell aktualisieren.

Beispiel

Angenommen, die folgenden Versionen sind verfügbar, wobei Ihre Administrator-Workstation und Ihre Cluster die älteste Version ausführen.

1.0.1 (älteste Version)
1.0.2
1.1 (aktuelle Version)

In diesem Fall ist 1.1 die aktuelle Version. Um von 1.0.1 auf 1.1 zu aktualisieren, müssen Sie dann folgende Schritte ausführen:

Aktualisieren Sie Ihre Administrator-Workstation von 1.0.1 auf 1.0.2.
Aktualisieren Sie Ihre Cluster von 1.0.1 auf 1.0.2.
Aktualisieren Sie Ihre Administrator-Workstation von 1.0.2 auf 1.1.
Aktualisieren Sie Ihre Cluster von 1.0.2 auf 1.1.

GKE On-Prem-Konfigurationsdatei und kubeconfig-Dateien sichern

Wenn Sie Ihre Administrator-Workstation aktualisieren, löscht Terraform die VM der Administrator-Workstation und ersetzt sie durch eine aktualisierte Administrator-Workstation. Bevor Sie ein Upgrade für Ihre Administrator-Workstation ausführen, müssen Sie Ihre GKE On-Prem-Konfigurationsdatei und die kubeconfig-Dateien Ihrer Cluster sichern. Später kopieren Sie diese Dateien dann wieder auf Ihre aktualisierte Administrator-Workstation.

Administrator-Workstation aktualisieren

Wenn Sie ein Upgrade für Ihre Administrator-Workstation ausführen, umfasst dies die folgenden Entitäten in der gleichen Version wie die Open Virtualization Appliance-Datei (OVA) der Administrator-Workstation:

gkectl
vollständiges Paket

Nach dem Upgrade Ihrer Administrator-Workstation führen Sie ein Upgrade Ihrer Cluster aus.

OVA herunterladen

Laden Sie unter Downloads die OVA-Datei der Administrator-Workstation für die Version herunter, auf die Sie ein Upgrade vornehmen möchten.

Mit dem folgenden Befehl laden Sie die neueste OVA herunter:

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

OVA in vSphere importieren und als VM-Vorlage markieren

In den folgenden Abschnitten führen Sie diese Schritte aus:

Einige Variablen erstellen, die Elemente Ihrer vCenter Server- und vSphere-Umgebung deklarieren
OVA-Datei für die Administrator-Workstation in vSphere importieren und als VM-Vorlage markieren

Variablen für `govc` erstellen

Bevor Sie die OVA-Datei für die Administrator-Workstation in vSphere importieren, müssen Sie für govc einige Variablen angeben, die Elemente Ihrer vCenter Server- und vSphere-Umgebung deklarieren:

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Sie können entweder den Standardressourcenpool von vSphere verwenden oder einen eigenen erstellen:

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

wobei

[VCENTER_SERVER_ADDRESS] ist die IP-Adresse oder der Hostname Ihres vCenter Servers.
[VCENTER_SERVER_USERNAME] ist der Nutzername eines Kontos, das die Administratorrolle oder gleichwertige Berechtigungen in vCenter Server hat.
[VCENTER_SERVER_PASSWORD] ist das Passwort des vCenter Server-Kontos.
[VSPHERE_DATASTORE] ist der Name des Datenspeichers, den Sie in Ihrer vSphere-Umgebung konfiguriert haben.
[VSPHERE_DATACENTER] ist der Name des Rechenzentrums, das Sie in Ihrer vSphere-Umgebung konfiguriert haben.
[VSPHERE_CLUSTER] ist der Name des Clusters, den Sie in Ihrer vSphere-Umgebung konfiguriert haben.
[VSPHERE_RESOURCE_POOL] ist der Name des Ressourcenpools, den Sie für Ihre vSphere-Umgebung konfiguriert haben.

OVA-Datei in vSphere importieren: Standard-Switch

Wenn Sie einen vSphere-Standard-Switch verwenden, importieren Sie die OVA-Datei mit diesem Befehl in vSphere:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

OVA in vSphere importieren: Verteilter Switch

Wenn Sie einen vSphere Distributed Switch verwenden, importieren Sie die OVA-Datei mit diesem Befehl in vSphere, wobei [YOUR_DISTRIBUTED_PORT_GROUP_NAME] der Name Ihrer verteilten Portgruppe ist:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Terraform-Vorlagenvariablen für die neue Administrator-Workstation-VM festlegen

Legen Sie in der TFVARS-Datei Ihrer Administrator-Workstation für vm_template die Version fest, auf die Sie ein Upgrade ausführen. Der Wert von vm_template sieht so aus, wobei [VERSION] die OVA-Version ist:

gke-on-prem-admin-appliance-vsphere-[VERSION]

Ihre Administrator-Workstation mit Terraform aktualisieren

Führen Sie den folgenden Befehl aus, um Ihre Administrator-Workstation zu aktualisieren. Mit diesem Befehl wird die aktuelle Administrator-Workstation-VM gelöscht und durch eine aktualisierte VM ersetzt:

terraform init && terraform apply -auto-approve -input=false

Verbindung zur Administrator-Workstation herstellen

SSH-Verbindung zur Administrator-Workstation herstellen

ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

Wenn Sie einen Proxy verwenden, müssen Sie Google Cloud CLI für den Proxy konfigurieren, damit Sie die Befehle gcloud und gsutil ausführen können. Eine Anleitung finden Sie unter gcloud CLI zur Verwendung hinter einem Proxy bzw. einer Firewall konfigurieren.
Melden Sie sich mit Ihren Kontoanmeldedaten in Google Cloud an:
```
gcloud auth login
```
Registrieren Sie gcloud als Credential Helper für Docker. Zu folgendem Befehl finden Sie weitere Informationen:
```
gcloud auth configure-docker
```
Erstellen Sie einen privaten Schlüssel für Ihr Dienstkonto auf der Zulassungsliste.

Kopieren Sie die E-Mail-Adresse des Dienstkontos.
```
gcloud iam service-accounts list
```
Erstellen Sie den privaten Schlüssel des Dienstkontos. Dabei ist [KEY_FILE] der Name, den Sie für die Datei verwenden. Mit folgendem Befehl wird die Datei im aktuellen Arbeitsverzeichnis gespeichert:
```
gcloud iam service-accounts keys create key.json \
--project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
```
wobei
- [PROJECT_ID] ist die Projekt-ID.
- [KEY_FILE] ist der Name und Pfad der Datei, in der der private Schlüssel des Dienstkontos gespeichert wird, z. B. /home/ubuntu/key.json.
- [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] ist die E-Mail-Adresse des Dienstkontos auf der Zulassungsliste.

Aktivieren Sie Ihr Dienstkonto auf der Zulassungsliste:

gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [KEY_FILE]

Gesicherte Konfigurations- und kubeconfig-Dateien kopieren

Weiter oben haben Sie Ihre GKE On-Prem-Konfigurationsdatei und die kubeconfig-Dateien Ihrer Cluster gesichert. Kopieren Sie diese Dateien nun wieder auf die aktualisierte Administrator-Workstation.

Cluster aktualisieren

Führen Sie die folgenden Schritte aus, nachdem Sie Ihre Administrator-Workstation aktualisiert und eine Verbindung zu ihr hergestellt haben:

Verfügbarkeit ausreichender IP-Adressen prüfen

Achten Sie vor dem Upgrade darauf, dass genügend IP-Adressen für Ihre Cluster verfügbar sind.

DHCP

Wenn dem Cluster die IP-Adressen eines DHCP-Servers zugewiesen wurden, prüfen Sie, ob der DHCP-Server in dem Netzwerk, in dem die Knoten erstellt werden, genügend IP-Adressen hat. Es sollten mehr IP-Adressen vorhanden sein, als Knoten im Nutzercluster ausgeführt werden.

Statische IP-Adressen

Wenn der Cluster statische IP-Adressen hat, prüfen Sie, ob im Cluster genügend IP-Adressen zugewiesen wurden:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

wobei

[ADMIN_CLUSTER_KUBECONFIG] weist kubectl an, die kubeconfig-Datei des Administratorclusters zu verwenden, mit der Nutzerclusterkonfigurationen aufgerufen und/oder geändert werden.
-n [USER_CLUSTER_NAME] weist kubectl an, in einem Namespace zu suchen, der nach dem Nutzercluster benannt ist.
[USER_CLUSTER_NAME] -o yaml teilt kubectl mit, für welchen Nutzercluster Sie den Befehl ausführen. -o yaml zeigt die Konfiguration des Nutzerclusters an.

Suchen Sie in der Ausgabe des Befehls nach dem Feld reservedAddresses. Das Feld sollte mehr IP-Adressen enthalten, als Knoten im Nutzercluster ausgeführt werden.

Wenn Sie dem Feld reservedAddresses weitere Adressen hinzufügen möchten, führen Sie die folgenden Schritte aus:

Öffnen Sie die Konfigurationsdatei des Nutzerclusters zur Bearbeitung:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME] --validate=false
```
Die Clusterkonfiguration wird im Standardeditor Ihrer Shell geöffnet.
Fügen Sie beliebig viele zusätzliche statische IP-Blöcke hinzu. Ein IP-Block besteht aus den Feldern gateway, hostname, ip und netmask.

Hinweis: Es ist immer sicher, dem Feld reservedAddresses weitere IP-Blöcke hinzuzufügen. Es ist jedoch nicht sicher, verwendete IP-Adressen zu entfernen.

Im Folgenden sehen Sie ein Beispiel für ein reservedAddresses-Feld mit vier hervorgehobenen statischen IP-Blöcken:

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Konfigurationsdatei ändern

Bearbeiten Sie auf der VM Ihrer Administrator-Workstation Ihre Konfigurationsdatei. Legen Sie den Wert von bundlepath fest, wobei [VERSION] die GKE On-Prem-Version ist, auf die Sie Ihre Cluster aktualisieren:

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

Informationen zu automatisch aktivierten Features

Eine neue GKE On-Prem-Version kann neue Features enthalten oder bestimmte Features von VMware vSphere unterstützen. Manchmal werden solche Features durch das Upgrade auf eine GKE On-Prem-Version automatisch aktiviert. Weitere Informationen zu den neuen Features finden Sie in den Versionshinweisen von GKE On-Prem. Solche neuen Features sind manchmal in der GKE On-Prem-Konfigurationsdatei enthalten.

Neue Features über die Konfigurationsdatei deaktivieren

Wenn Sie ein neues Feature deaktivieren müssen, dass durch eine neue GKE On-Prem-Version automatisch aktiviert wurde und durch die Konfigurationsdatei gesteuert wird, führen Sie die folgenden Schritte aus, bevor Sie Ihren Cluster aktualisieren:

Erstellen Sie in der aktualisierten Administration-Workstation eine neue Konfigurationsdatei mit einem anderen Namen als dem Ihrer aktuellen Konfigurationsdatei:
```
gkectl create-config --config [CONFIG_NAME]
```
Öffnen Sie die neue Konfigurationsdatei und das Feld der Funktion. Schließen Sie die Datei.
Öffnen Sie Ihre aktuelle Konfigurationsdatei und fügen Sie das Feld der neuen Funktion in die entsprechende Spezifikation ein.
Geben Sie im Feld einen false oder einen entsprechenden Wert ein.
Speichern Sie die Konfigurationsdatei. Fahren Sie mit dem Aktualisieren der Cluster fort.

Sie sollten immer die Versionshinweise lesen, bevor Sie Ihre Cluster aktualisieren. Sie können die Konfiguration eines vorhandenen Clusters nach dem Upgrade nicht deklarativ ändern.

`gkectl prepare` ausführen

Führen Sie folgenden Befehl aus:

gkectl prepare --config [CONFIG_FILE]

Mit dem Befehl gkectl prepare werden folgende Tasks ausgeführt:

Kopieren Sie bei Bedarf ein neues Knoten-Betriebssystem-Image in Ihre vsphere-Umgebung und markieren Sie das Betriebssystem-Image als Vorlage.
Übertragen Sie die im neuen Bundle angegebenen aktualisierten Docker-Images per Push in Ihre private Docker-Registry, sofern Sie eine solche konfiguriert haben.

Upgrade für Administratorcluster ausführen

Führen Sie dazu diesen Befehl aus:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

Upgrade für Nutzercluster ausführen

Für das Upgrade eines Nutzerclusters muss die Version Ihres Administratorclusters mindestens der Zielversion des Nutzercluster-Upgrades entsprechen. Wenn die Version Ihres Administratorclusters niedriger ist, führen Sie vor dem Upgrade des Nutzerclusters ein entsprechendes Upgrade für den Administratorcluster aus.

gkectl

Führen Sie auf Ihrer Administrator-Workstation den folgenden Befehl aus:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters, [CLUSTER_NAME] der Name des aktualisierten Nutzerclusters und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

Console

Sie können Ihre Nutzercluster während der Installation oder nach der Erstellung bei der Google Cloud Console registrieren. Sie können Ihre registrierten GKE On-Prem-Cluster und Ihre Google Kubernetes Engine-Cluster über das GKE-Menü der Google Cloud Console aufrufen und sich anmelden.

Wenn ein Upgrade für GKE On-Prem-Nutzercluster verfügbar ist, wird in der Google Cloud Console eine Benachrichtigung angezeigt. Wenn Sie auf diese Benachrichtigung klicken, werden eine Liste der verfügbaren Versionen und ein gkectl-Befehl angezeigt, den Sie zum Aktualisieren des Clusters ausführen können:

Rufen Sie in der Google Cloud Console das GKE-Menü auf.

Zum GKE On-Prem-Menü
Klicken Sie unter der Spalte Benachrichtigungen für den Nutzercluster auf Upgrade verfügbar, falls vorhanden.
Kopieren Sie den Befehl gkectl upgrade cluster.
Führen Sie auf Ihrer Administrator-Workstation den Befehl gkectl upgrade cluster aus, wobei [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters, [CLUSTER_NAME] der Name des aktualisierten Nutzerclusters und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei ist, die Sie für das Upgrade verwenden.

Upgrade fortsetzen

Wenn das Upgrade eines Nutzerclusters unterbrochen, der Administratorcluster aber erfolgreich aktualisiert wurde, können Sie das Upgrade fortsetzen. Führen Sie dazu noch einmal gkectl upgrade cluster mit der gleichen GKE On-Prem-Konfigurationsdatei und der gleichen kubeconfig-Datei des Administratorclusters aus.

Informationen zum Fortsetzen eines Administratorcluster-Upgrades

Sie sollten das Upgrade eines Administratorclusters nicht unterbrechen. Derzeit können Upgrades von Administratorclustern nicht in jedem Fall fortgesetzt werden. Wenn das Upgrade eines Administratorclusters aus irgendeinem Grund unterbrochen wird, wenden Sie sich an den Support.

Bekannte Probleme

Die folgenden bekannten Probleme betreffen das Aktualisieren von Clustern.

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

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

Version 1.1.1-gke.2: Das Datenlaufwerk im vSAN-Datenspeicherordner kann gelöscht werden

Wenn Sie einen vSAN-Datenspeicher verwenden, müssen Sie einen Ordner erstellen, in dem das VMDK gespeichert werden soll. Derzeit ist es wegen eines bekannten Problems erforderlich, dass Sie für vcenter.datadisk den UUID-Pfad (Universally Unique Identifier) des Ordners und nicht den Dateipfad angeben. Andernfalls können Upgrades fehlschlagen.

In Version 1.1.2 soll dieses Problem behoben werden. Um das Problem zu umgehen, führen Sie vor dem Upgrade die folgenden Schritte für den Knoten der Administrator-Steuerungsebene aus:

Rufen Sie über die vCenter-Benutzeroberfläche den UUID des Ordners in Ihrem vSAN-Datenspeicher ab.
Listen Sie die Maschinenressourcen in Ihren Clustern auf. Diese Maschinen entsprechen den Knoten in den Clustern:
```
kubectl get machines -n all
```
Öffnen Sie für die Maschine der Administrator-Steuerungsebene (gke-admin-master) deren Konfiguration zur Bearbeitung:
```
kubectl edit machine [MACHINE_NAME]
```

Ändern Sie das Feld spec.providerSpec.value.machineVariables.data_disk_path. Ersetzen Sie darin den Pfad zur VMDK-Datei durch den UUID. Beispiel:

spec:
providerSpec:
 value:
   apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
   kind: VsphereMachineProviderConfig
   machineVariables:
     data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
     datacenter: datacenter
     datastore: datastore

Speichern Sie die Datei.
Öffnen Sie die GKE On-Prem-Konfigurationsdatei.
Ersetzen Sie in vcenter.datadisk den Ordner im Dateipfad durch den UUID des Ordners. Beispiel:
```
vcenter:
 ...
 datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
```
Fahren Sie mit dem Aktualisieren der Cluster fort.

Upgrade auf Version 1.1.0-gke.6 von Version 1.0.2-gke.3: OIDC-Problem

Cluster der Versionen 1.0.11, 1.0.1-gke.5 und 1.0.2-gke.3, für die OpenID Connect (OIDC) konfiguriert ist, können nicht auf Version 1.1.0-gke.6 aktualisiert werden. Dieses Problem wurde in Version 1.1.1-gke.2 behoben.

Wenn Sie einen Cluster der Version 1.0.11, 1.0.1-gke.5 oder 1.0.2-gke.3 bei der Installation mit OIDC konfiguriert haben, können Sie kein Upgrade ausführen. Stattdessen sollten Sie neue Cluster erstellen.

Upgrade auf Version 1.0.2-gke.3 von Version 1.0.11

In Version 1.0.2-gke.3 werden die folgenden OIDC-Felder (usercluster.oidc) eingeführt. Mit diesen Feldern können Sie sich von der Google Cloud Console aus in einem Cluster anmelden:

usercluster.oidc.kubectlredirecturl
usercluster.oidc.clientsecret
usercluster.oidc.usehttpproxy

Wenn Sie OIDC verwenden möchten, ist das Feld clientsecret erforderlich, auch wenn Sie sich nicht über die Google Cloud Console bei einem Cluster anmelden möchten. Zur Verwendung von OIDC müssen Sie möglicherweise einen Platzhalterwert für clientsecret angeben:

oidc:
  clientsecret: "secret"

Anhang

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

Ab Version 1.1.0-gke.6 erstellt GKE On-Prem für die Knoten Ihres Nutzerclusters automatisch VMware-Anti-Affinitätsregeln vom Typ Distributed Resource Scheduler (DRS). Die Knoten werden damit auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt. Ab Version 1.1.0-gke.6 wird dieses Feature für neue und vorhandene Cluster automatisch 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.
Das im Feld vcenter angegebene vSphere-Nutzerkonto hat die Berechtigung Host.Inventory.EditCluster.
Es sind mindestens drei physische Hosts verfügbar.

VMware DRS vor dem Upgrade auf 1.1.0-gke.6 deaktivieren

Wenn Sie dieses Feature nicht für Ihre vorhandenen Nutzercluster aktivieren möchten, z. B. weil nicht genügend Hosts für das Feature vorhanden sind, führen Sie die folgenden Schritte aus, bevor Sie Ihre Nutzercluster aktualisieren:

Öffnen Sie die vorhandene GKE On-Prem-Konfigurationsdatei.
Fügen Sie unter der usercluster-Spezifikation das Feld antiaffinitygroups hinzu, wie in der Dokumentation zu antiaffinitygroups beschrieben:
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
Speichern Sie die Datei.
Verwenden Sie die Konfigurationsdatei für das Upgrade. Ihre Cluster werden aktualisiert, aber das Feature wird nicht aktiviert.

Alternatives Upgradeszenario

In diesem Thema wird die einfachste Möglichkeit zur Aktualisierung von GKE On-Prem beschrieben. In der Tabelle unten wird ein alternatives Upgrade-Szenario beschrieben. In diesem Szenario aktualisieren Sie nur gkectl und Ihre Cluster, aber nicht die Administrator-Workstation:

Szenario	Schritte
Der Release enthält keine Sicherheitsupdates für die Administrator-Workstation.	Laden Sie `gkectl` herunter. Laden Sie das Bundle herunter. Folgen Sie dazu der Anleitung auf dieser Seite.

Fehlerbehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Neue Knoten erstellt, aber nicht intakt

Symptome

Neue Knoten registrieren sich nicht auf der Steuerungsebene des Nutzerclusters, wenn Sie den manuellen Load-Balancing-Modus verwenden.

Mögliche Ursachen

Die Ingress-Validierung im Knoten, die den Startvorgang der Knoten blockiert, kann aktiviert sein.

Lösung

Führen Sie Folgendes aus, um die Prüfung zu deaktivieren:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

Clusterprobleme mit `gkectl` diagnostizieren

Verwenden Sie gkectl diagnose-Befehle, um Clusterprobleme zu identifizieren und Clusterinformationen an Google zu senden. Siehe Clusterprobleme diagnostizieren.

Standard-Logging-Verhalten

Für gkectl und gkeadm reicht es aus, die Standard-Logging-Einstellungen zu verwenden:

Standardmäßig werden Logeinträge so gespeichert:
- Für gkectl ist die Standard-Logdatei /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log. Die Datei ist mit der Datei logs/gkectl-$(date).log in dem lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
- Für gkeadm ist die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.
Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn --alsologtostderr auf false gesetzt ist).
Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.
Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.

Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.

Nicht standardmäßigen Speicherort für die Logdatei angeben

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl angeben möchten, verwenden Sie das Flag --log_file. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm angeben möchten, verwenden Sie das Flag --log_file.

Cluster-API-Logs im Administratorcluster suchen

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, versuchen Sie, dies durch Untersuchen der Logs der Cluster-API-Controller im Administratorcluster zu beheben:

Suchen Sie im Namespace kube-system den Namen des Cluster-API-Controller-Pods, wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad zur kubeconfig-Datei des Administratorclusters ist:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Verwenden Sie optional für die Fehlersuche grep oder ein ähnliches Tool:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```