Anthos-Cluster auf VMware aktualisieren

Auf dieser Seite wird erläutert, wie Sie Anthos-Cluster auf VMware (GKE On-Prem) aktualisieren.

Ü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. Beispielsweise können Sie ein Upgrade von Version 1.11.0 auf 1.11.1 oder von 1.10.1 auf 1.11.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 ein Upgrade von Version 1.9.2 auf Version 1.11.0 ausführen, so ist dieses direkte Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.9.2 auf Version 1.10.x und dann ein Upgrade auf Version 1.11.0 ausführen.

In diesem Thema wird erläutert, wie Sie ein Upgrade von Version 1.10.x oder 1.11.x auf Version 1.11.y durchführen.

Nachfolgend ist der allgemeine Workflow für das Upgraden dargestellt.

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

  2. Installieren Sie auf Ihrer Administrator-Workstation das Bundle, das Sie zum Aktualisieren der Cluster verwenden.

  3. Führen Sie ein Upgrade Ihrer Nutzercluster über Ihre Administrator-Workstation durch.

  4. Nachdem alle Nutzercluster aktualisiert wurden, können Sie den Administratorcluster über die Administrator-Workstation aktualisieren. Dieser Schritt ist optional, es sei denn, Sie benötigen die im Upgrade verfügbaren Features.

Auf Upgrade vorbereiten

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 aktuellen 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

Planen Sie Ihre Strategie auch hinsichtlich der Ausfallzeiten, die durch das Upgrade verursacht werden. Siehe Ausfallzeit bei Upgrades.

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

  1. Führen Sie diesen Befehl aus, um die angegebene gkeadm-Version herunterzuladen:

    gkeadm upgrade gkeadm --target-version TARGET_VERSION

    Ersetzen Sie TARGET_VERSION durch die Version, die Sie herunterladen möchten.

  2. Führen Sie den folgenden Befehl aus, um das Upgrade abzuschließen:

    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.

  • 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

Achten Sie vor dem Upgrade Ihrer Cluster darauf, dass Sie genügend IP-Adressen zugewiesen haben. Sie können zusätzliche IP-Adressen bei Bedarf reservieren, wie für die einzelnen DHCP- und statischen IP-Adressen beschrieben. Wenn Sie mehr als einen Knotenpool haben, sollten Sie auch eine zusätzliche IP-Adresse für jeden Knotenpool haben, um das Upgrade zu erleichtern.

Unter Knoten-IP-Adressen verwalten können Sie nachlesen, wie Sie berechnen, wie viele IP-Adressen Sie benötigen.

Bundle für Upgrade prüfen

Wenn Sie ein Upgrade für Ihre Administrator-Workstation durchgeführt haben, befindet sich die entsprechende Bundle-Version für das Upgrade Ihrer Cluster auf der Workstation.

Wenn Sie eine andere Version als die Version der Administrator-Workstation verwenden möchten, müssen Sie das entsprechende Bundle manuell installieren. Siehe Bundle für Upgrade installieren.

Nutzercluster aktualisieren

Befehlszeile

Beachten Sie Folgendes, bevor Sie mit dem Upgrade fortfahren:

  • 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. Sie sollten die Preflight-Prüfungen nur überspringen, wenn Sie sicher sind, dass keine Fehler existieren.

  • Ab Version 1.10 enthält Anthos-Cluster auf VMware den konnectivityServerNodePort für den manuellen Load-Balancer. Sie müssen einen geeigneten Wert für diesen Knotenport angeben, den Load-Balancer mit diesem Knotenport konfigurieren und diesen neuen Knotenport in der Konfigurationsdatei hinzufügen, bevor Sie ein Upgrade ausführen. Siehe manuelles Load-Balancing.

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

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

  2. Achten Sie darauf, dass das Feld gkeOnPremVersion in der Konfigurationsdatei des Nutzerclusters der Version entspricht, auf die Sie ein Upgrade ausführen möchten.

    Wenn Sie weitere Änderungen an den Feldern in der Konfigurationsdatei des Administratorclusters oder der Konfigurationsdatei des Nutzerclusters 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.

  3. Installieren Sie das Bundle aus dem angegebenen Verzeichnis im Cluster.

    gkectl prepare \
 --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
 --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Die kubeconfig-Datei des Administratorclusters.

  4. Führen Sie ein Upgrade mit dem folgenden Befehl durch.

    gkectl upgrade cluster \
 --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
 --config USER_CLUSTER_CONFIG_FILE \
 FLAGS

    Ersetzen Sie Folgendes:

    • USER_CLUSTER_CONFIG_FILE ist die Konfigurationsdatei des Anthos-Cluster auf VMware-Nutzerclusters auf Ihrer neuen Administrator-Workstation.

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

