Wenn Sie ein Upgrade von GKE on Bare Metal ausführen, umfasst der Upgradeprozess mehrere Schritte und Komponenten. Damit Sie den Upgradestatus überwachen oder Probleme diagnostizieren und beheben können, sollten Sie wissen, was passiert, wenn Sie den Befehl bmctl upgrade cluster ausführen. In diesem Dokument werden die Komponenten und Phasen eines Clusterupgrades beschrieben.
Überblick
Beim Upgradeprozess wird Ihr GKE on Bare Metal-Cluster von seiner aktuellen Version in eine höhere Version verschoben.
Diese Versionsinformationen werden an den folgenden Speicherorten als Teil der benutzerdefinierten Clusterressource im Administratorcluster gespeichert:
status.anthosBareMetalVersion: definiert die aktuelle Version des Clustersspec.anthosBareMetalVersion: definiert die Zielversion und wird festgelegt, wenn der Upgradeprozess beginnt.
Bei einem erfolgreichen Upgradevorgang wird status.anthosBareMetalVersion mit spec.anthosBareMetalVersion abgeglichen, sodass beide die Zielversion anzeigen.
Versionsabweichung
Die Versionsabweichung ist der Versionsunterschied zwischen einem Administratorcluster und seinen verwalteten Nutzerclustern. GKE on Bare Metal-Cluster folgen demselben Stil wie Kubernetes: Der Administratorcluster kann höchstens eine Nebenversion vor seinen verwalteten Clustern haben.
Versionsregeln für Upgrades
Wenn Sie eine neue Version von bmctl herunterladen und installieren, können Sie ein Upgrade für Ihre Administrator-, Hybrid-, eigenständigen und Nutzercluster ausführen, die mit einer früheren Version von bmctl erstellt oder aktualisiert wurden. Cluster können nicht auf eine niedrigere Version herabgestuft werden.
Sie können ein Cluster nur auf eine Version aktualisieren, die der von Ihnen verwendeten Version von bmctl entspricht. Wenn Sie also Version 1.16.8 von bmctl verwenden, können Sie einen Cluster nur auf Version 1.16.8 upgraden.
Upgrades der Patchversionen
Für eine Nebenversion können Sie ein Upgrade auf eine höhere Patchversion ausführen. Das heißt, Sie können einen 1.16.X-Versionscluster auf Version 1.16.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.15.0 auf 1.15.1 und von 1.15.1 auf 1.15.3 durchführen. Wir empfehlen, nach Möglichkeit ein Upgrade auf die neueste Patchversion durchzuführen, damit Ihre Cluster die neuesten Sicherheitsupdates haben.
Upgrades von Nebenversionen
Sie können Cluster unabhängig von der Patchversion von einer Nebenversion auf die nächste aktualisieren. Sie können also ein Upgrade von
1.N.X auf 1.N+1.Y durchführen, wobei 1.N.X die Version Ihres Clusters ist und N+1 ist die nächste verfügbare Nebenversion. Die Patchversionen X und Y wirken sich in diesem Fall nicht auf die Upgradelogik aus. Beispielsweise ist ein Upgrade von 1.15.3 auf 1.16.8 möglich.
Beim Upgrade von Clustern können Sie Nebenversionen nicht überspringen. Wenn Sie versuchen, ein Upgrade auf eine Nebenversion durchzuführen, die zwei oder mehr Nebenversionen höher ist als die Clusterversion, gibt bmctl einen Fehler aus. Sie können beispielsweise einen Cluster der Version 1.14.0 nicht auf Version 1.16.0 aktualisieren.
Ein Administratorcluster kann Nutzercluster verwalten, die sich in der gleichen oder einer früheren Nebenversion befinden. Verwaltete Nutzercluster können maximal eine Nebenversion niedriger als der Administratorcluster sein. Prüfen Sie daher vor dem Upgrade eines Administratorclusters auf eine neue Nebenversion, ob alle verwalteten Nutzercluster dieselbe Nebenversion als der Administratorcluster haben.
Die Beispiele in der folgenden Upgradeanleitung zeigen den Upgradeprozess von Version 1.15.2 auf GKE on Bare Metal 1.16.8.
Versionsverwaltungsregeln für Knotenpools
Wenn Sie Knotenpools selektiv aktualisieren, gelten die folgenden Versionsregeln:
Die Clusterversion muss größer oder gleich der Version des Worker-Knotenpools sein.
Die maximale Abweichung zwischen der Clusterversion und der Version des Worker-Knotenpools ist um eine Nebenversion.
Worker-Knotenpools dürfen keine Version haben, die später als die Clusterversion veröffentlicht wurde.
Bei einem Cluster mit der Version 1.15.4, die bei der Veröffentlichung von Version 1.16.0 nicht verfügbar war, können Sie beispielsweise kein Upgrade auf Version 1.16.0 durchführen und den Worker-Knotenpool mit der Version 1.15.4 verlassen. Wenn Sie ein Upgrade auf Version 1.16.0 durchgeführt haben, sich aber entschieden haben, einen Worker-Knotenpool mit der Version 1.15.2 zu belassen, können Sie später kein Upgrade des Worker-Knotenpools auf Version 1.15.4 durchführen.
In der folgenden Tabelle sind die unterstützten Versionen von Knotenpools aufgeführt, die für eine bestimmte Clusterversion zulässig sind:
| Version des Clusters (Steuerungsebene) | Unterstützte Versionen von Worker-Knotenpools | |||
|---|---|---|---|---|
| 1.16.8 |
|
|
|
|
| 1.16.7 |
|
|
|
|
| 1.16.6 |
|
|
|
|
| 1.16.5 |
|
|
|
|
| 1.16.4 |
|
|
|
|
| 1.16.3 |
|
|
|
|
| 1.16.2 |
|
|
|
|
| 1.16.1 |
|
|
||
| 1.16.0 |
|
|
||
Komponenten upgraden
Upgrades für Komponenten werden sowohl auf Knoten- als auch auf Clusterebene durchgeführt. Auf Clusterebene werden Upgrades für die folgenden Komponenten durchgeführt:
- Clusterkomponenten für Netzwerk, Beobachtbarkeit und Speicher
- Bei Administrator-, Hybrid- und eigenständigen Clustern: die Lebenszyklus-Controller.
- Das Feld
gke-connect-agent.
Knoten in einem Cluster werden mit einer der folgenden Rollen ausgeführt, wobei je nach Rolle des Knotens unterschiedliche Komponenten aktualisiert werden:
| Rolle des Knotens | Funktion | Komponenten, für die ein Upgrade durchgeführt werden soll |
|---|---|---|
| Worker | Führt Nutzerarbeitslasten aus | Kubelet, Containerlaufzeit (Docker oder containerd) |
| Steuerungsebene | Führt die Kubernetes-Steuerungsebene, Clusterlebenszyklus-Controller und Plattform-Add-ons der Google Kubernetes Engine (GKE) Enterprise-Version aus | Statische Pods der Kubernetes-Steuerungsebene (kubeapi-server, kube-scheduler, kube-controller-manager usw.)
Lebenszyklus-Controller wie lifecycle-controllers-manager und anthos-cluster-operatorPlattform-Add-ons der Google Kubernetes Engine (GKE) Enterprise Edition wie stackdriver-log-aggregator und gke-connect-agent |
| Load-Balancer der Steuerungsebene | Führt HAProxy und Keepaowned aus, die Traffic an kube-apiserver weiterleiten, und MetalLB-Lautsprecher, um virtuelle IP-Adressen zu beanspruchen |
Statische Pods des Load-Balancers der Steuerungsebene (HAProxy, Keepaowned)
MetalLB-Lautsprecher |
Erwartete Ausfallzeiten
Die folgende Tabelle enthält die erwarteten Ausfallzeiten und möglichen Auswirkungen beim Upgrade von Clustern. In dieser Tabelle wird davon ausgegangen, dass Sie mehrere Clusterknoten und eine Steuerungsebene für Hochverfügbarkeit haben. Wenn Sie einen eigenständigen Cluster ausführen oder keine Steuerungsebene für Hochverfügbarkeit haben, ist mit zusätzlichen Ausfallzeiten zu rechnen. Sofern nicht anders angegeben, gilt diese Ausfallzeit sowohl für Administrator- als auch für Nutzerclusterupgrades:
| Komponenten | Erwartungen an Ausfallzeiten | Bei Ausfallzeiten |
|---|---|---|
API-Server der Kubernetes-Steuerungsebene (kube-apiserver), etcd und Planer |
Keine Ausfallzeiten | – |
Lebenszyklus-Controller und ansible-runner-Job (nur Administratorcluster) |
Keine Ausfallzeiten | – |
Kubernetes-Steuerungsebene loadbalancer-haproxy und keepalived |
Vorübergehende Ausfallzeit (weniger als 1 bis 2 Minuten), wenn der Load-Balancer Traffic weiterleitet. | Beginn des Upgradeprozesses. |
Beobachtbarkeit pipeline-stackdriver und metrics-server |
Der Operator wurde per Drain beendet und es wurde ein Upgrade durchgeführt. Die Ruhezeit sollte weniger als 5 Minuten betragen.
DaemonSets funktionieren weiterhin ohne Ausfallzeiten. |
Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| Container Network Interface (CNI) | Keine Ausfallzeit für vorhandene Netzwerkrouten. DaemonSet wurde zweimal zu zwei ohne Ausfallzeiten bereitgestellt. Der Operator wurde per Drain beendet und hat ein Upgrade. Ruhezeit weniger als 5 Minuten. |
Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| MetalLB (nur Nutzercluster) | Der Operator wurde per Drain beendet und es wurde ein Upgrade durchgeführt. Die Ruhezeit beträgt weniger als 5 Minuten.
Keine Ausfallzeiten für den vorhandenen Dienst |
Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| CoreDNS und DNS-Autoscaling (nur Nutzercluster) | CoreDNS hat mehrere Replikate mit Autoscaling. In der Regel keine Ausfallzeiten. | Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| Bereitsteller lokaler Volumes | Keine Ausfallzeit für vorhandene bereitgestellte nichtflüchtige Volumes (PVs).
Der Betreiber hat möglicherweise eine Ausfallzeit von 5 Minuten. |
Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| Istio / Ingress | Der Istio-Operator wird per Drain beendet und aktualisiert. Etwa 5 Minuten Ausfallzeit. Vorhandener konfigurierter eingehender Traffic funktioniert weiterhin. |
Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| Andere Netzbetreiber | 5 Minuten Ausfallzeit beim Draining und Aktualisieren. | Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist. |
| Nutzerarbeitslasten | Hängt von der Einrichtung ab, z. B. von der Hochverfügbarkeit. Überprüfen Sie Ihre eigenen Arbeitslastbereitstellungen, um mögliche Auswirkungen zu verstehen. |
Wenn ein Upgrade der Worker-Knoten durchgeführt wird. |
Details zum Nutzerclusterupgrade
In diesem Abschnitt wird die Reihenfolge der Komponentenupgrades und Statusinformationen für ein Nutzerclusterupgrade beschrieben. Im folgenden Abschnitt werden Abweichungen von diesem Ablauf für Administrator-, Hybrid- oder eigenständige Clusterupgrades beschrieben.
Das folgende Diagramm zeigt den Preflight-Prüfungsprozess für ein Nutzerclusterupgrade:
Das obige Diagramm zeigt die Schritte, die während eines Upgrades ausgeführt werden:
- Mit dem Befehl
bmctl upgrade clusterwird eine benutzerdefinierte Ressource vom TypPreflightCheckerstellt. - Diese Preflight-Prüfung führt zusätzliche Prüfungen aus, z. B. Prüfungen für Clusterupgrades, Netzwerk- und Knotendiagnosen.
- Die Ergebnisse dieser zusätzlichen Prüfungen geben zusammen Aufschluss über die Fähigkeit des Clusters, ein erfolgreiches Upgrade auf die Zielversion durchzuführen.
Wenn die Preflight-Prüfungen erfolgreich sind und keine blockierenden Probleme vorliegen, werden die Komponenten im Cluster in einer bestimmten Reihenfolge aktualisiert, wie im folgenden Diagramm dargestellt:
Im obigen Diagramm werden Komponenten in folgender Reihenfolge aktualisiert:
- Das Upgrade beginnt mit dem Aktualisieren des Felds
spec.anthosBareMetalVersion. - Die Load-Balancer der Steuerungsebene werden aktualisiert.
- Für den Knotenpool der Steuerungsebene wurde ein Upgrade durchgeführt.
- Parallel dazu werden Upgrades für GKE Connect, Cluster-Add-ons und Load-Balancer-Knotenpool durchgeführt.
- Nachdem der Load-Balancer-Knotenpool erfolgreich aktualisiert wurde, werden auch die Worker-Knotenpools aktualisiert.
Wenn alle Komponenten aktualisiert wurden, werden Cluster-Systemdiagnosen ausgeführt.
Die Systemdiagnosen werden so lange fortgesetzt, bis alle Prüfungen bestanden wurden.
Wenn alle Systemdiagnosen bestanden wurden, ist das Upgrade abgeschlossen.
Jede Komponente hat ein eigenes Statusfeld in der benutzerdefinierten Clusterressource. In den folgenden Feldern können Sie den Status prüfen, um den Fortschritt des Upgrades nachzuvollziehen:
| Sequenz | Feldname | Bedeutung |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
Der Status wird aus dem Knotenpoolstatus der Steuerungsebene kopiert. Das Feld enthält die Versionen der Knoten der Knotenpools der Steuerungsebene |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Version von lifecycles-controllers-manager, die auf den Cluster angewendet wurde. Dieses Feld ist nur für Administratorcluster, eigenständige Cluster oder Hybridcluster verfügbar. |
| 2 | status.anthosBareMetalManifestsVersion |
Version des Clusters aus dem zuletzt angewendeten Manifest. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Der Status wird aus dem Knotenpoolstatus des Load-Balancers der Steuerungsebene kopiert. Dieses Feld ist leer, wenn in Cluster.Spec kein separater Load-Balancer der Steuerungsebene angegeben ist. |
| 3 | status.anthosBareMetalVersions |
Eine aggregierte Versionszuordnung von Versionen zu Knotennummern. |
| 4 | status.anthosBareMetalVersion |
Endgültiger Status der aktualisierten Version. |
Details zum Upgrade von Administrator-, Hybrid- und eigenständigen Clustern
Ab bmctl-Version 1.15.0 ist das standardmäßige Upgradeverhalten für selbstverwaltete (Administrator-, Hybrid- oder eigenständige) Cluster ein direktes Upgrade.
Wenn Sie also einen Cluster auf Version 1.15.0 oder höher upgraden, verwendet das Upgrade Lebenszyklus-Controller anstelle eines Bootstrap-Clusters, um den gesamten Upgradeprozess zu verwalten. Diese Änderung vereinfacht den Prozess und verringert den Ressourcenbedarf, wodurch Clusterupgrades zuverlässiger und skalierbarer werden.
Die Verwendung eines Bootstrap-Clusters für das Upgrade wird zwar nicht empfohlen, die Option ist aber weiterhin verfügbar. Wenn Sie beim Upgrade einen Bootstrap-Cluster verwenden möchten, führen Sie den Befehl bmctl upgrade mit dem Flag --use-bootstrap=true aus.
Die Phasen des Upgrades unterscheiden sich je nach verwendeter Methode.
Direkte Upgrades
Der standardmäßige direkte Upgradeprozess für selbstverwaltete Cluster ähnelt dem Upgradeprozess für Nutzercluster. Wenn Sie jedoch den direkten Upgradeprozess verwenden, wird eine neue Version von preflightcheck-operator bereitgestellt, bevor die Preflight-Prüfung und die Systemdiagnosen des Clusters ausgeführt werden:
Wie beim Nutzerclusterupgrade beginnt der Upgradeprozess mit dem Aktualisieren des Felds Cluster.spec.anthosBareMetalVersion auf die Zielversion. Zwei zusätzliche Schritte werden ausgeführt, bevor die Komponenten aktualisiert werden, wie im folgenden Diagramm gezeigt: lifecycle-controller-manager führt ein Upgrade auf die Zielversion selbst durch und stellt dann die Zielversion von anthos-cluster-operator bereit. Mit dieser anthos-cluster-operator werden die verbleibenden Schritte des Upgradeprozesses ausgeführt:
Bei Erfolg gleicht anthos-cluster-operator die Zielversion von spec.anthosBareMetalVersion mit status.anthosBareMetalVersion ab.
Upgrade mit einem Bootstrap-Cluster
Der Vorgang zum Upgrade eines Administrator-, Hybrid- oder eigenständigen Clusters ähnelt einem Nutzercluster, der im vorherigen Abschnitt beschrieben wurde.
Der Hauptunterschied besteht darin, dass der Befehl bmctl upgrade cluster einen Prozess zum Erstellen eines Bootstrap-Clusters startet. Dieser Bootstrap-Cluster ist ein temporärer Cluster, der den Hybrid-, Administrator- oder eigenständigen Cluster während eines Upgrades verwaltet.
Der Vorgang zum Übertragen der Verwaltungsinhaberschaft des Clusters auf den Bootstrap-Cluster wird als Pivot bezeichnet. Der Rest des Upgrades folgt dem gleichen Prozess wie das Nutzerclusterupgrade.
Während des Upgrades bleiben die Ressourcen im Zielcluster veraltet. Der Upgradefortschritt wird nur in den Ressourcen des Bootstrap-Clusters widergespiegelt.
Bei Bedarf können Sie auf den Bootstrap-Cluster zugreifen, um den Upgradeprozess zu überwachen und zu debuggen. Auf den Bootstrap-Cluster kann über bmctl-workspace/.kindkubeconfig zugegriffen werden.
Um die Verwaltungsinhaberschaft des Clusters nach Abschluss des Upgrades wieder zurückzuübertragen, wandelt der Cluster die Ressourcen vom Bootstrap-Cluster in den aktualisierten Cluster um. Während des Upgrades müssen Sie keine manuellen Schritte ausführen, um den Cluster zu pivotieren. Der Bootstrap-Cluster wird gelöscht, nachdem das Clusterupgrade erfolgreich war.
Knotenausgleich
GKE on Bare Metal-Clusterupgrades können zu Anwendungsunterbrechungen führen, wenn die Knoten per Drain beendet werden. Dieser Ausgleichsprozess führt dazu, dass alle auf einem Knoten ausgeführten Pods heruntergefahren und auf den verbleibenden Knoten im Cluster neu gestartet werden.
Bereitstellungen können verwendet werden, um solche Störungen zu tolerieren. Ein Deployment kann mehrere Replikate einer Anwendung oder eines Dienstes angeben, die ausgeführt werden sollen. Bei einer Anwendung mit mehreren Replikaten sollten während Upgrades kaum oder gar keine Störungen auftreten.
Budgets für Pod-Störungen (Pod-Unterbrechungsbudgets)
Mit Budget für Pod-Störungen (Pod Disruption Budgets, PDBs) können Sie sicherstellen, dass eine definierte Anzahl von Replikaten immer unter normalen Ausführungsbedingungen im Cluster ausgeführt wird. Mit PDBs können Sie die Unterbrechung einer Arbeitslast begrenzen, wenn ihre Pods neu geplant werden müssen.
GKE on Bare Metal berücksichtigt jedoch keine PDBs, wenn Knoten während eines Upgrades per Drain beendet werden.
Stattdessen wird der Knotenausgleich nach dem Best-Effort-Prinzip angewendet. Einige Pods bleiben möglicherweise im Status Terminating hängen und weigern sich, den Knoten zu verlassen. Das Upgrade wird auch bei hängen gebliebenen Pods fortgesetzt, wenn der Ausgleichsprozess auf einem Knoten länger als 20 Minuten dauert.
Nächste Schritte
- Best Practices für Upgrades auf GKE on Bare Metal
- Cluster upgraden
- Probleme beim Clusterupgrade beheben