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 Upgradevorgang wird Ihr Google Distributed Cloud-Cluster von seiner aktuellen Version in eine höhere Version verschoben.

Diese Versionsinformationen werden als Teil der benutzerdefinierten Clusterressource im Administratorcluster an den folgenden Speicherorten gespeichert:

  • status.anthosBareMetalVersion: definiert die aktuelle Version des Clusters.

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

Bei einem erfolgreichen Upgradevorgang wird status.anthosBareMetalVersion mit spec.anthosBareMetalVersion abgeglichen, sodass in beiden die Zielversion angezeigt wird.

Abweichung der Clusterversion

Die Clusterversionsabweichung ist der Versionsunterschied zwischen einem Verwaltungscluster (Hybrid oder Administrator) und seinen verwalteten Nutzerclustern. Wenn Sie einen Nutzercluster hinzufügen oder aktualisieren, gelten die folgenden Versionsregeln:

1,29

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

  • Die Versionen des Nutzerclusters dürfen nicht höher sein als die Version des Verwaltungsclusters (Administrator oder Hybrid).

  • (1.29 Vorschau) Nutzercluster können bis zu zwei Nebenversionen unterhalb der Version des Verwaltungsclusters sein. Beispielsweise kann ein Administratorcluster der Version 1.29 einen Nutzercluster mit Version 1.16 verwalten. Diese n-2-Versionsabweichung ist als Vorabversion für die Verwaltung von Clustern ab Version 1.29 verfügbar.

  • (1.29 Vorschau) Für einen bestimmten 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 von gemischten Versionsabweichungen ist als Vorabversion für die Verwaltung von Clustern ab Version 1.29 verfügbar.

    Die Funktion zur Verwaltung mehrerer Entwürfe in der Vorabversion bietet Ihnen mehr Flexibilität bei der Planung Ihrer Flottenupgrades. Beispielsweise müssen Sie nicht alle Nutzercluster der Version 1.16 auf Version 1.28 aktualisieren, bevor Sie Ihren Administratorcluster auf Version 1.29 aktualisieren können.

1.28 und niedriger

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

  • Die Versionen des Nutzerclusters dürfen nicht höher sein als die Version des Verwaltungsclusters (Administrator oder Hybrid).

  • Nutzercluster können eine Nebenversion niedriger als die Version des Verwaltungsclusters sein. Beispielsweise kann ein Administratorcluster der Version 1.28 keinen Nutzercluster mit Version 1.15 verwalten.

  • Für einen bestimmten Verwaltungscluster müssen alle verwalteten Nutzercluster dieselbe Nebenversion haben.

Informationen zu Versionsabweichungsregeln 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. Das heißt, wenn Sie 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 ist beispielsweise ein Upgrade von 1.28.600-gke.163 auf 1.29.100-gke.251 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.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 selektive Upgrades von Knotenpools durchführen, gelten die folgenden Versionsregeln:

