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.8.0 auf 1.8.3 oder von 1.8.1 auf 1.9.0 durchfü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.7.2 auf Version 1.9.0 durchführen, ist ein direktes Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.7.2 auf Version 1.8.x und dann ein Upgrade auf Version 1.9.0 durchführen.

Führen Sie zuerst ein Upgrade der Administrator-Workstation, der Nutzercluster und dann des Administratorclusters durch. Sie müssen den Administratorcluster nicht unmittelbar nach dem Upgrade der Nutzercluster aktualisieren, wenn Sie den Administratorcluster auf der aktuellen Version beibehalten möchten.

  1. Laden Sie das gkeadm-Tool herunter. Die Version von gkeadm muss mit der Zielversion Ihres Upgrades übereinstimmen.
  2. Führen Sie ein Upgrade Ihrer Administrator-Workstation durch.
  3. Führen Sie ein Upgrade Ihrer Nutzercluster über Ihre Administrator-Workstation durch.
  4. Führen Sie über Ihre Administrator-Workstation ein Upgrade Ihres Administratorclusters aus.

Angenommen, Ihre Administrator-Workstation, Ihr Administratorcluster und Ihre Nutzercluster verwenden derzeit Version 1.8.x und Sie möchten sowohl Ihren Administratorcluster als auch Ihre Nutzercluster auf Version 1.9.x aktualisieren. Wenn Sie einem Upgradepfad wie dem folgenden folgen, mit einem Canary-Cluster für Tests, bevor Sie fortfahren, verringern Sie das Risiko einer Unterbrechung.

Im Folgenden finden Sie eine allgemeine Übersicht über einen empfohlenen Upgradeprozess. Erstellen Sie zuerst einen Canary-Nutzercluster mit der Version 1.8.x, falls noch nicht geschehen.

  1. Testen Sie Version 1.9.x in einem Canary-Cluster.
    • Führen Sie ein Upgrade der Administrator-Workstation auf Version 1.9.x durch.
    • Führen Sie wie nachfolgend beschrieben den Befehl gkectl prepare aus, um das Upgrade einzurichten.
    • Aktualisieren Sie den Canary-Nutzercluster auf Version 1.9.x.
  2. Aktualisieren Sie alle Produktionsnutzercluster auf Version 1.9.x, wenn Sie sich mit Version 1.9.x auskennen.
  3. Führen Sie ein Upgrade des Administratorclusters auf Version 1.9.x durch.

Ihre Konfigurations- und Informationsdateien finden, um sie für das Upgrade vorzubereiten

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.

Außerdem hat gkeadm eine Informationsdatei für Sie erstellt. 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, um die Schritte in dieser Anleitung ausführen zu können. 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.

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.

Upgrade für die Administrator-Workstation ausführen

Achten Sie darauf, dass gkectl und Ihre Cluster in der entsprechenden Versionsebene für ein Upgrade sind und das entsprechende Bundle heruntergeladen haben.

Führen Sie folgenden Befehl aus: 

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

