Lebenszyklus und Phasen von Clusterupgrades

Wenn Sie ein Upgrade von Google Distributed Cloud durchfü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 Google Distributed Cloud-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 Clusters.

  • spec.anthosBareMetalVersion: definiert die Zielversion und wird festgelegt, wenn der Upgradeprozess gestartet wird.

Bei einem erfolgreichen Upgradevorgang wird status.anthosBareMetalVersion mit spec.anthosBareMetalVersion abgeglichen, sodass beide die Zielversion anzeigen.

Clusterversionsabweichung

Die Clusterversionsabweichung ist der Unterschied der Versionen zwischen einem verwalteten Cluster (Hybrid oder Administrator) und seinen verwalteten Nutzerclustern. Wenn Sie einen Nutzercluster hinzufügen oder ein Upgrade durchführen, gelten die folgenden Versionsregeln:

1,29

Die folgenden Regeln gelten für Nutzercluster, die von einem Administratorcluster der Version 1.29 oder eines Hybridclusters verwaltet werden:

  • Die Versionen von Nutzerclustern dürfen nicht höher als die Version des verwaltenden Clusters (Administrator oder Hybrid) sein.

  • (1.29 Vorschau) Die Version von Nutzerclustern kann bis zu zwei Nebenversionen niedriger sein als die Version des verwaltenden Clusters. Ein Administratorcluster der Version 1.29 kann beispielsweise einen Nutzercluster der Version 1.16 verwalten. Diese n-2-Versionsverwaltung ist als Vorschaufunktion zum Verwalten von Clustern ab Version 1.29 verfügbar.

  • (1.29 Vorschau) Für einen Verwaltungscluster müssen Nutzercluster nicht dieselbe Nebenversion haben. Ein Administratorcluster der Version 1.29 kann beispielsweise Nutzercluster der Version 1.29, Version 1.28 und Version 1.16 verwalten. Diese Verwaltung gemischter Versionen ist als Vorabversion für die Verwaltung von Clustern ab Version 1.29 verfügbar.

    Die Funktion Vorschau für die Verwaltung mehrerer Neigungen bietet Ihnen mehr Flexibilität bei der Planung von Flottenupgrades. Sie müssen beispielsweise nicht alle Nutzercluster der Version 1.16 auf Version 1.28 upgraden, bevor Sie Ihren Administratorcluster auf Version 1.29 upgraden können.

1.28 und niedriger

Die folgenden Regeln gelten für Nutzercluster, die von einem Administratorcluster oder Hybridcluster der Version 1.28 oder einer früheren Version verwaltet werden:

  • Die Versionen von Nutzerclustern dürfen nicht höher als die Version des verwaltenden Clusters (Administrator oder Hybrid) sein.

  • Nutzercluster dürfen maximal eine Nebenversion unter der Version des verwaltenden Clusters liegen. Ein Administratorcluster der Version 1.28 kann beispielsweise keinen Nutzercluster mit der Version 1.15 verwalten.

  • Für einen Verwaltungscluster müssen sich alle verwalteten Nutzercluster in derselben Nebenversion befinden.

Informationen zu Versionsverzerrungsregeln für Knotenpools finden Sie unter Versionsverwaltungsregeln für Knotenpools.

Versionsregeln

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.29.100-gke.251 von bmctl verwenden, können Sie einen Cluster nur auf Version 1.29.100-gke.251 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.29.X-Versionscluster auf Version 1.29.Y aktualisieren, solange Y größer als X ist. Beispielsweise können Sie ein Upgrade von 1.28.0 auf 1.28.100 und von 1.28.100 auf 1.28.300 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. So können Sie beispielsweise ein Upgrade von 1.28.500-gke.120 auf 1.29.100-gke.251 ausführen.

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.16.0 nicht auf Version 1.29.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.

Versionsverwaltungsregeln für Knotenpools

Wenn Sie Knotenpools selektiv aktualisieren, gelten die folgenden Versionsregeln:

1,29

  • Die Clusterversion muss größer oder gleich der Version des Worker-Knotenpools sein.

  • (1.29 GA) Maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen.

  • Worker-Knotenpools dürfen keine Version haben, die chronologisch nach der Clusterversion veröffentlicht wurde. Der frühere Release enthält nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Beispielsweise wird Version 1.16.6 nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 upgraden und einen Worker-Knotenpool mit Version 1.16.6 belassen. Das Gleiche gilt, wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 upgraden, die Version 1.16.5 aber den Worker-Knotenpool beibehalten, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 upgraden, solange der Cluster die Version 1.28.100-gke.146 hat.

