Version 1.0. Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Verfügbare Versionen

Cluster aktualisieren

Auf dieser Seite wird erläutert, wie Sie Ihre Administrator- und Nutzercluster von einer GKE On-Prem-Patchversion auf die nächsthöhere Patchversion upgraden. Informationen zu den verfügbaren Versionen finden Sie unter Versionen.

Weitere Informationen

Übersicht

GKE On-Prem unterstützt sequenzielle Upgrades. Angenommen, es sind nur die folgenden Versionen vorhanden:

1.0.10
1.0.X, wobei X nach .10 kam
1.0.Y, wobei Y nach X kam

In diesem Fall ist 1.0.Y die neueste Version. So führen Sie ein Upgrade für einen Cluster der Version 1.0.10 auf 1.0.Y durch:

Führen Sie ein Upgrade des Clusters von 1.0.10 auf 1.0.X durch.
führen Sie dann ein Upgrade des Clusters von 1.0.X auf 1.0.Y durch.

Hinweis

Stellen Sie eine SSH-Verbindung zur Administrator-Workstation her:
```
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
```
Autorisieren Sie gcloud zum Zugriff auf Google Cloud:
```
gcloud auth login
```
Aktivieren Sie Ihr Zugriffsdienstkonto:
```
gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [ACCESS_KEY_FILE]
```
Dabei gilt:
- [PROJECT_ID] ist die Projekt-ID.
- [ACCESS_KEY_FILE] ist der Pfad zur JSON-Schlüsseldatei für Ihr Zugriffsdienstkonto, z. B. /home/ubuntu/access.json.

Upgrade auf Version 1.0.2 durchführen

In Version 1.0.2-gke.3 wurden die folgenden erforderlichen OIDC-Felder (usercluster.oidc) hinzugefügt. 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 sich nicht über die Google Cloud Console in einem Cluster anmelden wollen, aber OIDC verwenden möchten, können Sie für diese Felder Platzhalterwerte übergeben:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Szenario für das Cluster-Upgrade bestimmen

Entscheiden Sie vor dem Upgrade des Clusters, welches der folgenden Szenarien für die Version relevant ist, auf die Sie das Upgrade durchführen:

Szenario	Maßnahme erforderlich	Hinweise
Version hat keine Sicherheitsupdates.	Laden Sie die aktuelle `gkectl`-Version herunter. Laden Sie das aktuelle Bundle herunter. Folgen Sie dazu der Anleitung auf dieser Seite.
Die Version enthält Sicherheitsupdates.	Laden Sie die aktuelle Administrator-Workstation-OVA-Datei herunter. Führen Sie ein Upgrade Ihrer Administrator-Workstation durch. Folgen Sie dazu der Anleitung auf dieser Seite.	Sie müssen Ihre Administrator-Workstation nur upgraden, wenn die neue Version über Sicherheitsupdates verfügt. Wenn Sie ein Upgrade für Ihre Administrator-Workstation durchführen, enthält sie die aktuelle `gkectl`-Version und das aktuelle Bundle.

Plattformversion ermitteln

Um ein Upgrade Ihrer Cluster durchzuführen, müssen Sie die Plattformversion für Ihre Cluster ermitteln:

Aus der Dokumentation

Siehe Versionen.

Aus dem Bundle

Führen Sie den folgenden Befehl aus, um das Bundle in ein temporäres Verzeichnis zu extrahieren:

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

Sehen Sie sich die extrahierten YAML-Dateien an, um einen allgemeinen Überblick über den Inhalt des Bundles zu erhalten.

Öffnen Sie insbesondere gke-onprem-vsphere-[VERSION]-images.yaml. Sehen Sie sich das Feld osimages an. Sie können die GKE-Plattformversion dem Namen der Betriebssystem-Image-Datei entnehmen. Im folgenden Betriebssystem-Image sehen Sie beispielsweise, dass die GKE-Plattformversion 1.12.7-gke.19 ist.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

Konfigurationsdatei ändern

Bearbeiten Sie auf der VM Ihrer Administrator-Workstation Ihre Konfigurationsdatei. Legen Sie die Werte für gkeplatformversion und bundlepath fest. Beispiel:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

gkectl prepare ausführen

Führen Sie diesen Befehl aus:

gkectl prepare --config [CONFIG_FILE]

Mit dem Befehl gkectl prepare werden folgende Tasks ausgeführt:

Kopieren Sie bei Bedarf ein neues Knoten-Betriebssystem-Image in Ihre vsphere-Umgebung und markieren Sie das Betriebssystem-Image als Vorlage.
Übertragen Sie die im neuen Bundle angegebenen aktualisierten Docker-Images in Ihre private Docker-Registry, sofern Sie eine konfiguriert haben.

Cluster upgraden

Für ein Upgrade eines Nutzerclusters muss die Version Ihres Administratorclusters mindestens so hoch wie die Zielversion des Nutzercluster-Upgrades sein. Wenn die Version Ihres Administratorclusters niedriger ist, upgraden Sie diesen vor einem Upgrade des Nutzerclusters.

Administratorcluster

Führen Sie diesen Befehl aus:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

Nutzercluster

Führen Sie dazu diesen Befehl aus:

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

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters, [CLUSTER_NAME] der Name des Nutzerclusters, den Sie upgraden, und [CONFIG_FILE] die GKE On-Prem-Konfigurationsdatei, die Sie für das Upgrade verwenden.

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. Hinweis: Wenn Nutzercluster-Knoten während des Upgrades die Nutzersteuerungsebene nicht erreichen können, werden keine neuen Arbeitslasten für den Cluster geplant. Vorhandene Arbeitslasten sind davon nicht betroffen.
Nutzerclusterknoten	Wenn ein Upgrade eine Änderung an Nutzerclusterknoten erfordert, erstellt GKE On-Prem die Knoten rollierend neu und plant 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.

Bekannte Probleme

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

Problembehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Neue Knoten erstellt, aber nicht intakt

Symptome

Neue Knoten registrieren sich nicht auf der Steuerungsebene des Nutzerclusters, wenn Sie den manuellen Load-Balancing-Modus verwenden.

Mögliche Ursachen

Die Ingress-Validierung im Knoten, die den Startvorgang der Knoten blockiert, kann aktiviert sein.

Lösung

Führen Sie Folgendes aus, um die Prüfung zu deaktivieren:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

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. Die Datei ist per Symlink mit der Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
- Für gkeadm ist 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:

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