1,29

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

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

  • Worker-Knotenpools dürfen sich nicht in einer Version befinden, die chronologisch nach der Clusterversion veröffentlicht wurde. Die frühere Version hat nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Version 1.16.6, die nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht wurde, können Sie beispielsweise kein Upgrade Ihres Clusters von Version 1.16.6 auf Version 1.28.100-gke.146 durchführen und einen Worker-Knotenpool in Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool mit Version 1.16.5 belassen haben, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, während 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) Die maximale Versionsverzerrung zwischen einem Worker-Knotenpool und dem Cluster beträgt zwei Nebenversionen, wenn die Vorabversion der n-2-Versionsabweichung aktiviert ist. Wenn Sie diese Funktion nicht aktivieren, beträgt die maximale Versionsabweichung zwischen einem Worker-Knotenpool und dem Cluster eine Nebenversion.

  • Worker-Knotenpools dürfen sich nicht in einer Version befinden, die chronologisch nach der Clusterversion veröffentlicht wurde. Die frühere Version hat nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Version 1.16.6, die nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht wurde, können Sie beispielsweise kein Upgrade Ihres Clusters von Version 1.16.6 auf Version 1.28.100-gke.146 durchführen und einen Worker-Knotenpool in Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool mit Version 1.16.5 belassen haben, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, während 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 ist eine Nebenversion.

  • Worker-Knotenpools dürfen sich nicht in einer Version befinden, die chronologisch nach der Clusterversion veröffentlicht wurde. Die frühere Version hat nicht die umfassenden Details für die spätere Version, was für die Kompatibilität erforderlich ist.

    Version 1.16.6, die nach der Veröffentlichung von Version 1.28.100-gke.146 veröffentlicht wurde, können Sie beispielsweise kein Upgrade Ihres Clusters von Version 1.16.6 auf Version 1.28.100-gke.146 durchführen und einen Worker-Knotenpool in Version 1.16.6 belassen. Wenn Sie Ihren Cluster auf Version 1.28.100-gke.146 aktualisieren, aber einen Worker-Knotenpool mit Version 1.16.5 belassen haben, können Sie den Worker-Knotenpool nicht auf Version 1.16.6 aktualisieren, während der Cluster die Version 1.28.100-gke.146 hat.

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

1,29

Clusterversion (Steuerungsebene) Unterstützte Versionen des 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

Clusterversion (Steuerungsebene) Unterstützte Versionen des Worker-Knotenpools
1.28.600-gke.163
  • 1.28.600-gke.163
  • 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.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.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

Clusterversion (Steuerungsebene) Unterstützte Versionen des 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

Upgrade der Komponenten durchführen

Komponenten werden sowohl auf Knoten- als auch auf Clusterebene aktualisiert. Auf Clusterebene werden die folgenden Komponenten aktualisiert:

  • Clusterkomponenten für Netzwerke, 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 Zu aktualisierende Komponenten
Worker Führt Nutzerarbeitslasten aus Kubelet, Containerlaufzeit (Docker oder containerd)
Steuerungsebene Führt die Kubernetes-Steuerungsebene, Clusterlebenszyklus-Controller und Plattform-Add-ons für die Google Kubernetes Engine (GKE) Enterprise-Version aus Statische Pods der Kubernetes-Steuerungsebene (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)

Lebenszyklus-Controller wie lifecycle-controllers-manager und anthos-cluster-operator

Plattform-Add-ons der Google Kubernetes Engine (GKE) Enterprise-Version wie stackdriver-log-aggregator und gke-connect-agent
Load Balancer der Steuerungsebene Führt HAProxy und Keepa Lively aus, die Traffic an kube-apiserver weiterleiten, und MetalLB-Lautsprecher ausführen, um virtuelle IP-Adressen zu beanspruchen Statische Pods für Load Balancer der Steuerungsebene (HAProxy, Keepa Lively)

MetalLB-Lautsprecher

Erwartungen an Ausfallzeiten

In der folgenden Tabelle sind die erwarteten Ausfallzeiten 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, müssen Sie mit zusätzlichen Ausfallzeiten rechnen. Sofern nicht anders angegeben, gilt diese Ausfallzeit sowohl für Administrator- als auch für Nutzerclusterupgrades:

Komponenten Erwartungen an Ausfallzeiten Wenn Ausfallzeiten auftreten
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 Vom Operator entladen und aktualisiert. Die Ruhezeit sollte weniger als 5 Minuten betragen.

DaemonSets funktionieren weiterhin ohne Ausfallzeiten.		 Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
Container-Netzwerkschnittstelle (CNI) Keine Ausfallzeiten für vorhandene Netzwerkrouten.

DaemonSet wurde zwei zu zwei ohne Ausfallzeiten bereitgestellt.