Dabei gilt:

  • [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:

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

  • Erstellen Sie eine neue Administrator-Workstation und kopieren Sie alle gesicherten Dateien auf die neue Administrator-Workstation.

  • Löschen Sie die alte Administrator-Workstation.

Verfügbarkeit ausreichender IP-Adressen prüfen

Führen Sie die Schritte in diesem Abschnitt auf Ihrer neuen Administrator-Workstation aus.

Achten Sie vor dem Upgrade darauf, dass genügend IP-Adressen für Ihre Cluster verfügbar sind. Sie können zusätzliche IP-Adressen bei Bedarf reservieren, wie für die einzelnen DHCP- und statischen IP-Adressen beschrieben.

DHCP

Wenn Sie den Administratorcluster aktualisieren, erstellen Anthos-Cluster auf VMware einen temporären Knoten im Administratorcluster. Wenn Sie einen Nutzercluster aktualisieren, erstellen Anthos-Cluster auf VMware einen temporären Knoten in diesem Nutzercluster. Der Zweck des temporären Knotens besteht darin, eine unterbrechungsfreie Verfügbarkeit sicherzustellen. Achten Sie vor dem Upgrade eines Clusters darauf, dass Ihr DHCP-Server genügend IP-Adressen für den temporären Knoten bereitstellen kann. Weitere Informationen finden Sie unter Erforderliche IP-Adressen für Administrator- und Nutzercluster.

Statische IP-Adressen

Wenn Sie den Administratorcluster aktualisieren, erstellen Anthos-Cluster auf VMware einen temporären Knoten im Administratorcluster. Wenn Sie einen Nutzercluster aktualisieren, erstellen Anthos-Cluster auf VMware einen temporären Knoten in diesem Nutzercluster. Der Zweck des temporären Knotens besteht darin, eine unterbrechungsfreie Verfügbarkeit sicherzustellen. Prüfen Sie vor dem Upgrade eines Clusters, ob Sie genügend IP-Adressen reserviert haben. Für jeden Cluster müssen Sie mindestens eine weitere IP-Adresse reservieren als die Anzahl der Clusterknoten. 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.

So fügen Sie dem Administratorcluster ab Version 1.7 IP-Adressen hinzu:

Bearbeiten Sie zuerst die IP-Blockdatei, wie in diesem Beispiel gezeigt.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

Führen Sie als Nächstes diesen Befehl aus, um die Konfiguration zu aktualisieren.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]

  • [ADMIN_CLUSTER_KUBECONFIG] ist der Pfad Ihrer kubeconfig-Datei.

  • [ADMIN_CONFIG_FILE] ist der Pfad Ihrer Administrator-Konfigurationsdatei. Sie können dieses Flag auslassen, wenn sich die Datei im aktuellen Verzeichnis befindet und den Namen admin-config.yaml hat.

Sie können keine IP-Adressen entfernen, sondern nur IP-Adressen hinzufügen.

In Versionen vor Version 1.7 können Sie eine zusätzliche Adresse hinzufügen, indem Sie das Clusterobjekt direkt bearbeiten.

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

Wichtig: Ab 1.5.0 funktioniert das selbe Verfahren nicht für Nutzercluster und Sie müssen für jeden Cluster gkectl update cluster verwenden.

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

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

Dabei ist [USER_CLUSTER_KUBECONFIG] der Pfad der kubeconfig-Datei Ihres Nutzerclusters.

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.

Die Anzahl der reservierten IP-Adressen sollte mindestens eine mehr als die Anzahl der Knoten im Nutzercluster betragen. Wenn dies nicht der Fall ist, können Sie die IP-Blockdatei des Nutzerclusters zur Bearbeitung öffnen:

  • Wenn eine der für einen Nutzercluster reservierten Adressen in der IP-Blockdatei enthalten ist, fügen Sie sie zum entsprechenden Block basierend auf netmask und gateway hinzu.

  • Fügen Sie dem entsprechenden Block nach Bedarf weitere statische IP-Adressen hinzu und führen Sie dann gkectl update cluster aus.

Bundle für Upgrade installieren

Sie müssen das entsprechende Bundle installieren, um eine Version zum Erstellen oder Aktualisieren von Clustern verfügbar zu machen. Folgen Sie diesen Schritten, um ein Bundle für TARGET_VERSION zu installieren. Dies ist die Anzahl der Version, auf die Sie ein Upgrade durchfü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

Hier ein Beispiel für eine Ausgabe: 

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

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

  • Wenn die gkectl-Version niedriger als 1.7 ist, ist der neue Upgrade-Vorgang nicht direkt verfügbar. Befolgen Sie den ursprünglichen Upgradeprozess, um alle Ihre Cluster auf 1.6 zu aktualisieren, und führen Sie dann ein Upgrade Ihrer Administrator-Workstation auf 1.7 durch, um mit dem neuen Upgrade-Prozess zu beginnen.

  • Wenn die Version des aktuellen Administratorclusters höher als die Nebenversion von TARGET_VERSION ist, aktualisieren Sie alle Cluster auf eine Nebenversion von TARGET_VERSION.

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

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

Dabei gilt:

  • [ADMIN_CLUSTER_KUBECONFIG] ist der 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.

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.

Upgrade für Nutzercluster durchführen

Führen Sie die Schritte in diesem Abschnitt auf Ihrer neuen Administrator-Workstation aus.

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

Dabei gilt:

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

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

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

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 upgraden

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.

