GKE On-Prem upgraden

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

Zielversionen

Ab GKE On-Prem-Version 1.3.2 können Sie ein Upgrade direkt auf jede Version ausführen, die sich in der gleichen Nebenversion oder in der nächsten Nebenversion befindet. Beispielsweise ist ein Upgrade von 1.3.2 auf 1.4.0 möglich. Sobald Version 1.4.1 verfügbar ist, können Sie ein direktes Upgrade von 1.3.2 auf 1.4.1 ausführen.

Die folgende Tabelle zeigt mögliche direkte Upgrades:

Aktuelle Version1.4.01.4.11.4.2
1.3.2JaJaJa
1.4.0JaJa
1.4.1Ja

Wenn Ihre aktuelle Version niedriger als 1.3.2 ist, müssen Sie sequenzielle Upgrades ausführen. Wenn Sie beispielsweise ein Upgrade von 1.2.0 auf 1.2.2 ausführen möchten, müssen Sie zuerst ein Upgrade von 1.2.0 auf 1.2.1 und dann ein Upgrade von 1.2.1 auf 1.2.2 ausfü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 eine neue Version des gkeadm-Tools herunter und führen Sie damit ein Upgrade Ihrer Administrator-Workstation aus. Die Version von gkeadm muss der Zielversion Ihres Upgrades entsprechen.

So laden Sie gkeadm herunter:

gsutil cp gs://gke-on-prem-release-public/gkeadm/[VERSION]/linux/gkeadm ./
chmod +x gkeadm

Dabei ist [VERSION] die Zielversion des Upgrades. Beispiel: 1.5.2-gke.3.

So führen Sie ein Upgrade der Administrator-Workstation 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:

    • Ihre GKE On-Prem-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.

Alte Administrator-Workstation aus known_hosts entfernen

Wenn Ihre Administrator-Workstation eine statische IP-Adresse hat, müssen Sie Ihre alte Administrator-Workstation nach dem Upgrade Ihrer Administrator-Workstation aus der Datei known_hosts entfernen.

So entfernen Sie die alte Administrator-Workstation aus known_hosts:

ssh-keygen -R [ADMIN_WS_IP]

Dabei ist [ADMIN_WS_IP] die IP-Adresse der Administrator-Workstation.

Bundle-Pfad in der GKE On-Prem-Konfigurationsdatei festlegen

Öffnen Sie auf Ihrer neuen Administrator-Workstation die GKE On-Prem-Konfigurationsdatei. Legen Sie den Wert von bundlepath auf den Pfad zur Bundle-Datei auf der neuen Administrator-Workstation fest:

bundlepath: "/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz"

Dabei ist [VERSION] die Zielversion Ihres Upgrades.

Betriebssystem-Image und Docker-Images aktualisieren

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

gkectl prepare --config [CONFIG_FILE] [FLAGS]