Der Operator wurde per Drain beendet und ein Upgrade durchgeführt. Die Ausfallzeit beträgt weniger als 5 Minuten.		 Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
MetalLB (nur Nutzercluster) Vom Operator entladen und aktualisiert. Die Ruhezeit beträgt weniger als 5 Minuten.

Keine Ausfallzeit bei vorhandenem Dienst		 Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
CoreDNS und DNS-Autoscaling (nur Nutzercluster) CoreDNS verfügt über mehrere Replikate mit Autoscaling. In der Regel gibt es 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 Operator hat möglicherweise eine Ausfallzeit von 5 Minuten.		 Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
Istio / Ingress Der Istio-Operator wurde per Drain beendet und aktualisiert. Ungefähr 5 Minuten Ausfallzeit.

Vorhandene konfigurierte eingehende Verbindungen funktionieren weiterhin.		 Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
Andere Systembetreiber 5 Minuten Ausfallzeit nach Leeren und Upgrade. Nachdem das Upgrade der Knoten der Steuerungsebene abgeschlossen ist.
Nutzerarbeitslasten Hängt von der Einrichtung ab, z. B. ob hochverfügbar.

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

Die Cluster-Preflight-Prüfung führt vor Beginn des Upgrades zusätzliche Systemdiagnosen für den Cluster aus.

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

  • Mit dem Befehl bmctl upgrade cluster wird eine benutzerdefinierte Ressource PreflightCheck erstellt.
  • Diese Preflight-Prüfung führt zusätzliche Prüfungen aus, z. B. Prüfungen von Clusterupgrades, Netzwerkdiagnosen und Knotendiagnosen.
  • Die Ergebnisse dieser zusätzlichen Prüfungen geben 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 angegebenen Reihenfolge aktualisiert, wie im folgenden Diagramm dargestellt:

Die Load-Balancer und der Knotenpool der Steuerungsebene werden aktualisiert, dann die GKE-Verbindung, die Cluster-Add-ons sowie der Load-Balancer-Knotenpool und die Worker-Knotenpools.

Im obigen Diagramm werden Komponenten in der folgenden Reihenfolge aktualisiert:

  1. Das Upgrade beginnt mit der Aktualisierung des Felds spec.anthosBareMetalVersion.
  2. Für die Load-Balancer der Steuerungsebene wurde ein Upgrade durchgeführt.
  3. Der Knotenpool der Steuerungsebene wird aktualisiert.
  4. Parallel dazu wird ein Upgrade der GKE-Verbindung, der Cluster-Add-ons und des Knotenpools des Load-Balancers durchgeführt.
    1. Nach dem erfolgreichen Upgrade des Load-Balancer-Knotenpools wird das Upgrade auch für die Worker-Knotenpools durchgeführt.

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

    Die Systemdiagnosen werden weiter ausgeführt, bis alle Prüfungen bestanden sind.

  6. Wenn alle Systemdiagnosen bestanden sind, ist das Upgrade abgeschlossen.

Jede Komponente hat in der benutzerdefinierten Clusterressource ein eigenes Statusfeld. Anhand des Status in diesen Feldern können Sie den Fortschritt des Upgrades nachvollziehen:

Sequenz Feldname Bedeutung
1 status.controlPlaneNodepoolStatus Der Status wird aus dem Knotenpoolstatus 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 zuletzt 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 der Version zu Knotennummern.
4 status.anthosBareMetalVersion Endgültiger Status der aktualisierten Version.

Details zu Administrator-, Hybrid- und eigenständigen Clusterupgrades

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 reduziert den Ressourcenbedarf, wodurch Clusterupgrades zuverlässiger und skalierbarer sind.

Obwohl die Verwendung eines Bootstrap-Clusters für das Upgrade nicht empfohlen wird, ist die Option 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 der Umstellung unterscheiden sich je nach verwendeter Methode.

Direkte Upgrades

