GKE On-Prem upgraden

Auf dieser Seite erfahren Sie, wie Sie ein Upgrade für GKE On-Prem ausführen.

Wenn Sie GKE On-Prem aktualisieren möchten, 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 und die bekannten Probleme, die sich auf das Upgrade auswirken.
• 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 verschiebt 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, d. h. der Cluster, den Sie aktualisieren möchten, muss sich in der unmittelbar vorherigen Patchversion befinden.

Sie können Ihre Cluster nicht direkt auf die neueste Version einer Version aktualisieren, die mehr als eine Patchversion aufweist. Wenn Ihr Cluster mehr als eine Patchversion aufweist, müssen Sie diesen Cluster nacheinander für jede Patchversion aktualisieren.

Beispiel

Wenn Sie ein Upgrade auf die Version 1.1.0 ausführen möchten und Ihre Administrator-Workstation und Ihre Nutzercluster die ältere Version 1.0.1 ausführen:

• 1.0.1 (älteste Version)
• 1.0.2
• 1.1.0 (aktuelle Version)

Führen Sie dann die folgenden Schritte aus, um ein Upgrade auf die Version 1.0.2 und dann auf die Version 1.1.0 auszuführen:

1. Führen Sie ein Upgrade Ihrer Administrator-Workstation von 1.0.1 auf 1.0.2 aus.
2. Aktualisieren Sie Ihre Cluster von 1.0.1 auf 1.0.2.
3. Führen Sie ein Upgrade Ihrer Administrator-Workstation von 1.0.2 auf 1.1 durch.
4. Aktualisieren Sie Ihre Cluster von 1.0.2 auf 1.1.0.

Ihre GKE On-Prem-Konfigurationsdatei und die 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 das Upgrade der Administrator-Workstation ausführen, müssen Sie zuerst die GKE On-Prem-Konfigurationsdatei und die kubeconfig-Dateien Ihres Clusters sichern. Der Befehl gkectl create cluster erstellt die kubeconfig-Dateien für den Administratorcluster ([ADMIN_CLUSTER_KUBECONFIG]) und den Nutzercluster ([USER_CLUSTER_KUBECONFIG]). Ein Beispiel finden Sie in der Basisinstallation. Nach dem Upgrade Ihrer Administrator-Workstation kopieren Sie dieselben Dateien auf die aktualisierte Administrator-Workstation.

Administrator-Workstation aktualisieren

Sie verwenden Terraform, um Ihre Administrator-Workstation zu aktualisieren.

Wichtig: Sie müssen zuerst die Dateien der Administratorworkstation sichern, da Terraform die VM der Administratorworkstation löscht und durch eine neue VM ersetzt.

Die aktualisierte Administrator-Workstation enthält die folgenden Entitäten in derselben Version wie die Open Virtualization Appliance-Datei der Administrator-Workstation:

• gkectl
• vollständiges Paket

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.3.2-gke.1/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.{ova,ova.1.sig} ~/

Hinweis: Informationen zum Verifizieren dieser Datei finden Sie unter VAA mit openssl verifizieren.

OVA in vSphere importieren und als VM-Vorlage markieren

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

1. Einige Variablen erstellen, die Elemente Ihrer vCenter Server- und vSphere-Umgebung deklarieren
2. 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:

Hinweis: Sie finden viele dieser Werte, wenn Sie sich beim vCenter-Server anmelden.

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

Dabei gilt:

• [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.
Wenn Sie einen nicht standardmäßigen Ressourcenpool verwenden,
• [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.3.2-gke.1.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.3.2-gke.1.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:

Hinweis: Achten Sie darauf, die OVA-Datei in vSphere zu importieren, bevor Sie diesen Befehl ausführen.

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

Verbindung zur Administrator-Workstation herstellen

Stellen Sie eine SSH-Verbindung zu Ihrer Administrator-Workstation her, indem Sie den folgenden Befehl ausführen:

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

Ihre gesicherten Konfigurations- und kubeconfig-Dateien kopieren

Zuvor 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

Während eines Upgrades erstellt GKE On-Prem einen temporären Knoten im Administratorcluster und einen temporären Knoten in jedem zugeordneten Nutzercluster. Achten Sie darauf, dass Ihr DHCP-Server genügend IP-Adressen für diese temporären Knoten bereitstellen kann. Weitere Informationen finden Sie unter Erforderliche IP-Adressen für Administrator- und Nutzercluster.

Statische IP-Adressen

Während eines Upgrades erstellt GKE On-Prem einen temporären Knoten im Administratorcluster und einen temporären Knoten in jedem zugeordneten Nutzercluster. Prüfen Sie, ob Sie für Ihren Administratorcluster und jeden Nutzercluster genügend IP-Adressen reserviert haben. Für jeden Cluster müssen Sie mindestens eine IP-Adresse reserviert haben, die über die Anzahl der Clusterknoten hinausgeht. Weitere Informationen finden Sie unter Statische IP-Adressen konfigurieren.

Bestimmen Sie die Anzahl der Knoten in Ihrem Administratorcluster:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] der Pfad der kubeconfig-Datei Ihres Administratorclusters.

Sehen Sie sich als Nächstes die für Ihren Administratorcluster reservierten Adressen an:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

In der Ausgabe sehen Sie im Feld reservedAddresses die Anzahl der IP-Adressen, die für die Knoten des Administratorclusters reserviert sind. Die folgende Ausgabe zeigt beispielsweise, dass fünf IP-Adressen für die Knoten des Administratorclusters reserviert sind:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Die Anzahl der reservierten IP-Adressen sollte mindestens eine mehr als die Anzahl der Knoten im Administratorcluster betragen. Wenn dies nicht der Fall ist, können Sie eine zusätzliche Adresse reservieren. Dazu bearbeiten Sie das Clusterobjekt.

Öffnen Sie das Clusterobjekt zum Bearbeiten:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Fügen Sie unter reservedAddresses einen zusätzlichen Block mit gateway, hostname, ip und netmask hinzu.

Gehen Sie für jeden Ihrer Nutzercluster genauso vor.

So stellen Sie die Anzahl von Knoten in einem Nutzercluster fest:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

Dabei gilt:[USER_CLUSTER_KUBECONFIG] is the path of your user cluster's kubeconfig file.

So zeigen Sie die für einen Nutzercluster reservierten Adressen an:

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

Dabei gilt:

• [ADMIN_CLUSTER_KUBECONFIG] ist der Pfad der kubeconfig-Datei Ihres Administratorclusters.

• [USER_CLUSTER_NAME] ist der Name des Nutzerclusters.

So bearbeiten Sie das Clusterobjekt eines Nutzerclusters:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

Konfigurationsdatei ändern

Bearbeiten Sie auf der VM Ihrer Administrator-Workstation die Konfigurationsdatei, die Sie zum Erstellen Ihrer Administrator- und Nutzercluster verwendet haben. 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 Funktionen

Eine neue GKE On-Prem-Version kann neue Funktionen enthalten oder Unterstützung für bestimmte Funktionen von VMware vSphere bieten. Manchmal werden durch das Upgrade auf eine GKE On-Prem-Version solche Funktionen automatisch aktiviert. Weitere Informationen zu den neuen Funktionen von GKE On-Prem finden Sie in den Versionshinweisen. Neue Funktionen werden manchmal in der GKE On-Prem-Konfigurationsdatei angezeigt.

Neue Funktionen über die Konfigurationsdatei deaktivieren

Wenn Sie eine neue Funktion deaktivieren müssen, die in einer neuen GKE On-Prem-Version automatisch aktiviert ist und durch die Konfigurationsdatei gesteuert wird, führen Sie die folgenden Schritte aus, bevor Sie Ihren Cluster aktualisieren:

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

2. Öffnen Sie die neue Konfigurationsdatei und das Feld der Funktion. Schließen Sie die Datei.

3. Öffnen Sie Ihre aktuelle Konfigurationsdatei und fügen Sie das Feld der neuen Funktion in die entsprechende Spezifikation ein.

4. Geben Sie im Feld einen false oder einen entsprechenden Wert ein.

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

Mit dem Befehl gkectl prepare werden folgende Aufgaben 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 in Ihre private Docker-Registry, sofern Sie eine konfiguriert haben.

Führen Sie den folgenden Befehl aus, um die vorherigen Aufgaben auszuführen:

gkectl prepare --config [CONFIG_FILE] [FLAGS]

Dabei gilt:

• [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

• [FLAGS] ist ein optionaler Satz Flags. Sie können beispielsweise das Flag --skip-validation-infra einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.

Ihren Administratorcluster aktualisieren

Führen Sie diesen Befehl aus:

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

Dabei gilt:

• [ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei des Administratorclusters.

• [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

• [FLAGS] ist ein optionaler Satz Flags. Sie können beispielsweise das Flag --skip-validation-infra einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.

Ihren Nutzercluster aktualisieren

Zum Upgrade eines Nutzerclusters muss Ihr Administratorcluster auf die gewünschte Version oder höher aktualisiert werden, bevor Sie den Nutzercluster aktualisieren.

gkectl

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

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

Dabei gilt:

• [ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei des Administratorclusters.

• [CLUSTER_NAME] ist der Name des Nutzerclusters, den Sie aktualisieren.

• [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

• [FLAGS] ist ein optionaler Satz Flags. Sie können beispielsweise das Flag --skip-validation-infra einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.

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 eine Benachrichtigung in der Google Cloud Console 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:

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

   Zum GKE-Menü

2. Klicken Sie unter der Spalte Benachrichtigungen für den Nutzercluster auf Upgrade verfügbar, falls verfügbar.

3. Kopieren Sie den Befehl gkectl upgrade cluster.

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

Ein Upgrade fortsetzen

Wenn das Upgrade eines Nutzerclusters nach dem Upgrade des Administratorclusters unterbrochen wird, können Sie es fortsetzen, wenn Sie denselben Aktualisierungsbefehl mit dem Flag --skip-validation-all ausführen:

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

Informationen zum Fortsetzen eines Administratorcluster-Upgrades

Sie sollten ein Upgrade des Administratorclusters nicht unterbrechen. Derzeit werden Upgrades von Administratorclustern nicht immer fortgesetzt. 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.

Version 1.1.0-gke.6, 1.2.0-gke.6: Das Feld stackdriver.proxyconfigsecretname wurde entfernt

Das Feld stackdriver.proxyconfigsecretname wurde in Version 1.1.0-gke.6 entfernt. Die Preflight-Prüfungen von GKE On-Prem geben einen Fehler zurück, wenn das Feld in Ihrer Konfigurationsdatei vorhanden ist.

Dies können Sie umgehen, wenn Sie vor dem Upgrade auf 1.2.0-gke.6 das Feld proxyconfigsecretname aus Ihrer Konfigurationsdatei löschen.

Stackdriver verweist auf die alte Version

Vor Version 1.2.0-gke.6 verhindert ein bekanntes Problem, dass Stackdriver seine Konfiguration nach Clusterupgrades aktualisiert. Stackdriver verweist immer noch auf eine alte Version. Dadurch wird verhindert, dass Stackdriver die neuesten Funktionen seiner Telemetrie-Pipeline erhält. Dieses Problem kann dem Google-Support die Fehlerbehebung für Cluster erschweren.

Nachdem Sie die Cluster auf 1.2.0-gke.6 aktualisiert haben, führen Sie den folgenden Befehl für die Administrator- und Nutzercluster aus:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

Dabei ist [KUBECONFIG] der Pfad zur kubeconfig-Datei des Clusters.

Unterbrechung für Arbeitslasten mit PodDisruptionBudgets

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

Version 1.2.0-gke.6: Prometheus und Grafana werden nach dem Upgrade deaktiviert

In Nutzerclustern werden Prometheus und Grafana während des Upgrades automatisch deaktiviert. Die Konfigurations- und Messwertdaten gehen jedoch nicht verloren. In Administratoclustern bleiben Prometheus und Grafana aktiviert.

Eine Anleitung finden Sie in den Versionshinweisen zu GKE On-Prem.

Version 1.1.2-gke.0: Gelöschte Nutzerclusterknoten werden nicht aus dem vSAN-Datenspeicher entfernt

Eine Anleitung finden Sie in den Versionshinweisen zu GKE On-Prem.

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 für ein bekanntes Problem erforderlich, dass Sie vcenter.datadisk den UUID-Pfad (Universally Unique Identifier) des Ordners und nicht den Dateipfad angeben. Andernfalls können Upgrades fehlschlagen.

Eine Anleitung finden Sie in den Versionshinweisen zu GKE On-Prem.

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 mit OIDC während der Installation 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"

Knoten schließen ihren Upgradeprozess nicht ab

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

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

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

Anhang

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

Ab Version 1.1.0-gke.6 erstellt GKE On-Prem 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 Cluster und vorhandene Cluster aktiviert.

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

• VMware DRS ist aktiviert. Für VMware DRS ist die vplaner Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter VMware DRS in einem Cluster aktivieren.
• 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 diese Funktion nicht für Ihre vorhandenen Nutzercluster aktivieren möchten, z. B. wenn nicht genügend Hosts für die Funktion vorhanden sind, führen Sie die folgenden Schritte aus, bevor Sie Ihre Nutzercluster aktualisieren:

1. Öffnen Sie die vorhandene GKE On-Prem-Konfigurationsdatei.
2. Fügen Sie unter der Spezifikation usercluster das Feld antiaffinitygroups hinzu:

   usercluster:
         ...
         antiaffinitygroups:
           enabled: false
   

3. Speichern Sie die Datei.
4. Verwenden Sie die Konfigurationsdatei zur Aktualisierung. Ihre Cluster werden aktualisiert, aber die Funktion ist nicht aktiviert.

Alternatives Upgradeszenario

Wenn Sicherheitspatches wie CVEs (Common Vulnerabilities and Exposures) für Ihre Version der Administratorarbeitsstation nicht vorhanden sind, können Sie die alternative Methode verwenden, um GKE On-Prem zu aktualisieren. Mit der alternativen Methode werden nur gkectl und Ihre Nutzercluster aktualisiert. In diesem Szenario führen Sie kein Upgrade Ihrer Administrator-Workstation durch. Daher müssen Sie diese alternative Methode nur verwenden, wenn alle Sicherheitsupdates auf Ihre vorhandene Verwaltungs-Workstation angewendet werden.

Wichtig: Bei dieser alternativen Upgrade-Methode tritt ein bekanntes Problem auf, wenn Sie Ihre Nutzercluster mithilfe des Bundle-Downloads von Version 1.2.2 auf 1.3.0 aktualisieren. Während des Upgrades kann es zu einer Zeitüberschreitung kommen, die dazu führt, dass das Upgrade des Nutzerclusters fehlschlägt. Wenn Sie dieses Problem vermeiden möchten, müssen Sie den vollständigen Upgrade-Prozess ausführen, der das Upgrade Ihrer Administrator-Workstation mithilfe der OVA-Datei umfasst.

1. Aktualisieren Sie die Komponenten von Google Cloud CLI: gcloud components update.
2. Laden Sie das aktuelle gkectl-Tool herunter und installieren Sie es.
3. Laden Sie das Bundle herunter.
4. Aktualisieren Sie Ihre Nutzercluster.

Problembehebung

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.

gkectl-Befehle umfassend ausführen

-v5

gkectl-Fehler in stderr protokollieren

--alsologtostderr

gkectl-Logs auf der Administratorworkstation suchen

Auch wenn Sie nicht die Debugging-Flags übergeben, können Sie gkectl-Logs im folgenden Verzeichnis der Administrator-Workstation aufrufen:

/home/ubuntu/.config/gke-on-prem/logs

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:

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

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