Die Zielversion Ihres Upgrades darf nicht höher als die gkectl-Version und höchstens eine Nebenversion unter Ihrer gkectl-Version sein. Wenn Ihre gkectl-Version also 1.7 ist, kann die Zielversion Ihres Upgrades 1.6.x auf 1.7 sein. Der Administratorcluster kann nur auf eine Nebenversion aktualisiert werden, wenn alle Nutzercluster auf diese Nebenversion aktualisiert wurden. Wenn Sie beispielsweise versuchen, den Administratorcluster auf Version 1.7 zu aktualisieren, und es immer noch 1.6.2 Nutzercluster gibt, erhalten Sie eine Fehlermeldung:

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

Führen Sie dazu diesen Befehl aus:

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

Dabei gilt:

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

  • [ADMIN_CLUSTER_CONFIG_FILE] ist die Konfigurationsdatei des Anthos-Cluster auf VMware-Administratorclusters auf Ihrer neuen Administrator-Workstation.

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

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

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.

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.6.2.-Einrichtung begonnen haben und das empfohlene Upgrade-Verfahren durchlaufen.

Fehlerbehebung bei Problemen mit dem Nutzercluster-Upgrade

Angenommen, Sie testen beim Testen des Canary-Clusters ein Problem mit 1.7 oder führen ein Upgrade für einen Nutzercluster durch. Sie stellen fest, dass das Problem in einer zukünftigen Patchversion 1.7.x behoben wird. Gehen Sie dazu so vor:

  1. Verwenden Sie weiterhin 1.6.2 für die Produktion.
  2. Testen Sie die Releaseversion 1.7.x in einem Canary-Cluster, sobald diese veröffentlicht wird.
  3. Führen Sie ein Upgrade aller Cluster für Produktionsnutzer auf 1.7.x durch, wenn Sie sicher sind.
  4. Aktualisieren Sie den Administratorcluster auf 1.7.x.

Verwalten eines 1.6.x-Patch-Releases beim Testen von 1.7

Angenommen, Sie testen oder migrieren zu Version 1.7, sind aber noch nicht damit überzeugt. Für Ihren Administratorcluster wird weiterhin Version 1.6.2 verwendet. Sie stellen fest, dass eine signifikante Version 1.6.x veröffentlicht wurde. Wenn Sie weiterhin 1.6.x-Patch testen, können Sie weiterhin die Version 1.7 testen. Gehen Sie so vor:

  1. Installieren Sie das Bundle 1.6.x-gke.0.
  2. Führen Sie ein Upgrade für alle Cluster der Produktionsnutzercluster 1.6.2 auf 1.6.x durch.
  3. Aktualisieren Sie den Administratorcluster auf 1.6.x.

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. Sie können beispielsweise den in Version 1.7 veröffentlichten Container-Optimized OS-Knotenpool verwenden. Das Upgrade kann so ausgeführt werden:

  1. Führen Sie ein Upgrade von Produktions-Nutzerclustern auf 1.7 durch.
  2. Behalten Sie den Administratorcluster bei Version 1.6 und erhalten Sie weiterhin Sicherheitspatches.
  3. Testen Sie das Upgrade des Administratorclusters in einer Testumgebung von 1.6 auf 1.7 und melden Sie Probleme, falls vorhanden.
  4. Wenn das Problem durch eine Patch-Version 1.7 behoben wurde, können Sie den Produktions-Administratorcluster auf den Stand von Version 1.6 auf diese Version 1.7 aktualisieren.

Bekannte Probleme

Die folgenden bekannten Probleme betreffen das Aktualisieren von Clustern.

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

Version 1.7.0: Änderungen bei Anthos Config Management-Updates

In Versionen, die älter als 1.7.0 sind, enthalten Anthos-Cluster in VMware die Images, die zum Installieren und Upgrade von Anthos Config Management erforderlich sind. Ab Version 1.7.0 ist die Software von Anthos Config Management nicht mehr im Anthos-Cluster auf VMware-Bundle enthalten, sondern müssen separat hinzugefügt werden. Wenn Sie zuvor Anthos Config Management für einen Cluster oder Cluster verwendet haben, wird die Software erst nach einem Upgrade aktualisiert.

Weitere Informationen zur Installation von Anthos Config Management finden Sie unter Anthos Config Management installieren.

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 Anthos-Cluster auf VMware 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 für Anthos-Cluster.

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

Eine Anleitung finden Sie in den Versionshinweisen für Anthos-Cluster.

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 für Anthos-Cluster.

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

Ausfallzeit

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.

Bekannte Probleme

Siehe Bekannte Probleme.

Problembehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.