Dabei gilt:

  • [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei 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.

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

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

Statische IP-Adressen

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

Bestimmen Sie die Anzahl der Knoten in Ihrem Administratorcluster:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

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

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

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

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

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

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

Öffnen Sie das Clusterobjekt zum Bearbeiten:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

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

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 Hostkonfigurationsdatei des Nutzerclusters zur Bearbeitung öffnen:

  • Wenn eine der für einen Nutzercluster reservierten Adressen in der hostconfig-Datei 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.

(Optional) Neue vSphere-Funktionen deaktivieren

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

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

  1. Erstellen Sie in der aktualisierten Administration-Workstation eine neue Konfigurationsdatei mit einem anderen Namen als dem Ihrer aktuellen Konfigurationsdatei:

    gkectl create-config --config [CONFIG_NAME]
  2. Öffnen Sie die neue Konfigurationsdatei und 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 [CONFIG_FILE] \
[FLAGS]

Dabei gilt:

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

  • [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei 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 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 [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
[FLAGS]

Dabei gilt:

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

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

  • [CONFIG_FILE] ist die GKE On-Prem-Konfigurationsdatei 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.

Console

Sie können Ihre Nutzercluster während der Installation oder nach der Erstellung bei der Cloud Console registrieren. Sie können Ihre registrierten GKE On-Prem-Cluster und Ihre Google Kubernetes Engine-Cluster über das GKE-Menü der Cloud Console aufrufen und sich anmelden.

Wenn ein Upgrade für GKE On-Prem Nutzercluster verfügbar ist, wird eine Benachrichtigung in der 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 Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

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

  3. Kopieren Sie den Befehl gkectl upgrade cluster.

  4. Führen Sie auf Ihrer Administrator-Workstation den Befehl gkectl upgrade cluster aus, wobei [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters, [CLUSTER_NAME] der Name des aktualisierten Nutzerclusters und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei auf Ihrer neuen Administrator-Workstation ist.

Upgrade fortsetzen

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

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

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.

Bekannte Probleme

Die folgenden bekannten Probleme betreffen das Aktualisieren von Clustern.

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

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

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

Stackdriver verweist auf die alte Version

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

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

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

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

Unterbrechung für Arbeitslasten mit PodDisruptionBudgets

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

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

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

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

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

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

Version 1.1.1-gke.2: Das Datenlaufwerk im vSAN-Datenspeicherordner kann gelöscht werden

Wenn Sie einen vSAN-Datenspeicher verwenden, müssen Sie einen Ordner erstellen, in dem das VMDK gespeichert werden soll. Derzeit ist es für ein bekanntes Problem erforderlich, dass Sie vcenter.datadisk den UUID-Pfad (Universally Unique Identifier) des Ordners und nicht den Dateipfad angeben. Andernfalls können Upgrades fehlschlagen.

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

Upgrade auf Version 1.1.0-gke.6 von Version 1.0.2-gke.3: OIDC-Problem

Cluster der Versionen 1.0.11, 1.0.1-gke.5 und 1.0.2-gke.3, für die OpenID Connect (OIDC) konfiguriert ist, können nicht auf Version 1.1.0-gke.6 aktualisiert werden. Dieses Problem wurde in Version 1.1.1-gke.2 behoben.

Wenn Sie einen Cluster der Version 1.0.11, 1.0.1-gke.5 oder 1.0.2-gke.3 mit OIDC während der Installation konfiguriert haben, können Sie kein Upgrade ausführen. Stattdessen sollten Sie neue Cluster erstellen.

Version 1.0.2-gke.3 auf Version 1.0.11 aktualisieren

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 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 Cloud Console bei einem Cluster anmelden möchten. Um OIDC verwenden zu können, müssen Sie möglicherweise einen Platzhalterwert für clientsecret angeben:

oidc:
  clientsecret: "secret"

Knoten schließen ihren Upgradeprozess nicht ab

Wenn Anthos Service Mesh oder OSS Istio auf Ihrem Cluster installiert ist, werden die Nutzerknoten je nach PodDisruptionBudget-Einstellungen für die Istio-Komponenten möglicherweise nach wiederholten Versuchen nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung diese Problems empfehlen wir, die minReplicas-Einstellung für das horizontale Pod-Autoscaling vor dem Upgrade von 1 auf 2 für die Komponenten im Namespace istio-system zu erhöhen. Dadurch wird immer eine Instanz der ASM-Steuerungsebene ausgeführt.

Wenn Sie Anthos Service Mesh 1.5 (oder höher) oder OSS Istio 1.5 (oder höher) verwenden:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Wenn Sie Anthos Service Mesh 1.4.x oder OSS Istio 1.4.x verwenden:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

Anhang

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

Ab Version 1.1.0-gke.6 erstellt GKE On-Prem automatisch Anti-Affinitätsregeln des Typs Distributed Resource Scheduler (DRS) für die Knoten Ihres Nutzerclusters, sodass sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden. Ab Version 1.1.0-gke.6 wird diese Funktion automatisch für neue Cluster und vorhandene Cluster aktiviert.

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

  • VMware DRS ist aktiviert. Für VMware DRS ist die vplaner Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter VMware DRS in einem Cluster aktivieren.
  • Das im Feld vcenter angegebene vSphere-Nutzerkonto hat die Berechtigung Host.Inventory.EditCluster.
  • Es sind mindestens drei physische Hosts verfügbar.

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 der GKE On-Prem-Versionshinweise.

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.

Steuerungsebene der Nutzercluster

Normalerweise sollten Sie keine nennenswerten Ausfallzeiten für Nutzercluster-Steuerungsebenen erwarten. Lang andauernde Verbindungen zum Kubernetes API-Server können jedoch unterbrochen werden und müssen neu hergestellt werden. In diesen Situationen sollte der API-Aufrufer noch einmal versuchen, eine Verbindung herzustellen. Im schlimmsten Fall kann es während eines Upgrades bis zu einer Minute dauern.

Nutzerclusterknoten

Wenn ein Upgrade eine Änderung an Nutzerclusterknoten erfordert, erstellt GKE On-Prem die Knoten rollierend neu und verschiebt die auf diesen Knoten ausgeführten Pods neu. Sie können Auswirkungen auf Ihre Arbeitslasten verhindern, wenn Sie die entsprechenden PodDisruptionBudgets und Anti-Affinitätsregeln konfigurieren.

Fehlerbehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Clusterprobleme mit gkectl diagnostizieren

Verwenden Sie gkectl diagnose-Befehle, um Clusterprobleme zu identifizieren und Clusterinformationen an Google zu senden. Siehe Clusterprobleme diagnostizieren.

Standard-Logging-Verhalten

Für gkectl und gkeadm reicht es aus, die Standard-Logging-Einstellungen zu verwenden:

  • Standardmäßig werden Logeinträge so gespeichert:

    • Für gkectl ist die Standard-Logdatei /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log per Symlink mit der Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
    • Für gkeadm befindet sich die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.
  • Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn --alsologtostderr auf false gesetzt ist).
  • Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.
  • Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.

Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.

Nicht standardmäßigen Speicherort für die Logdatei angeben

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl angeben möchten, verwenden Sie das Flag --log_file. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm angeben möchten, verwenden Sie das Flag --log_file.

Cluster-API-Logs im Administratorcluster suchen

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, versuchen Sie, dies durch Untersuchen der Logs der Cluster-API-Controller im Administratorcluster zu beheben:

  1. Suchen Sie im Namespace kube-system den Namen des Cluster-API-Controller-Pods, wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad zur kubeconfig-Datei des Administratorclusters ist:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Verwenden Sie optional für die Fehlersuche grep oder ein ähnliches Tool:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager