Anthos-Cluster auf VMware aktualisieren

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

Zielversionen

Ab Anthos-Cluster auf VMware-Version 1.3.2 können Sie direkt ein Upgrade auf jede Version ausführen, die sich im gleichen Nebenversion oder im nächsten Nebenversion befindet. Beispielsweise können Sie ein Upgrade von Version 1.3.2 auf 1.3.5 oder von 1.5.2 auf 1.6.1 durchführen.

Wenn Ihre aktuelle Version niedriger als 1.3.2 ist, müssen Sie sequenzielle Upgrades ausführen, um zuerst Version 1.3.2 zu erreichen. Wenn Sie beispielsweise ein Upgrade von 1.3.0 auf Version 1.3.2 durchführen möchten, müssen Sie zuerst ein Upgrade von 1.3.0 auf 1.3.1 und dann von 1.3.1 auf 1.3.2 durchführen.

Wenn Sie ein Upgrade von Version 1.3.2 oder höher auf eine Version durchführen, die nicht Teil der nächsten Nebenversion ist, müssen Sie ein Upgrade für jede Nebenversion einer aktuellen Version und der gewünschten Version durchführen. Wenn Sie beispielsweise ein Upgrade von Version 1.3.2 auf Version 1.6.1 durchführen, ist ein direktes Upgrade nicht möglich. Sie müssen zuerst ein Upgrade von Version 1.3.2 auf Version 1.4.x ausführen, wobei x für jede Patch-Version dieser Nebenversion steht. Anschließend können Sie ein Upgrade auf Version 1.5.x und schließlich auf Version 1.6.1 durchführen.

Übersicht über den Upgradevorgang

  1. Laden Sie das gkeadm-Tool herunter. Die Version von gkeadm muss mit der Zielversion Ihres Upgrades übereinstimmen.

  2. Verwenden Sie gkeadm, um die Administrator-Workstation zu aktualisieren.

  3. Führen Sie über Ihre Administrator-Workstation ein Upgrade Ihres Administratorclusters aus.

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

Upgraderichtlinie

Nach dem Upgrade Ihres Administratorclusters:

  • Alle neu erstellten Nutzercluster müssen dieselbe Version wie Ihr Administratorcluster haben.

  • Wenn Sie einen vorhandenen Nutzercluster aktualisieren, müssen Sie ein Upgrade auf die Version Ihres Administratorclusters ausführen.

  • Bevor Sie Ihren Administratorcluster noch einmal aktualisieren, müssen Sie alle Nutzercluster auf dieselbe Version wie Ihren aktuellen Administratorcluster aktualisieren.

Konfigurations- und Informationsdateien suchen

Beim Erstellen Ihrer aktuellen 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.

Beim Erstellen Ihrer aktuellen Administrator-Workstation 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 ihre Standardnamen haben, müssen Sie sie beim Ausführen von gkeadm upgrade admin-workstation 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.

Upgrade für die Administrator-Workstation ausführen

Laden Sie zuerst eine neue Version des gkeadm-Tools herunter und aktualisieren Sie damit das Upgrade Ihrer Administrator-Workstation. Die Version von gkeadm muss der Zielversion Ihres Upgrades entsprechen.

gkeadm herunterladen

Um die entsprechende Version von gkeadm herunterzuladen, folgen Sie der Anleitung auf der Seite Downloads.

Upgrade für die Administrator-Workstation ausführen

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:

    • Ihre Anthos-Cluster auf einer VMware-Konfigurationsdatei. Der Standardname dieser Datei ist config.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.

Betriebssystem-Image und Docker-Images aktualisieren

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

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

Dabei gilt:

  • [ADMIN_CONFIG] ist der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

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

Der vorherige Befehl führt die folgenden Aufgaben aus:

  • Kopieren Sie bei Bedarf ein neues Knoten-Betriebssystem-Image in Ihre vsphere-Umgebung und markieren Sie das Betriebssystem-Image als Vorlage.

  • Wenn Sie eine private Docker-Registry konfiguriert haben, übertragen Sie aktualisierte Docker-Images in die private Docker-Registry.

Prüfen, ob genügend IP-Adressen verfügbar sind

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.

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

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. Ist dies nicht der Fall, führen Sie die folgenden Schritte aus:

  • Öffnen Sie zur Bearbeitung die IP-Blockdatei des Nutzerclusters.

  • Fügen Sie dem Block weitere IP-Adressen hinzu und schließen Sie die Datei.

  • Aktualisieren Sie den Nutzercluster:

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
  --config [USER_CLUSTER_CONFIG]

(Optional) Neue vSphere-Funktionen deaktivieren

Neue Anthos-Cluster mit VMware-Version können neue Funktionen oder Unterstützung für bestimmte VMware vSphere-Features enthalten. In manchen Fällen werden bei einem Upgrade auf Anthos-Cluster mit VMware-Version automatisch solche Funktionen aktiviert. Informationen zu neuen Funktionen in Anthos-Clustern finden Sie in den Versionshinweisen von VMware. Neue Features werden manchmal in den Anthos-Clustern in der VMware-Konfigurationsdatei angezeigt.

Wenn Sie eine neue Funktion deaktivieren müssen, die in einer neuen Anthos-Cluster auf VMware-Version automatisch aktiviert ist und von der Konfigurationsdatei gesteuert wird, führen Sie die folgenden Schritte durch, bevor Sie Ihr 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 notieren Sie sich 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. Legen Sie den Wert des Felds auf false oder gleichwertig fest.

  4. Speichern Sie die Konfigurationsdatei.

Lesen Sie die Versionshinweise, bevor Sie die Cluster upgraden. Sie können die Konfiguration eines vorhandenen Clusters nach dem Upgrade nicht deklarativ ändern.

Administratorcluster upgraden

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

Denken Sie daran, dass die Zielversion Ihres Upgrades mit Ihrer gkeadm-Version übereinstimmen muss.

Führen Sie diesen Befehl aus:

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

Dabei gilt:

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

  • [ADMIN_CLUSTER_CONFIG_FILE] ist der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

  • [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 für Nutzercluster durchführen

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

Denken Sie daran, dass die Zielversion Ihres Upgrades mit Ihrer gkeadm-Version übereinstimmen muss.

gkectl

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

Dabei gilt:

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

  • [USER_CLUSTER_CONFIG_FILE] ist der Pfad Ihrer Nutzerclusterkonfigurationsdatei.

  • [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 Anthos-Cluster und Ihre GKE-Cluster in der Google Cloud Console ansehen und sich bei ihnen anmelden.

Sobald ein Upgrade für einen 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 die Seite „Google Kubernetes Engine“ auf:

    Zur Seite „Google Kubernetes Engine“

  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] der Pfad der kubeconfig-Datei des Administratorclusters ist. [CLUSTER_NAME] ist der Name des Nutzerclusters, den Sie aktualisieren, und [USER_CLUSTER_CONFIG_FILE] ist der Pfad der Nutzercluster-Konfigurationsdatei.

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] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

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.

Neuen Nutzercluster nach einem Upgrade erstellen

Nach dem Upgrade Ihrer Administrator-Workstation und Ihres Administratorclusters müssen alle neu erstellten Nutzercluster dieselbe Version wie die Upgrade-Zielversion haben.

VMware-DRS-Regeln

Anthos-Cluster auf VMware erstellt automatisch die DRS (Distributed Resource Scheduler)-Anti-Affinitätsregeln für die Knoten Ihres Nutzerclusters, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden. Dieses Feature wird 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.
  • Das im Feld vcenter angegebene vSphere-Nutzerkonto 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 den Versionshinweisen zu Version 1.4.0.

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.