Wenn Sie GKE on Bare Metal upgraden, umfasst der Upgradeprozess mehrere Schritte und Komponenten. Damit Sie den Upgradestatus überwachen oder Probleme diagnostizieren und beheben können, ist es hilfreich zu wissen, was passiert, wenn Sie den Befehl bmctl upgrade cluster ausführen. In diesem Dokument werden die Komponenten und Phasen eines Clusterupgrades beschrieben.
Überblick
Durch das Upgrade wird GKE on Bare Metal von der 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 Clusters.spec.anthosBareMetalVersiondefiniert die gewünschte Version und wird festgelegt, wenn der Upgradeprozess beginnt.
Bei einem erfolgreichen Upgradevorgang wird die gewünschte Version von spec.anthosBareMetalVersion nach status.anthosBareMetalVersion abgeglichen.
Versionsabweichung
Die Versionsabweichung ist der Versionsunterschied zwischen einem Administratorcluster und dessen verwalteten Nutzerclustern. GKE on Bare Metal folgt demselben Stil wie Kubernetes: Der Administratorcluster kann höchstens eine Nebenversion vor seinen verwalteten Clustern sein.
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.14.11 von bmctl verwenden, können Sie einen Cluster nur auf Version 1.14.11 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.14.X-Versionscluster auf Version 1.14.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.13.0 auf 1.13.1 und von 1.13.1 auf 1.13.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.13.3 auf 1.14.11 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.12.0 nicht auf Version 1.14.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.13.2 auf GKE on Bare Metal 1.14.11.
Komponenten upgraden
Für Komponenten werden sowohl auf Knoten- als auch auf Clusterebene Upgrades durchgeführt. Auf Clusterebene werden die folgenden Komponenten aktualisiert:
- Clusterkomponenten für Netzwerk, Beobachtbarkeit und Speicher
- Für Administrator-, Hybrid- und eigenständige Cluster 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 | Zu aktualisierende Komponenten |
|---|---|---|
| Worker | Führt Nutzerarbeitslasten aus | Kubelet, Containerlaufzeit (Docker oder containerd) |
| Steuerungsebene | Führt die Kubernetes-Steuerungsebene, Clusterlebenszyklus-Controller und Anthos-Plattform-Add-ons aus | Statische Pods der Kubernetes-Steuerungsebene (kubeapi-server, kube-scheduler, kube-controller-manager usw.)
Lebenszyklus-Controller wie lifecycle-controllers-manager und anthos-cluster-operatorAnthos-Plattform-Add-ons wie stackdriver-log-aggregator und gke-connect-agent |
| Load-Balancer der Steuerungsebene | Führt UDP und Keepalife aus, die Traffic an kube-apiserver weiterleiten, und MetalLB-Lautsprecher ausführen, um virtuelle IP-Adressen zu beanspruchen |
Statische Pods des Load-Balancers der Steuerungsebene (HAProxy, Keepabehavior)
MetalLB-Lautsprecher |
Erwartete Ausfallzeiten
In der folgenden Tabelle sind die erwartete Ausfallzeit und die möglichen Auswirkungen beim Upgrade von Clustern aufgeführt. In dieser Tabelle wird davon ausgegangen, dass Sie mehrere Clusterknoten und eine Hochverfügbarkeits-Steuerungsebene haben. Wenn Sie einen eigenständigen Cluster ausführen oder keine Hochverfügbarkeits-Steuerungsebene haben, ist mit zusätzlicher Ausfallzeit 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 |
Operator Draining beendet und Upgrade durchgeführt. Die Ruhezeit sollte weniger als 5 Minuten betragen.
DaemonSets arbeiten weiterhin ohne Ausfallzeiten. |
Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| Container Network Interface (CNI) | Keine Ausfallzeit für vorhandene Netzwerkrouten. DaemonSet wurde zweimal zu zwei ohne Ausfallzeit bereitgestellt. Der Operator wurde per Drain beendet und aktualisiert. Ruhezeit weniger als 5 Minuten. |
Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| MetalLB (nur Nutzercluster) | Operator Draining beendet und Upgrade durchgeführt. Die Ruhezeit beträgt weniger als 5 Minuten.
Keine Ausfallzeit für den vorhandenen Dienst |
Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| CoreDNS und DNS-Autoscaling (nur Nutzercluster) | CoreDNS hat mehrere Replikate mit Autoscaling. In der Regel keine Ausfallzeiten. | Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| Bereitsteller lokaler Volumes | Keine Ausfallzeit für vorhandene bereitgestellte nichtflüchtige Volumes (PVs).
Der Betreiber hat möglicherweise 5 Minuten Ausfallzeit. |
Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| Istio / Ingress | Der Istio-Operator wird per Drain beendet und aktualisiert. Etwa 5 Minuten Ausfallzeit. Vorhandener konfigurierter eingehender Traffic funktioniert weiterhin. |
Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| Andere Internetanbieter | 5 Minuten Ausfallzeit beim Ausgleichen und Upgraden. | Nach Abschluss des Upgrades der Knoten der Steuerungsebene. |
| Nutzerarbeitslasten | Hängt von der Einrichtung ab, z. B. ob hochverfügbar. Überprüfen Sie Ihre eigenen Arbeitslastbereitstellungen, um die potenziellen Auswirkungen zu verstehen. |
Wenn ein Upgrade der Worker-Knoten durchgeführt wird. |
Details zum Upgrade des Nutzerclusters
In diesem Abschnitt werden die Reihenfolge der Komponentenupgrades und Statusinformationen für ein Nutzerclusterupgrade beschrieben. Im folgenden Abschnitt werden die 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 benutzerdefiniertePreflightCheck-Ressource erstellt. - Mit dieser Preflight-Prüfung werden zusätzliche Prüfungen wie Clusterupgrade-, Netzwerk- und Knoten-Systemdiagnosen ausgeführt.
- Die Ergebnisse dieser zusätzlichen Prüfungen zeigen zusammen, ob der Cluster erfolgreich auf die Zielversion aktualisiert werden kann.
Wenn die Preflight-Prüfungen erfolgreich sind und keine blockierenden Probleme auftreten, werden die Komponenten im Cluster in einer bestimmten Reihenfolge aktualisiert, wie im folgenden Diagramm dargestellt:
Im obigen Diagramm werden Komponenten in der folgenden Reihenfolge aktualisiert:
- Das Upgrade beginnt mit der Aktualisierung des Feldes
spec.anthosBareMetalVersion. - Die Load-Balancer der Steuerungsebene werden aktualisiert.
- Der Knotenpool der Steuerungsebene wird aktualisiert.
- Parallel dazu werden für GKE Connect sowie Cluster-Add-ons und der Load-Balancer-Knotenpool ein Upgrade durchgeführt.
- Nachdem der Load-Balancer-Knotenpool erfolgreich aktualisiert wurde, werden auch die Worker-Knotenpools aktualisiert.
- Wenn alle Komponenten aktualisiert sind, ist das Upgrade abgeschlossen.
Jede Komponente hat in der benutzerdefinierten Clusterressource ein eigenes Statusfeld. Sie können den Status in diesen Feldern prüfen, um den Fortschritt des Upgrades nachzuvollziehen:
| Sequenz | Feldname | Bedeutung |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
Der Status wird aus dem Status des Knotenpools der Steuerungsebene kopiert. Das Feld enthält die Versionen der Knoten von Knotenpools der Steuerungsebene |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Version von lifecycles-controllers-manager, die auf den Cluster angewendet wurde. Dieses Feld ist nur für Administrator-, eigenständige oder Hybridcluster verfügbar. |
| 2 | status.anthosBareMetalManifestsVersion |
Version des Clusters aus dem letzten angewendeten Manifest. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Der Status wird aus dem Status des Load-Balancer-Knotenpools 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 Version zu Knotennummern. |
| 4 | status.anthosBareMetalVersion |
Endgültiger Status der aktualisierten Version. |
Details zum Upgrade von Administrator-, Hybrid- und eigenständigen Clustern
Beim Upgrade eines Administrator-, Hybrid- und eigenständigen Clusters wird normalerweise ein Bootstrap-Cluster verwendet, um den Prozess zu verwalten. Ab GKE on Bare Metal 1.13.0 können Sie das Upgrade ohne Bootstrap-Cluster ausführen. Nur Cluster mit Version 1.13.0 oder höher können ohne Bootstrap-Cluster aktualisiert werden. Die Phasen des Upgrades unterscheiden sich, je nachdem, welche Methode Sie verwenden.
Weitere Informationen zu direkten Upgrades finden Sie unter Direkte Upgrades für selbstverwaltete Cluster.
Mit einem Bootstrap-Cluster
Das Upgrade eines Administrator-, Hybrid- oder eigenständigen Clusters ähnelt dem im vorherigen Abschnitt beschriebenen Nutzercluster. 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. Für den Rest des Upgrades läuft das Upgrade genauso ab wie für das Nutzercluster-Upgrade.
Während des Upgradeprozesses 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 Fehler zu beheben. Auf den Bootstrap-Cluster kann über bmctl-workspace/.kindkubeconfig zugegriffen werden.
Um die Verwaltungsinhaberschaft des Clusters nach Abschluss des Upgrades wieder zurückzuübertragen, schwenkt der Cluster die Ressourcen vom Bootstrap-Cluster in den aktualisierten Cluster. Während des Upgradeprozesses müssen Sie keine manuellen Schritte ausführen, um den Cluster zu pivotieren. Der Bootstrap-Cluster wird gelöscht, nachdem das Clusterupgrade erfolgreich war.
Ohne Bootstrap-Cluster
GKE on Bare Metal 1.13.0 und höher kann einen Administrator-, Hybrid- oder eigenständigen Cluster ohne Bootstrap-Cluster upgraden. Ohne Bootstrap-Cluster ähnelt das Upgrade dem Nutzercluster-Upgrade.
Das folgende Diagramm zeigt den Unterschied zur Nutzercluster-Oberfläche.
Ohne Bootstrap-Cluster wird eine neue Version von preflightcheck-operator bereitgestellt, bevor die Cluster-Preflight-Prüfung und die Systemdiagnosen ausgeführt werden:
Wie beim Nutzerclusterupgrade beginnt der Upgradeprozess mit der Aktualisierung des Feldes Cluster.Spec.AnthosBareMetalVersion auf die gewünschte Version.
Zwei zusätzliche Schritte werden ausgeführt, bevor Komponenten aktualisiert werden, wie im folgenden Diagramm dargestellt: lifecycle-controller-manager aktualisiert sich selbst auf die gewünschte Version und stellt dann die gewünschte Version von anthos-cluster-operator bereit. Dieser anthos-cluster-operator wird später im Upgradeprozess abgeglichen:
Knotenausgleich
GKE on Bare Metal-Upgrades können zu Anwendungsunterbrechungen führen, da die Knoten per Drain beendet werden. Dadurch werden alle Pods, die auf einem Knoten ausgeführt werden, heruntergefahren und auf den verbleibenden Knoten im Cluster neu gestartet.
Mit Bereitstellungen können solche Unterbrechungen toleriert werden. Für ein Deployment können mehrere Replikate einer Anwendung oder eines Dienstes angegeben werden, die ausgeführt werden sollen. Bei einer Anwendung mit mehreren Replikaten sollte es während Upgrades kaum oder gar nicht unterbrochen werden.
Budgets für Pod-Störungen
Mit Pod-Störungen-Budgets (PDBs) können Sie dafür sorgen, dass unter normalen Ausführungsbedingungen immer eine definierte Anzahl von Replikaten im Cluster ausgeführt wird. Mit PDBs können Sie die Unterbrechung einer Arbeitslast begrenzen, wenn die zugehörigen Pods neu geplant werden müssen.
GKE on Bare Metal berücksichtigt jedoch keine PDBs, wenn Knoten während eines Upgrades beendet werden.
Stattdessen wird für den Knotenausgleich nach Best-Effort-Maßnahme gesorgt. Einige Pods bleiben möglicherweise im Status Terminating hängen und weigern sich, den Knoten zu verlassen. Das Upgrade wird auch bei hängenden Pods fortgesetzt, wenn der Ausgleichsprozess auf einem Knoten länger als 20 Minuten dauert.
Nächste Schritte
- Best Practices für Upgrades von Anthos-Clustern auf Bare Metal
- Upgrade von Anthos-Clustern auf Bare Metal ausführen
- Probleme beim Clusterupgrade beheben