Der standardmäßige direkte Upgradeprozess für selbstverwaltete Cluster ähnelt dem Upgradeprozess des Nutzerclusters. Wenn Sie jedoch den Prozess für direkte Upgrades verwenden, wird eine neue Version von preflightcheck-operator bereitgestellt, bevor die Cluster-Preflight-Prüfung und die Systemdiagnosen ausgeführt werden:

Bevor die Cluster-Preflight-Prüfung weitere Systemdiagnosen für den Cluster ausführt, wird eine neue Version des Preflightcheck-Operators bereitgestellt.

Wie beim Nutzerclusterupgrade beginnt auch der Upgradeprozess damit, dass das Feld Cluster.spec.anthosBareMetalVersion auf die Zielversion aktualisiert wird. Vor dem Aktualisieren der Komponenten werden zwei zusätzliche Schritte ausgeführt, wie im folgenden Diagramm dargestellt: lifecycle-controller-manager aktualisiert sich selbst auf die Zielversion und stellt dann die Zielversion von anthos-cluster-operator bereit. Dieser anthos-cluster-operator führt die verbleibenden Schritte des Upgradeprozesses aus:

Der „Lifecycle-controller-manager“ und der anthos-cluster-operator werden bereitgestellt, bevor für den Rest des Clusters ein Upgrade in der gleichen Reihenfolge wie die Komponenten im Nutzercluster durchgeführt wird.

Bei Erfolg gleicht anthos-cluster-operator die Zielversion von spec.anthosBareMetalVersion mit status.anthosBareMetalVersion ab.

Mit einem Bootstrap-Cluster upgraden

Das Upgrade eines Administrator-, Hybrid- oder eigenständigen Clusters ähnelt dem eines Nutzerclusters, 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 Inhaberschaft des Clusters an den Bootstrap-Cluster wird als Pivot bezeichnet. Der Rest des Upgrades folgt demselben Prozess wie das Upgrade des Nutzerclusters.

Während des Upgrades bleiben die Ressourcen im Zielcluster veraltet. Der Fortschritt des Upgrades wird nur in den Ressourcen des Bootstrap-Clusters angezeigt.

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 Verwaltung des Clusters nach Abschluss des Upgrades wieder zu übertragen, verschiebt der Cluster die Ressourcen vom Bootstrap-Cluster auf den aktualisierten Cluster. Sie müssen während des Upgrades keine manuellen Schritte ausführen, um den Cluster neu zu pivotieren. Der Bootstrap-Cluster wird gelöscht, nachdem das Clusterupgrade abgeschlossen ist.

Knotenausgleich

Google Distributed Cloud-Clusterupgrades können zu Anwendungsunterbrechungen führen, da die Knoten per Drain beendet werden. Durch diesen Ausgleichsprozess werden alle auf einem Knoten ausgeführten Pods heruntergefahren und auf den verbleibenden Knoten im Cluster neu gestartet.

Bereitstellungen können solche Störungen tolerieren. In einem 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 bis gar nicht zu Unterbrechungen kommen.

PodDisruptionBudgets (PDBs)

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

Ab Version 1.29 werden Knoten mit der Eviation API per Drain beendet, die PodDisruptionBudgets (PDBs) würdigt. Mit PDBs kann dafür gesorgt werden, dass immer eine definierte Anzahl von Replikaten im Cluster unter normalen Bedingungen ausgeführt wird. Mit PDBs können Sie die Unterbrechung einer Arbeitslast begrenzen, wenn deren Pods neu geplant werden müssen. Der entfernungsbasierte Knotenausgleich ist ab Version 1.29 allgemein verfügbar.

In den Versionen 1.28 und früheren Versionen berücksichtigt Google Distributed Cloud keine PDBs, wenn Knoten während eines Upgrades geleert werden. Der Knotenausgleich ist stattdessen der Best-Effort-Prozess. 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 für einen Knoten mehr als 20 Minuten dauert.

Weitere Informationen finden Sie unter Knoten in den Wartungsmodus versetzen.

Nächste Schritte