Auf dieser Seite wird erläutert, wie Sie ein Upgrade von GKE on VMware durchführen. Wenn Ihr Nutzercluster von der Anthos On-Prem API verwaltet wird und Sie die Google Cloud Console oder die Google Cloud CLI verwenden möchten, um den Cluster zu aktualisieren, lesen Sie Nutzercluster mit Anthos On-Prem API-Clients upgraden.
Übersicht über den Upgradevorgang
Sie können ein Upgrade direkt auf jede Version ausführen, die sich in der gleichen Nebenversion oder in der nächsten Nebenversion befindet. Sie können beispielsweise ein Upgrade von 1.14.0 auf 1.14.1 oder von 1.13.1 auf 1.14.0 ausführen.
Wenn Sie ein Upgrade auf eine Version ausführen, die nicht Teil der nächsten Nebenversion ist, müssen Sie zwischen der aktuellen und der gewünschten Version ein Upgrade für jede Nebenversion ausführen. Wenn Sie beispielsweise von Version 1.12.2 auf Version 1.14.0 aktualisieren möchten, können Sie kein direktes Upgrade durchführen. Sie müssen zuerst ein Upgrade von 1.12.2 auf 1.13.x und dann ein Upgrade auf 1.14.0 durchführen.
In diesem Thema wird beschrieben, wie Sie ein Upgrade von Version 1.13.x auf Version 1.14.y durchführen.
Lesen Sie die Best Practices für Clusterupgrades, bevor Sie mit dem Upgrade beginnen.
Nachfolgend ist der allgemeine Workflow für das Upgraden dargestellt.
Führen Sie ein Upgrade Ihrer Administratorworkstation auf die Zielversion Ihres Upgrades durch.
Führen Sie ein Upgrade Ihrer Nutzercluster über Ihre Administrator-Workstation durch.
Nachdem alle Nutzercluster aktualisiert wurden, können Sie den Administratorcluster über die Administratorworkstation upgraden. Dieser Schritt ist optional, es sei denn, Sie benötigen die im Upgrade verfügbaren Features.
Asynchrones Upgrade von Nutzerclustern
Für ein Nutzerclusterupgrade gibt es zwei Varianten des Befehls gkectl upgrade cluster
:
- Asynchron (empfohlen)
- Synchron
Bei der asynchronen Variante startet der Befehl das Upgrade und wird dann abgeschlossen. Sie müssen die Ausgabe des Befehls nicht während der gesamten Dauer des Upgrades beobachten. Stattdessen können Sie den Upgradefortschritt 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 dem Befehl das Flag --async
hinzu.
Weitere Informationen finden Sie unter Nutzercluster upgraden.
Zertifikatsrotation während des Upgrades
Während eines Upgrades werden untergeordnete Zertifikate rotiert, CA-Zertifikate jedoch nicht. Sie müssen Ihre CA-Zertifikate mindestens alle fünf Jahre manuell rotieren. Weitere Informationen finden Sie unter Rotation von Zertifizierungsstellen für Nutzercluster und Rotieren von CA-Zertifikaten von Administratorclustern.
Auf Upgrade vorbereiten
Erstellen Sie vor dem Upgrade einen Snapshot Ihres Clusters. Der Snapshot hilft bei der Fehlerbehebung, wenn während des Upgrades ein Problem auftritt.
Bevor Sie die Administratorworkstation erstellt haben, haben Sie die von gkeadm create config
generierte Konfigurationsdatei für die Administratorworkstation ausgefüllt. 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. Weitere Informationen finden Sie unter Informationsdatei neu erstellen, falls vorhanden.
Führen Sie ein Upgrade Ihrer Administrator-Workstation durch.
gkeadm
herunterladen:gkeadm upgrade gkeadm --target-version TARGET_VERSION
Ersetzen Sie TARGET_VERSION durch die Zielversion Ihres Upgrades.
Führen Sie ein Upgrade Ihrer Administrator-Workstation aus:
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.
Der vorherige Befehl führt die folgenden Aufgaben aus:
Sichert alle Dateien im Basisverzeichnis Ihrer aktuellen Administrator-Workstation. Dazu gehören:
- Die Konfigurationsdatei des Administratorclusters. Der Standardname ist
admin-cluster.yaml
. - Ihre Nutzercluster-Konfigurationsdatei. Der Standardname ist
user-cluster.yaml
. - Die kubeconfig-Dateien für Ihren Administratorcluster und Ihre Nutzercluster.
- Das Root-Zertifikat für Ihren vCenter-Server. Diese Datei muss Lese- und Schreibberechtigungen für Inhaber haben.
- Die JSON-Schlüsseldatei für das Dienstkonto für den Komponentenzugriff. Diese Datei muss Lese- und Schreibberechtigungen für Inhaber haben.
- Die JSON-Schlüsseldateien für die Dienstkonten connect-register, connect-agent und logging-monitoring.
- Die Konfigurationsdatei des Administratorclusters. Der Standardname ist
Erstellt eine neue Administrator-Workstation und kopiert alle gesicherten Dateien auf die neue Administrator-Workstation.
Löscht die alte Administrator-Workstation.
Verfügbarkeit ausreichender IP-Adressen prüfen
Prüfen Sie vor dem Upgrade Ihrer Cluster, ob Sie genügend IP-Adressen zugewiesen haben. Sie können bei Bedarf zusätzliche IP-Adressen zuweisen. Unter Knoten-IP-Adressen verwalten erfahren Sie, wie viele IP-Adressen Sie benötigen.
Nutzercluster aktualisieren
Es gibt zwei Arten von Nutzerclusterupgrades, die Sie über die Befehlszeile ausführen können:
- Asynchron
- Synchron
Asynchrones Upgrade
Führen Sie die folgenden Schritte auf Ihrer Administrator-Workstation aus:
Führen Sie
gkectl prepare
aus, um Betriebssystem-Images in vSphere zu importieren:gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Wenn der Cluster einen Windows-Knotenpool hat, führen Sie
gkectl prepare windows
aus und aktualisieren Sie das FeldosImage
für den Knotenpool. Eine ausführliche Anleitung finden Sie unter Nutzercluster mit Windows-Knotenpools upgraden.Führen Sie das Tool vor dem Upgrade aus, um den Zustand und die Konfiguration des Clusters zu prüfen.
Legen Sie in der Konfigurationsdatei des Nutzerclusters
gkeOnPremVersion
auf die Zielversion Ihres Upgrades fest.Starten Sie auf Ihrer Administratorworkstation ein asynchrones Upgrade:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG \ --async
Der vorherige Befehl wird ausgeführt. Sie können Ihren Nutzercluster 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
. Wird der Cluster noch aktualisiert, ist der Wert vonSTATE
UPGRADING
. Beispiel:NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc False UPGRADING 9h 1.14.0-gke.1
Die möglichen Werte für
STATE
sindPROVISIONING
,UPGRADING
,DELETING
,UPDATING
,RUNNING
,RECONCILING
,ERROR
undUNKNOWN
.So erhalten Sie weitere Details zum Upgradefortschritt und zu Clusterereignissen:
gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --cluster USER_CLUSTER_NAME -v 5
Die Ausgabe zeigt die benutzerdefinierte Ressource OnPremUserCluster für den angegebenen Nutzercluster, einschließlich Clusterstatus, Bedingungen und Ereignissen.
Wir zeichnen Ereignisse zu Beginn und Ende jeder kritischen Upgradephase auf, darunter:
- ControlPlaneUpgrade
- MasterNodeUpgrade
- AddonsUpgrade
- NodePoolsUpgrade
Beispielausgabe:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodePoolsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating node pools: pool-2: Creating or updating node pool Normal AddonsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating addon workloads Normal ControlPlaneUpgradeStarted 25m onprem-user-cluster-controller Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready Normal ControlPlaneUpgradeFinished 23m onprem-user-cluster-controller Control plane is running
Wenn das Upgrade abgeschlossen ist, zeigt
gkectl list clusters
fürSTATUS
den WertRUNNING
an:NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc True RUNNING 9h 1.14.0-gke.1
Wenn das Upgrade abgeschlossen ist, wird in
gkectl describe clusters
außerdem das FeldLastGKEOnPremVersion
unterStatus
angezeigt. Beispiel:Status: Cluster State: RUNNING LastGKEOnOremVersion: 1.14.0-gke.1
Fehler beim asynchronen Upgrade beheben
Bei einem asynchronen Upgrade basiert die Zeitüberschreitung auf der Anzahl der Knoten im Cluster. Wenn das Upgrade länger als das Zeitlimit dauert, ändert sich der Clusterstatus von UPGRADING
zu ERROR
und es wird ein Ereignis angezeigt, das besagt, dass beim Upgrade eine Zeitüberschreitung aufgetreten ist. Der Status ERROR
bedeutet, dass das Upgrade länger als erwartet dauert, aber nicht beendet wurde. Der Controller fährt mit dem Abgleich fort und wiederholt den Vorgang weiter.
In der Regel ist eine Zeitüberschreitung das Ergebnis eines Deadlocks, das durch ein PodDisruptionBudget (PDB) verursacht wird. In diesem Fall können keine Pods aus alten Knoten entfernt und die alten Knoten nicht per Drain beendet werden. Wenn die Pod-Bereinigung länger als 10 Minuten dauert, schreiben wir ein Ereignis in das Objekt „OnPremUserCluster“. Sie können das Ereignis mit gkectl describe clusters
erfassen. Anschließend können Sie das PDB so anpassen, dass der Knoten per Drain beendet wird. Danach kann das Upgrade fortgesetzt und schließlich abgeschlossen werden.
Beispielereignis:
Warning PodEvictionTooLong 96s (x2 over 4m7s) onprem-user-cluster-controller Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.
Wenn ein Upgrade blockiert wird oder fehlschlägt, können Sie außerdem gkectl diagnose
ausführen, um häufige Clusterprobleme zu ermitteln. Auf Grundlage des Ergebnisses können Sie entscheiden, ob Sie eine manuelle Fehlerbehebung ausführen oder sich für weitere Unterstützung an das Anthos-Supportteam wenden möchten.
Synchrones Upgrade
Mit dem Befehl gkectl upgrade
werden Preflight-Prüfungen ausgeführt. Wenn die Preflight-Prüfungen fehlschlagen, wird der Befehl blockiert. Sie müssen die Fehler beheben oder das Flag --skip-preflight-check-blocking
verwenden. Sie sollten die Preflight-Prüfungen nur überspringen, wenn Sie sicher sind, dass keine kritischen Fehler vorliegen.
Führen Sie die folgenden Schritte auf Ihrer Administrator-Workstation aus:
Führen Sie
gkectl prepare
aus, um Betriebssystem-Images in vSphere zu importieren:gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Wenn der Cluster einen Windows-Knotenpool hat, führen Sie
gkectl prepare windows
aus und aktualisieren Sie das FeldosImage
für den Knotenpool. Eine ausführliche Anleitung finden Sie unter Nutzercluster mit Windows-Knotenpools upgraden.Führen Sie das Tool vor dem Upgrade aus, um den Zustand und die Konfiguration des Clusters zu prüfen.
Legen Sie in der Konfigurationsdatei des Nutzerclusters
gkeOnPremVersion
auf die Zielversion Ihres Upgrades fest.Aktualisieren Sie den Cluster:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
Wenn Sie ein Upgrade auf Version 1.14.0 oder höher ausführen, wird für den Nutzercluster eine neue kubeconfig-Datei generiert, die alle vorhandenen Dateien überschreibt. Führen Sie den folgenden Befehl aus, um die Clusterdetails in der Datei anzusehen:
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_FILE \ --skip-validation-all
Administratorcluster aktualisieren
Hinweis
Prüfen Sie, ob Ihre Zertifikate auf dem neuesten Stand sind, und verlängern Sie sie bei Bedarf.
Wenn Sie ein Upgrade auf Version 1.13 oder höher ausführen, müssen Sie zuerst den Administratorcluster registrieren. Füllen Sie dazu in der Konfigurationsdatei des Administratorclusters den Abschnitt
gkeConnect
aus. Führen Sie den Befehl update cluster mit der geänderten Konfigurationsdatei aus.
Führen Sie die Schritte in diesem Abschnitt auf Ihrer neuen Administrator-Workstation aus. 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.
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 upgraden und dann den Befehl update cluster mit den Änderungen der Konfigurationsdatei ausführen, um weitere Änderungen am Cluster vorzunehmen.
Führen Sie das Tool vor dem Upgrade aus, um den Zustand und die Konfiguration des Clusters zu prüfen.
Führen Sie dazu diesen Befehl aus:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE \ FLAGS
Ersetzen Sie Folgendes:
ADMIN_CLUSTER_KUBECONFIG: Die kubeconfig-Datei des Administratorclusters.
ADMIN_CLUSTER_CONFIG_FILE: die Konfigurationsdatei des GKE on VMware-Administratorclusters auf Ihrer neuen Administratorworkstation.
FLAGS: ein optionaler Satz Flags. Sie können beispielsweise das Flag
--skip-validation-infra
einfügen, um die Prüfung der vSphere-Infrastruktur zu überspringen.
Wenn Sie ein Upgrade auf Version 1.14.0 oder höher ausführen, wird für den Administratorcluster eine neue kubeconfig-Datei generiert, die alle vorhandenen Dateien überschreibt. Führen Sie den folgenden Befehl aus, um die Clusterdetails in der Datei anzusehen:
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Wenn Sie ein vollständiges Bundle heruntergeladen haben und die Befehle gkectl prepare
und gkectl upgrade admin
erfolgreich ausgeführt wurden, sollten Sie nun das vollständige Bundle löschen, um Speicherplatz auf der Administrator-Workstation zu sparen. Verwenden Sie diesen Befehl:
rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz
Upgrade eines Administratorclusters fortsetzen
Wenn das Upgrade eines Administratorclusters unterbrochen wird oder fehlschlägt, kann das Upgrade fortgesetzt werden, falls der Prüfpunkt des Administratorclusters den Status enthält, der zur Wiederherstellung des Zustands vor der Unterbrechung erforderlich ist.
Warnung: Reparieren Sie den Admin-Master nach einem fehlgeschlagenen Upgradeversuch nicht mit gkectl repair admin-master
. Dies führt dazu, dass der Administratorcluster in einen fehlerhaften Zustand versetzt wird.
Gehen Sie so vor:
Prüfen Sie, ob die Administratorsteuerungsebene fehlerfrei ist, bevor Sie mit dem ersten Upgradeversuch beginnen. Siehe Clusterprobleme diagnostizieren. Führen Sie wie in diesem Thema beschrieben den Befehl
gkectl diagnose cluster
für den Administratorcluster aus.Wenn die Administratorsteuerungsebene vor dem ersten Upgradefehler fehlerhaft ist, reparieren Sie die Administratorsteuerungsebene mit dem Befehl
gkectl repair admin-master
.Wenn Sie den Upgradebefehl noch einmal ausführen, nachdem ein Upgrade unterbrochen wurde oder fehlgeschlagen ist, verwenden Sie dasselbe Bundle und dieselbe Zielversion wie beim vorherigen Upgradeversuch.
Wenn Sie den Upgradebefehl noch einmal ausführen, wird beim fortgesetzten Upgrade der Status des Administratorclusters am Prüfpunkt neu erstellt und das gesamte Upgrade wird noch einmal ausgeführt. Wenn die Administrator-Steuerungsebene ab Version 1.12.0 fehlerhaft ist, wird der Upgradeprozess direkt auf die Zielversion aktualisiert, ohne zu versuchen, den Administratorcluster in der Quellversion wiederherzustellen, bevor mit dem Upgrade fortgefahren wird.
Das Upgrade wird ab dem Punkt fortgesetzt, an dem es fehlgeschlagen ist oder beendet wurde, sofern der Prüfpunkt des Administratorclusters verfügbar ist. Wenn der Prüfpunkt nicht verfügbar ist, greift das Upgrade auf die Administratorsteuerungsebene zurück. Daher muss die Administratorsteuerungsebene fehlerfrei sein, um mit dem Upgrade fortfahren zu können. Nach einem erfolgreichen Upgrade wird der Prüfpunkt neu generiert.
Wenn gkectl
während eines Upgrade des Administratorclusters unerwartet beendet wird, wird der Typcluster nicht bereinigt. Bevor Sie den Upgradebefehl noch einmal ausführen, um das Upgrade fortzusetzen, löschen Sie den Typcluster:
docker stop gkectl-control-plane && docker rm gkectl-control-plane
Führen Sie nach dem Löschen des Typclusters den Upgradebefehl noch einmal aus.
Rollback einer Administrator-Workstation nach einem Upgrade
Sie können die Administrator-Workstation auf die Version zurücksetzen, die vor dem Upgrade verwendet wurde.
Während des Upgrades erfasst gkeadm
die vor dem Upgrade verwendete Version in der Ausgabeinformationsdatei. Während des Rollbacks verwendet gkeadm
die aufgelistete Version, um die ältere Datei herunterzuladen.
So führen Sie ein Rollback Ihrer Administrator-Workstation auf die vorherige Version durch:
gkeadm rollback admin-workstation --config=AW_CONFIG_FILE
Sie können --config=AW_CONFIG_FILE
weglassen, wenn die Konfigurationsdatei der Administrator-Workstation der Standard-admin-ws-config.yaml
ist. Andernfalls ersetzen Sie AW_CONFIG_FILE durch den Pfad zur Konfigurationsdatei der Administrator-Workstation.
Der Rollback-Befehl führt folgende Schritte aus:
- Die Rollback-Version von
gkeadm
wird heruntergeladen. - Sie sichert das Basisverzeichnis der aktuellen Administrator-Workstation.
- Erstellt eine neue Administrator-Workstation mit der Rollback-Version von
gkeadm
. - Löscht die ursprüngliche Administrator-Workstation.
Bundle mit einer anderen Version für das Upgrade installieren
Wenn Sie ein Upgrade Ihrer Workstation durchführen, wird dort ein Bundle mit einer entsprechenden Version installiert. Wenn Sie eine andere Version verwenden möchten, führen Sie die folgenden Schritte aus, um ein Bundle für TARGET_VERSION zu installieren. Dies ist die Version, auf die Sie ein Upgrade ausführen möchten.
Führen Sie den folgenden Befehl aus, um die aktuelle
gkectl
und die Clusterversionen zu prüfen. Mit dem Flag--details/-d
erhalten Sie genauere Informationen.gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
Die Ausgabe enthält Informationen zu Ihren Clusterversionen.
Prüfen Sie anhand der ausgegebenen Ausgabe, ob folgende Probleme vorliegen, und beheben Sie sie gegebenenfalls.
Wenn die aktuelle Version des Administratorclusters um mehr als eine Nebenversion tiefer als die TARGET_VERSION ist, aktualisieren Sie alle Cluster auf genau eine Nebenversion tiefer als TARGET_VERSION.
Wenn die
gkectl
-Version niedriger als 1.11 ist und Sie ein Upgrade auf 1.12.x durchführen möchten, müssen Sie mehrere Upgrades ausführen. Upgraden Sie jeweils eine Nebenversion auf einmal bis Sie zu 1.11.x gelangen und fahren Sie dann mit der Anleitung in diesem Thema fort.Wenn die
gkectl
-Version niedriger als TARGET_VERSION ist, aktualisieren Sie die Administrator-Workstation auf TARGET_VERSION.
Wenn Sie festgestellt haben, dass die
gkectl
- und Clusterversionen für ein Upgrade geeignet sind, laden Sie das Bundle herunter.Prüfen Sie, ob das Bundle-Tarball bereits auf der Administrator-Workstation vorhanden ist.
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
Wenn sich das Bundle nicht auf der Administrator-Workstation befindet, laden Sie es herunter.
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
Installieren Sie das Bundle.
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad Ihrer kubeconfig-Datei. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet und den Namen
kubeconfig
hat.Listen Sie die verfügbaren Clusterversionen auf und prüfen Sie, ob die Zielversion in den verfügbaren Nutzerclusterversionen enthalten ist.
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
Sie können jetzt einen Nutzercluster in der Zielversion erstellen oder einen Nutzercluster auf die Zielversion aktualisieren.
Fehlerbehebung beim Upgrade
Sollten bei der empfohlenen Umstellung Probleme auftreten, beachten Sie bitte diese Empfehlungen, um sie zu beheben. Diese Vorschläge setzen voraus, dass Sie mit der Version 1.11.x.-Einrichtung begonnen haben und das empfohlene Upgrade-Verfahren durchlaufen.
Siehe auch Fehlerbehebung beim Erstellen und Upgraden von Clustern.
Fehlerbehebung bei Problemen mit dem Nutzercluster-Upgrade
Angenommen, Sie finden beim Upgraden eines Nutzerclusters ein Problem mit der Upgradeversion. Sie stellen fest, dass das Problem in einer zukünftigen Patchversion behoben wird. Gehen Sie dazu so vor:
- Für die Produktion verwenden Sie weiterhin die aktuelle Version.
- Testen Sie den Patchrelease in einem Nicht-Produktionscluster, wenn er veröffentlicht wird.
- Aktualisieren Sie alle Produktionsnutzercluster auf die Patchrelease-Version, wenn Sie sicher sind.
- Aktualisieren Sie den Administratorcluster auf die Patchrelease-Version.
Fehlerbehebung bei Problemen mit dem Upgrade eines Administratorclusters
Wenn beim Upgrade des Administratorclusters ein Problem auftritt, wenden Sie sich bitte an den Google-Support, um das Problem mit dem Administratorcluster zu beheben.
Mit dem neuen Upgrade-Ablauf können Sie weiterhin von neuen Nutzerclusterfunktionen profitieren, ohne von der Aktualisierung des Administratorclusters zu profitieren. So können Sie die Upgradehäufigkeit des Administratorclusters bei Bedarf verringern. Das Upgrade kann so ausgeführt werden:
- Führen Sie ein Upgrade der Produktionsnutzercluster auf 1.12.x durch.
- Behalten Sie die frühere Version des Administratorclusters bei und erhalten Sie weiterhin Sicherheitspatches.
- Testen Sie das Upgrade des Administratorclusters in einer Testumgebung von 1.11.x auf 1.12.x und melden Sie Probleme, falls vorhanden.
- Wenn das Problem durch eine Patch-Version 1.12.x behoben wurde, können Sie den Produktions-Administratorcluster auf diese Patch-Version aktualisieren, falls gewünscht.
Bekannte Probleme bei aktuellen Versionen
Die folgenden bekannten Probleme können Auswirkungen auf Upgrades haben, wenn Sie ein Upgrade von Version 1.7 oder höher ausführen.
Weitere Informationen finden Sie im Hilfeartikel Bekannte Probleme.
Das Upgrade der Administrator-Workstation kann fehlschlagen, wenn das Datenlaufwerk fast voll ist
Wenn Sie die Administrator-Workstation mit dem Befehl gkectl upgrade admin-workstation
aktualisieren, schlägt das Upgrade möglicherweise fehl, wenn das Datenlaufwerk fast voll ist. Dies liegt daran, dass das System versucht, die aktuelle Administrator-Workstation lokal zu sichern, während ein Upgrade auf eine neue Administrator-Workstation durchgeführt wird. Wenn Sie nicht genügend Speicherplatz auf dem Datenlaufwerk löschen können, verwenden Sie den Befehl gkectl upgrade admin-workstation
mit dem zusätzlichen Flag --backup-to-local=false
, um eine lokale Sicherung der aktuellen Administrator-Workstation zu verhindern.
Unterbrechung für Arbeitslasten mit PodDisauseBudgets
Derzeit kann das Upgrade von Clustern zu Unterbrechungen oder Ausfallzeiten bei Arbeitslasten führen, die PodDisruptionBudgets (PDBs) verwenden.
Knoten schließen ihren Upgradeprozess nicht ab
Wenn Sie PodDisruptionBudget
-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment
oder HorizontalPodAutoscaler
, damit der Knoten unter Berücksichtigung der PodDisruptionBudget
-Konfiguration entleert wird.
So rufen Sie alle PodDisruptionBudget
-Objekte auf, die keine Störungen zulassen:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Anhang
Informationen zu den in Version 1.1.0-gke.6 aktivierten DRS-Regeln von VMware
Ab Version 1.1.0-gke.6 erstellt GKE on VMware automatisch die DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) von VMware für die Knoten Ihres Nutzerclusters, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden. Ab Version 1.1.0-gke.6 wird diese Funktion automatisch für neue und vorhandene Cluster aktiviert.
Prüfen Sie vor dem Upgrade, ob Ihre vSphere-Umgebung die folgenden Bedingungen erfüllt:
VMware DRS ist aktiviert. Für VMware DRS ist die vplaner Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter VMware DRS in einem Cluster aktivieren.
Der in der Datei mit den Anmeldedatenkonfiguration angegebene vSphere-Nutzername hat die Berechtigung
Host.Inventory.EditCluster
.Es sind mindestens drei physische Hosts verfügbar.
Wenn Ihre vSphere-Umgebung nicht die vorherigen Bedingungen erfüllt, können Sie trotzdem ein Upgrade ausführen. Wenn Sie jedoch einen Nutzercluster von 1.3.x auf 1.4.x aktualisieren möchten, müssen Sie Anti-Affinitätsgruppen deaktivieren. Weitere Informationen finden Sie in diesem bekannten Problem in den Versionshinweisen zu GKE on VMware.
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. |
Nutzerclusterknoten | Wenn für ein Upgrade eine Änderung an den Nutzerclusterknoten erforderlich ist, werden die Knoten von GKE on VMware rollierend neu erstellt und die auf diesen Knoten ausgeführten Pods neu geplant. Sie können Auswirkungen auf Ihre Arbeitslasten verhindern, wenn Sie die entsprechenden PodDisruptionBudgets und Anti-Affinitätsregeln konfigurieren. |
Neuerstellung einer Informationsdatei, falls sie fehlt
Wenn die Ausgabeinformationsdatei für Ihre Administrator-Workstation fehlt, müssen Sie diese Datei neu erstellen, damit Sie mit dem Upgrade fortfahren können. Diese Datei wurde bei der anfänglichen Erstellung Ihrer Workstation erstellt. Wenn Sie seitdem ein Upgrade ausgeführt haben, wurde sie mit neuen Informationen aktualisiert.
Die Datei mit den Ausgabeinformationen hat folgendes Format:
Admin workstation version: GKEADM_VERSION Created using gkeadm version: GKEADM_VERSION VM name: ADMIN_WS_NAME IP: ADMIN_WS_IP SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY To access your admin workstation: ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP
Hier sehen Sie ein Beispiel für eine Ausgabeinformationsdatei:
Admin workstation version: v1.10.3-gke.49 Created using gkeadm version: v1.10.3-gke.49 VM name: admin-ws-janedoe IP: 172.16.91.21 SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation Upgraded from (rollback version): v1.10.0-gke.194 To access your admin workstation: ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21
Erstellen Sie die Datei in einem Editor und ersetzen Sie die entsprechenden Parameter. Speichern Sie die Datei mit einem Dateinamen, der mit dem VM-Namen in dem Verzeichnis übereinstimmt, in dem gkeadm ausgeführt wird. Wenn der VM-Name beispielsweise admin-ws-janedoe
lautet, speichern Sie die Datei als admin-ws-janedoe
.