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. |
|
|
Die Version enthält Sicherheitsupdates. |
|
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. |
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 Dateilogs/gkectl-$(date).log
im lokalen Verzeichnis verknüpft, in dem Siegkectl
ausführen. -
Für
gkeadm
ist die Standard-Logdateilogs/gkeadm-$(date).log
im lokalen Verzeichnis, in dem Siegkeadm
ausführen.
-
Für
- Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn
--alsologtostderr
auffalse
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