Console

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

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --upgrade-platform

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG ist der Pfad zur kubeconfig-Datei des Administratorclusters.

    Dieser Befehl aktualisiert die Richtlinien für den Nutzercluster-Controller und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), mit denen die Google Cloud Console den Nutzercluster verwalten kann.

  2. Rufen Sie in der Google Cloud Console die Anthos-Seite Cluster auf.

    Zur Seite "Anthos-Cluster"

  3. Wählen Sie das Google Cloud-Projekt aus, in dem sich der Nutzercluster befindet.

  4. Klicken Sie in der Liste der Cluster auf den Cluster, den Sie upgraden möchten.

  5. Wenn der Typ im Bereich Details auf VM Anthos (VMware) eingestellt ist, führen Sie die folgenden Schritte aus, um den Cluster mithilfe der Google Cloud Console zu löschen:

    1. Klicken Sie im Bereich Details auf Weitere Details.

    2. Klicken Sie im Abschnitt Clustergrundlagen auf Upgrade.

    3. Wählen Sie in der Liste Anthos-Cluster in VMware-Version die Version aus, auf die Sie upgraden möchten.

    4. Klicken Sie auf Upgrade.

    Wenn der Typ auf extern eingestellt ist, bedeutet dies, dass der Cluster mit gkectl erstellt wurde. Führen Sie in diesem Fall die Schritte auf dem Tab Befehlszeile aus, um den Cluster zu aktualisieren.

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

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.

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

  2. 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 ist die Konfigurationsdatei des Anthos-Cluster auf VMware-Administratorclusters auf Ihrer neuen Administrator-Workstation.

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

  3. Führen Sie nach dem Upgrade des Administratorclusters den folgenden Befehl aus, um zu prüfen, ob das Feld component-access-sa-key im Secret admin-cluster-creds gelöscht wurde:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds | grep 'component-access-sa-key'

    Wenn die Ausgabe leer ist, führen Sie den nächsten Befehl aus, um component-access-sa-key wieder hinzuzufügen:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

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.

Gehen Sie so vor:

  1. Prüfen Sie, ob die Administratorsteuerungsebene fehlerfrei ist, bevor Sie mit dem ersten Upgradeversuch beginnen. Siehe Clusterprobleme diagnostizieren. Führen Sie wie in diesem Thema beschrieben den Befehl gkectl diagnose cluster für den Administratorcluster aus.

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

  3. Wenn Sie den Upgradebefehl noch einmal ausführen, nachdem ein Upgrade unterbrochen wurde oder fehlgeschlagen ist, verwenden Sie dasselbe Bundle und dieselbe Zielversion wie beim vorherigen Upgradeversuch.

Wenn Sie den Upgradebefehl noch einmal ausführen, erstellt das fortgesetzte Upgrade den Status im Typcluster vom Prüfpunkt neu und führt das gesamte Upgrade noch einmal aus. Wenn die Administrator-Steuerungsebene fehlerhaft ist, wird sie zuerst wiederhergestellt, bevor ein Upgrade durchgeführt wird.

Das Upgrade wird ab dem Punkt fortgesetzt, an dem es fehlgeschlagen ist oder beendet wurde, sofern der Prüfpunkt des Administratorclusters verfügbar ist. Wenn der Prüfpunkt nicht verfügbar ist, greift das Upgrade auf die Administratorsteuerungsebene zurück. Daher muss die Administratorsteuerungsebene fehlerfrei sein, um mit dem Upgrade fortfahren zu können. Nach einem erfolgreichen Upgrade wird der Prüfpunkt neu generiert.

Wenn gkectl während eines Upgrade des Administratorclusters unerwartet beendet wird, wird der Typcluster nicht bereinigt. Bevor Sie den Upgradebefehl noch einmal ausführen, um das Upgrade fortzusetzen, löschen Sie den Typcluster:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Führen Sie nach dem Löschen des Typclusters den Upgradebefehl noch einmal aus.

Rollback einer Administrator-Workstation nach einem Upgrade

Sie können die Administrator-Workstation auf die Version zurücksetzen, die vor dem Upgrade verwendet wurde.

Während des Upgrades erfasst gkeadm die vor dem Upgrade verwendete Version in der Ausgabeinformationsdatei. Während des Rollbacks verwendet gkeadm die aufgelistete Version, um die ältere Datei herunterzuladen.

So führen Sie ein Rollback Ihrer Administrator-Workstation auf die vorherige Version durch:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Sie können --config=AW_CONFIG_FILE weglassen, wenn die Konfigurationsdatei der Administrator-Workstation der Standard-admin-ws-config.yaml ist. Andernfalls ersetzen Sie AW_CONFIG_FILE durch den Pfad zur Konfigurationsdatei der Administrator-Workstation.

Der Rollback-Befehl führt folgende Schritte aus:

  1. Die Rollback-Version von gkeadm wird heruntergeladen.
  2. Sie sichert das Basisverzeichnis der aktuellen Administrator-Workstation.
  3. Erstellt eine neue Administrator-Workstation mit der Rollback-Version von gkeadm.
  4. Löscht die ursprüngliche Administrator-Workstation.

Bundle mit einer anderen Version für das Upgrade installieren

Wenn Sie ein Upgrade Ihrer Workstation durchführen, wird dort ein Bundle mit einer entsprechenden Version installiert. Wenn Sie eine andere Version verwenden möchten, führen Sie die folgenden Schritte aus, um ein Bundle für TARGET_VERSION zu installieren. Dies ist die Version, auf die Sie ein Upgrade ausführen möchten.

  1. Führen Sie den folgenden Befehl aus, um die aktuelle gkectl und die Clusterversionen zu prüfen. Mit dem Flag --details/-d erhalten Sie genauere Informationen.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

    Die Ausgabe enthält Informationen zu Ihren Clusterversionen.

  2. Prüfen Sie anhand der ausgegebenen Ausgabe, ob folgende Probleme vorliegen, und beheben Sie sie gegebenenfalls.

    • Wenn die aktuelle Version des Administratorclusters um mehr als eine Nebenversion tiefer als die TARGET_VERSION ist, aktualisieren Sie alle Cluster auf genau eine Nebenversion tiefer als TARGET_VERSION.

    • Wenn die gkectl-Version niedriger als 1.10 ist und Sie ein Upgrade auf 1.11.x durchführen möchten, müssen Sie mehrere Upgrades ausführen. Upgraden Sie jeweils eine Nebenversion auf einmal bis Sie zu 1.10.x gelangen und fahren Sie dann mit der Anleitung in diesem Thema fort.

    • Wenn die gkectl-Version niedriger als TARGET_VERSION ist, aktualisieren Sie die Administrator-Workstation auf TARGET_VERSION.

  3. Wenn Sie festgestellt haben, dass die gkectl- und Clusterversionen für ein Upgrade geeignet sind, laden Sie das Bundle herunter.

    Prüfen Sie, ob das Bundle-Tarball bereits auf der Administrator-Workstation vorhanden ist.

    stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

    Wenn sich das Bundle nicht auf der Administrator-Workstation befindet, laden Sie es herunter. 

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

  4. Installieren Sie das Bundle.

    gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad Ihrer kubeconfig-Datei. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet und den Namen kubeconfig hat.

  5. Listen Sie die verfügbaren Clusterversionen auf und prüfen Sie, ob die Zielversion in den verfügbaren Nutzerclusterversionen enthalten ist.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Sie können jetzt einen Nutzercluster in der Zielversion erstellen oder einen Nutzercluster auf die Zielversion aktualisieren.

Fehlerbehebung beim Upgrade

Sollten bei der empfohlenen Umstellung Probleme auftreten, beachten Sie bitte diese Empfehlungen, um sie zu beheben. Diese Vorschläge setzen voraus, dass Sie mit der Einrichtung von Version 1.10.x begonnen haben und das empfohlene Upgrade-Verfahren durchlaufen.

Siehe auch Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Fehlerbehebung bei Problemen mit dem Nutzercluster-Upgrade

Angenommen, Sie finden beim Upgraden eines Nutzerclusters ein Problem mit der Upgradeversion. Sie stellen fest, dass das Problem in einer zukünftigen Patchversion behoben wird. Gehen Sie dazu so vor:

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

Fehlerbehebung bei Problemen mit dem Upgrade eines Administratorclusters

Wenn beim Upgrade des Administratorclusters ein Problem auftritt, wenden Sie sich bitte an den Google-Support, um das Problem mit dem Administratorcluster zu beheben.

Mit dem neuen Upgrade-Ablauf können Sie weiterhin von neuen Nutzerclusterfunktionen profitieren, ohne von der Aktualisierung des Administratorclusters zu profitieren. So können Sie die Upgradehäufigkeit des Administratorclusters bei Bedarf verringern. Das Upgrade kann so ausgeführt werden:

  1. Führen Sie ein Upgrade der Produktionsnutzercluster auf 1.11.x durch.
  2. Behalten Sie die frühere Version des Administratorclusters bei und erhalten Sie weiterhin Sicherheitspatches.
  3. Testen Sie das Upgrade des Administratorclusters von 1.10.x auf 1.11.x in einer Testumgebung und melden Sie Probleme, falls vorhanden.
  4. Wenn das Problem durch eine Patch-Version 1.11.x behoben wurde, können Sie den Produktions-Administratorcluster auf diese Patch-Version aktualisieren, falls gewünscht.

Bekannte Probleme bei aktuellen Versionen

Die folgenden Probleme und Beschränkungen können sich auf Cloud CDN auswirken:

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 Anthos-Cluster auf VMware 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:

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 Anthos-Clustern auf VMware 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.
Nutzerclusterknoten

Wenn für ein Upgrade eine Änderung der Nutzerclusterknoten erforderlich macht, werden die Knoten von Anthos-Clustern auf VMware schrittweise 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.