1,28

  • Die Clusterversion muss größer oder gleich der Version des Worker-Knotenpools sein.

  • (1.28 Vorschau) Maximale Versionsverzerrung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen, wenn die Vorschau-Funktion für n-2-Versionsabweichungen aktiviert ist. Wenn Sie diese Funktion nicht aktivieren, beträgt die maximale Versionsverzerrung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.

  • Worker-Knotenpools dürfen keine Version haben, die chronologisch nach der Clusterversion veröffentlicht wurde. Der frühere Release enthält nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Beispielsweise wird Version 1.16.6 nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 upgraden und einen Worker-Knotenpool mit Version 1.16.6 belassen. Das Gleiche gilt, wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 upgraden, die Version 1.16.5 aber den Worker-Knotenpool beibehalten, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 upgraden, solange der Cluster die Version 1.28.100-gke.146 hat.

1.16

  • Die Clusterversion muss größer oder gleich der Version des Worker-Knotenpools sein.

  • Die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster beträgt eine Nebenversion.

  • Worker-Knotenpools dürfen keine Version haben, die chronologisch nach der Clusterversion veröffentlicht wurde. Der frühere Release enthält nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Beispielsweise wird Version 1.16.6 nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht. Daher können Sie Ihren Cluster nicht von Version 1.16.6 auf Version 1.28.100-gke.146 upgraden und einen Worker-Knotenpool mit Version 1.16.6 belassen. Das Gleiche gilt, wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 upgraden, die Version 1.16.5 aber den Worker-Knotenpool beibehalten, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 upgraden, solange der Cluster die Version 1.28.100-gke.146 hat.

In der folgenden Tabelle sind die unterstützten Versionen von Knotenpools aufgeführt, die für eine bestimmte Clusterversion zulässig sind:

1,29

Version des Clusters (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 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
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1,28

Version des Clusters (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Version des Clusters (Steuerungsebene) Unterstützte Versionen von Worker-Knotenpools
1.16.9
  • 1.16.9
  • 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
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 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
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.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-operator

Plattform-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:

Die Preflight-Prüfung des Clusters führt zusätzliche Systemdiagnosen für den Cluster aus, bevor das Upgrade gestartet wird.

Das obige Diagramm zeigt die Schritte, die während eines Upgrades ausgeführt werden:

  • Mit dem Befehl bmctl upgrade cluster wird eine benutzerdefinierte Ressource vom Typ PreflightCheck erstellt.
  • 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:

Für die Load-Balancer und den Knotenpool der Steuerungsebene sowie für die GKE-Verbindung und die Cluster-Add-ons sowie für den Knotenpool und Worker-Knotenpools der Load-Balancer und der Worker-Knotenpools werden Upgrades durchgeführt.

Im obigen Diagramm werden Komponenten in folgender Reihenfolge aktualisiert:

  1. Das Upgrade beginnt mit dem Aktualisieren des Felds spec.anthosBareMetalVersion.
  2. Die Load-Balancer der Steuerungsebene werden aktualisiert.
  3. Für den Knotenpool der Steuerungsebene wurde ein Upgrade durchgeführt.
  4. Parallel dazu werden Upgrades für GKE Connect, Cluster-Add-ons und Load-Balancer-Knotenpool durchgeführt.
    1. Nachdem der Load-Balancer-Knotenpool erfolgreich aktualisiert wurde, werden auch die Worker-Knotenpools aktualisiert.

  5. Wenn alle Komponenten aktualisiert wurden, werden Cluster-Systemdiagnosen ausgeführt.

    Die Systemdiagnosen werden so lange fortgesetzt, bis alle Prüfungen bestanden wurden.

  6. 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:

Eine neue Version des Preflightcheck-Operators wird bereitgestellt, bevor die Preflight-Prüfung des Clusters zusätzliche Systemdiagnosen im Cluster ausführt.

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:

Der „Lifecycle-Controller-Manager“- und „Anthos-Cluster-Operator“ werden bereitgestellt, bevor der Rest des Clusters in der gleichen Reihenfolge wie die Komponenten im Nutzercluster aktualisiert wird.

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

Google Distributed Cloud-Clusterupgrades können zu Anwendungsunterbrechungen führen, da 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.

PodDisruptionBudgets (PDBs)

Wenn Sie einen Cluster upgraden, verwendet Google Distributed Cloud den Wartungsmodus, um Knoten zu entleeren.

Ab Version 1.29 werden Knoten mit der Eviction API per Drain beendet, die PodDisruptionBudgets (PDBs) ehrt. Mit PDBs lässt sich sicherstellen, 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 ihre Pods neu geplant werden müssen. Der bereinigte Knotenausgleich ist für Version 1.29 allgemein verfügbar.

In Versionen 1.28 und früheren Versionen berücksichtigt Google Distributed Cloud keine PDBs, wenn während eines Upgrades Knoten entleert 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 mehr als 20 Minuten dauert.

Weitere Informationen finden Sie unter Knoten in den Wartungsmodus versetzen.

Nächste Schritte