Diese Seite wurde von der Cloud Translation API übersetzt.

Clusterupgrades mit Roll-out-Sequenzierung

Autopilot Standard

Sie können die Reihenfolge automatischer Clusterupgrades in Google Kubernetes Engine-Clustern (GKE) in mehreren Umgebungen mithilfe der Roll-out-Sequenzierung verwalten. Sie können beispielsweise eine neue Version in Vorproduktionsclustern qualifizieren, bevor Sie Produktionscluster upgraden. GKE bietet auch eine Version der Roll-out-Sequenzierung, die benutzerdefinierte Phasen verwendet (Vorschau), um Ihnen eine detailliertere Kontrolle über Cluster-Upgrades zu ermöglichen.

In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:

Informationen zum Konfigurieren einer Roll-out-Sequenz finden Sie unter Roll-out von Clusterupgrades sequenzieren.

Übersicht

Mit der GKE-Roll-out-Sequenzierung können Sie eine bestimmte, geordnete Sequenz für Clusterupgrades in verschiedenen Umgebungen definieren, z. B. zuerst die Cluster in der Entwicklungsumgebung, dann die Testumgebung und schließlich die Produktionsumgebung aktualisieren. Diese progressive Strategie bietet eine integrierte Testphase, in der Sie potenzielle Probleme erkennen und beheben können, bevor das Upgrade Ihre wichtigsten Systeme erreicht.

Die Roll-out-Sequenzierung basiert auf dem Konzept von Flotten, die logische Gruppierungen von GKE-Clustern sind, die einer Umgebung (z. B. Test) zugeordnet sind. Um diese Funktion zu verwenden, definieren Sie eine Sequenz aus Flotten und legen die Betriebszeit zwischen den einzelnen Gruppen fest. Wenn GKE eine neue Version auswählt, werden Ihre Cluster in der definierten Reihenfolge aktualisiert. So können Sie Arbeitslasten validieren, bevor die Version vollständig in Ihrer Produktionsumgebung bereitgestellt wird.

Flotten unterstützen einfache Mitgliedschaften, mit denen Sie Cluster logisch für die Bereitstellungsreihenfolge gruppieren können, ohne alle Konfigurationen und Funktionen auf Flottenebene zu aktivieren. Die eingeschränkte Mitgliedschaft ist eine gute Wahl, wenn Sie die sequenzielle Einführung nutzen möchten, ohne dass die anderen Auswirkungen der vollständigen Flottenverwaltung wie die Namespace-Gleichheit auf Flottenebene eintreten. Weitere Informationen finden Sie unter Lightweight Memberships.

Strategie für die Reihenfolge des Roll-outs auswählen

GKE bietet zwei Versionen der Roll-out-Sequenzierung. Beide Versionen basieren auf denselben Grundprinzipien für progressive, flottenbasierte Upgrades, bieten aber unterschiedliche Flexibilitätsgrade. In diesem Abschnitt erfahren Sie, welche Version für Ihren Anwendungsfall am besten geeignet ist.

Flottenbasierte Roll-out-Sequenzierung (GA):Diese Version ist die empfohlene Strategie für die meisten Produktionsanwendungsfälle. Die flottenbasierte Roll-out-Sequenzierung bietet eine stabile und unterstützte Methode zum schrittweisen Roll-out von Upgrades in verschiedenen Umgebungen (z. B. Test, Staging und Produktion) und verwendet eine lineare Abfolge von Flotten.
Rollout-Sequenzierung mit benutzerdefinierten Phasen (Vorabversion):Diese Version ist eine Weiterentwicklung des flottenbasierten Modells und bietet eine genauere Steuerung und mehr Flexibilität. Mit benutzerdefinierten Phasen können Sie bestimmte Phasen innerhalb einer Flotte mithilfe von Labels definieren. Das ist eine gute Option für komplexere Rollout-Strategien, z. B. wenn Sie eine neue Version auf einer kleinen Teilmenge von Produktionsclustern bereitstellen möchten, bevor Sie sie auf alle Cluster ausweiten. Wählen Sie diese Option aus, wenn Sie mehr Flexibilität benötigen oder die neuesten Funktionen für die Rollout-Sequenzierung testen möchten.

Flottenbasierte Roll-out-Sequenz

Verwenden Sie Flotten, um Cluster automatisch mit Roll-out-Sequenzierung zu aktualisieren. Dort haben Sie Ihre Cluster mit derselben Release-Version und derselben Nebenversion in Bereitstellungsphasen gruppiert. Definieren Sie die Reihenfolge der Flotten und die Betriebszeit, die zwischen den einzelnen Clustergruppen gewünscht ist. Wenn GKE dann eine neue Version für automatische Upgrades in der Release-Version auswählt, werden Ihre Gruppen von Clustern in der von Ihnen definierten Reihenfolge aktualisiert. Sie können prüfen, ob Arbeitslasten mit einer neuen Version wie erwartet ausgeführt werden, bevor Upgrades für Ihre Produktionscluster beginnen.

Das folgende Diagramm zeigt, wie GKE Cluster automatisch in einer mit Flotten organisierten Roll-out-Sequenz aktualisiert:

Flottenbasierte Roll-out-Sequenz, bei der Sie Cluster in Flotten gruppieren. — **Abbildung** : Flottenbasierte Roll-out-Sequenz

Wenn GKE bei einer flottenbasierten Sequenz ein neues Upgrade-Ziel im Release-Channel zur Verfügung stellt, in dem alle Cluster in dieser Sequenz registriert sind, führt GKE Upgrades für diese Clusterflotten in dieser Sequenz durch. Dabei qualifizieren die Cluster der vorgelagerten Flotte die neue Version für Cluster in der nachgelagerten Flotte. Dies gilt für bis zu fünf Flotten. Bezieht sich in einer Roll-out-Sequenz vorgelagert auf die vorherige Gruppe und nachgelagert auf die nächste Gruppe.

Während der konfigurierten Betriebszeit zwischen Flotten können Sie prüfen, ob Ihre Arbeitslasten auf den aktualisierten Clustern wie erwartet ausgeführt werden.

Roll-out-Sequenzierung mit benutzerdefinierten Phasen

Wenn Sie die Roll-out-Sequenzierung mit benutzerdefinierten Phasen verwenden, definieren Sie die Reihenfolge der Flotten-Upgrades und legen die Soak-Zeiten fest. Außerdem haben Sie folgende Möglichkeiten:

Definieren Sie eine Sequenz mit detaillierten Phasen, die mithilfe von Labels auf bestimmte Teilmengen von Clustern in einer Flotte ausgerichtet werden können. Das macht sie zu einer guten Wahl für Strategien wie stufenweise Einführungen.
Mit den neuen API-Objekten RolloutSequence und Rollout haben Sie mehr Kontrolle und Transparenz.

Diese Methode bietet die größte Flexibilität und detaillierte Kontrolle über Ihre Clusterupgrades. Wenn Sie bestimmte Teilmengen von Clustern in einer Flotte als Ziel auswählen möchten, verwenden Sie ein label-selector, um nur die Cluster mit bestimmten Kubernetes-Labels als Ziel auszuwählen.

Das folgende Diagramm zeigt, wie GKE Cluster automatisch in einer Roll-out-Sequenz mit benutzerdefinierten Phasen aktualisiert. Die Stufe zielt auf Cluster mit einem label-selector namens canary in der Flotte prod ab:

Roll-out-Sequenz mit benutzerdefinierten Phasen in GKE — **Abbildung** : Einführungssequenz mit benutzerdefinierten Phasen

Wenn ein neues Upgrade-Ziel im Release-Channel verfügbar wird, in dem alle Cluster in dieser Sequenz registriert sind, aktualisiert GKE zuerst die Cluster in der Testflotte und dann die Cluster in der Staging-Flotte. In der Produktionsflotte priorisiert GKE dann Cluster, die mit label-selector übereinstimmen. Da prod-cluster-1 mit canary: true gekennzeichnet ist, wird dieser Cluster als Nächstes von GKE aktualisiert. GKE führt am Ende des Prozesses Upgrades für alle verbleibenden Cluster in der Produktionsflotte (in der Hauptphase) durch, da diese Phase keine Labelauswahl hat.

Während der konfigurierten Betriebszeit zwischen Phasen können Sie prüfen, ob Ihre Arbeitslasten auf den aktualisierten Clustern wie erwartet ausgeführt werden. Im vorherigen Beispiel ist eine benutzerdefinierte Phase in der Produktionsflotte zu sehen. Sie können jedoch einer beliebigen Flotte mehrere Phasen hinzufügen oder nur eine Flotte mit mehreren Phasen verwenden.

Weitere Informationen zur Roll-out-Sequenzierung mit benutzerdefinierten Phasen finden Sie unter Roll-out-Sequenzierung mit benutzerdefinierten Phasen.

Der Rest dieses Dokuments bezieht sich nur auf die Sequenzierung des flottenbasierten Roll-outs.

So aktualisiert GKE Cluster in einer Roll-out-Sequenz

Wenn GKE einen Cluster aktualisiert, werden zuerst die Steuerungsebene und dann die Knoten aktualisiert. Bei einer Roll-out-Sequenz werden Cluster weiterhin anhand dieses Prozesses aktualisiert. Sie steuern aber auch die Reihenfolge, in der Gruppen (Flotten) von Clustern aktualisiert werden. Außerdem geben Sie eine Betriebszeit an, die definiert, wie lange GKE pausiert, bevor Upgrades von einer Gruppe zur nächsten Gruppe übergehen.

Clusterupgrades in einer Roll-out-Sequenz werden mit den folgenden Schritten fortgesetzt:

GKE legt ein neues Ziel für automatische Upgrades für Cluster in einer Nebenversion in einer bestimmten Release-Version fest. Die Versionshinweise ähneln der folgenden Meldung: „Steuerungsebenen und Knoten mit aktiviertem automatischen Upgrade in Regular channel werden mit diesem Release von Version 1.29 auf Version 1.30.14-gke.1150000 aktualisiert.“
GKE beginnt mit dem Upgrade der Clustersteuerungsebenen auf die neue Version in der ersten Gruppe von Clustern. Nachdem GKE die Steuerungsebene eines Clusters aktualisiert hat, aktualisiert GKE die Knoten des Clusters. GKE berücksichtigt beim Upgrade von Clustern in einer Roll-out-Sequenz die Wartungsverfügbarkeit.
GKE führt die folgenden Schritte für Upgrades der Steuerungsebene aus:
1. Nachdem alle Upgrades der Clustersteuerungsebene in der ersten Gruppe abgeschlossen sind, beginnt GKE mit dem Betriebszeitraum für Upgrades der Steuerungsebene. GKE beginnt den Betriebszeitraum auch, wenn seit Beginn der Upgrades der Steuerungsebene mehr als 30 Tage vergangen sind.
2. Nach Abschluss des Betriebszeitraums für die Upgrades der Clustersteuerungsebene der ersten Gruppe beginnt GKE mit dem Upgrade der Steuerungsebenen der zweiten Gruppe auf die neue Version. Beachten Sie jedoch Folgendes:
  - In einigen Fällen aktualisiert GKE die Clustersteuerungsebenen der ersten Gruppe mehrmals, bevor die Clustersteuerungsebenen der zweiten Gruppe aktualisiert werden. In diesem Fall wählt GKE die neueste Version aus, die auch die folgenden Attribute hat:
    - Die Version wird durch die erste Gruppe qualifiziert.
    - Die Version ist höchstens eine Nebenversion später als die Version der Steuerungsebene der Cluster der zweiten Gruppe.
  - GKE aktualisiert die Steuerungsebene von Clustern in der zweiten Gruppe, die eine neuere Version als das von der ersten Gruppe qualifizierte Ziel für automatische Upgrades haben, nicht.
Parallel zu Upgrades der Steuerungsebene führt GKE die folgenden Schritte für Knotenupgrades aus:
1. Nachdem alle Knotenupgrades der Cluster in der ersten Gruppe abgeschlossen sind, beginnt GKE mit dem Betriebszeitraum für Knotenupgrades. GKE beginnt auch mit dem Betriebszeitraum, wenn seit Beginn der Knotenupgrades mehr als 30 Tage vergangen sind.
2. Nach Abschluss des Betriebszeitraums für die Knotenupgrades der ersten Gruppe beginnt GKE mit dem Upgrade der Knoten der zweiten Gruppe auf die neue Version. Beachten Sie jedoch Folgendes:
  - In einigen Fällen aktualisiert GKE die Clusterknoten der ersten Gruppe möglicherweise mehrmals, bevor die Clusterknoten der zweiten Gruppe aktualisiert werden. In diesem Fall wählt GKE die neueste Version aus, die auch die folgenden Attribute hat:
    - Die Version wird durch die erste Gruppe qualifiziert.
    - Die Version ist nicht neuer als die Version der Cluster-Steuerungsebene der zweiten Gruppe.
  - GKE führt keine Upgrades für die Knoten von Clustern in der zweiten Gruppe durch, die eine neuere Version als das von der ersten Gruppe qualifizierte Ziel für automatische Upgrades haben.
GKE wiederholt diese Schritte von der zweiten Gruppe bis zur dritten Gruppe, bis Cluster in allen Gruppen in der Roll-out-Sequenz auf das neue Upgrade-Ziel aktualisiert wurden.

Prüfen Sie, wenn Cluster in jeder Gruppe aktualisiert werden, während der Betriebszeit, ob Ihre Arbeitslasten mit Clustern, auf denen die neue GKE-Version ausgeführt wird, wie erwartet funktionieren .

Es kann auch vorkommen, dass Cluster aufgrund von Wartungsfenstern oder -ausschlüssen, einer verworfenen API-Nutzung oder aus anderen Gründen nicht aktualisiert werden.

Upgrades in einer Roll-out-Sequenz steuern

Bei Clusterupgrades in einer Roll-out-Sequenz werden Clustergruppen in der von Ihnen definierten Reihenfolge aktualisiert und die Betriebszeit jeder Gruppe wird von Ihnen ausgewählt. Während Upgrades ausgeführt werden, können Sie den Status prüfen und nach Bedarf die Roll-out-Sequenz verwalten. Sie können den Prozess auch so steuern:

Für eine Gruppe in einer Roll-out-Sequenz können Sie die Standard-Betriebszeit überschreiben, wenn sie für eine bestimmte Version länger oder kürzer sein muss.

Für einzelne Clusterupgrades können Sie weiterhin die folgenden Tools verwenden:
- Upgrades manuell steuern, indem Sie beispielsweise Knotenpool-Upgrades abbrechen, fortsetzen, ein Rollback für sie durchführen oder sie abschließen.
- Verwenden Sie Wartungsfenster und -ausschlüsse, um zu entscheiden, wann ein Cluster aktualisiert werden kann und wann nicht.
- Konfigurieren Sie Knotenupgrade-Strategien, um je nach den auf diesen Knoten ausgeführten Arbeitslasten ein Gleichgewicht zwischen Geschwindigkeit und Risikotoleranz zu finden.

Beispiel: Community-Bank führt Änderungen nach und nach aus der Testphase in die Produktion ein

Der Plattformadministrator einer Community-Bank verwaltet beispielsweise drei Hauptbereitstellungsumgebungen: Tests, Staging und Produktion. Jede Umgebung hat eine Gruppe von Clustern, die in einer Flotte organisiert sind. Wie es bei der Roll-out-Sequenzierung erforderlich ist, hat der Administrator jeden Cluster bei allen drei Flotten in derselben Release-Version (in diesen Flotten der Regular Channel) registriert, wobei in allen Clustern dieselbe Nebenversion ausgeführt wird.

Der Administrator verwendet die Roll-out-Sequenzierung, um die Reihenfolge festzulegen, in der GKE Cluster in diesen Umgebungen aktualisiert. Wenn Sie den Roll-out bestellen, kann der Administrator prüfen, ob seine Arbeitslasten wie erwartet mit Clustern in einer neuen GKE-Version ausgeführt werden, bevor die Produktionsumgebung auf die neue Version aktualisiert wird. Diese Sequenz wird durch das Diagramm einer flottenbasierten Roll-out-Sequenz veranschaulicht.

Der Administrator nutzt die Betriebszeit zwischen den Flotten, um zu prüfen, ob seine Arbeitslasten wie erwartet mit der neuen GKE-Version ausgeführt werden. Für die Testflotte legt der Administrator die Betriebszeit auf 14 Tage fest, sodass er zwei volle Wochen Zeit hat, um zu testen, wie die Arbeitslasten ausgeführt werden. Für das Staging legt er die Betriebszeit auf 7 Tage fest, da er nicht so viel zusätzliche Zeit benötigt, nachdem die Arbeitslasten bereits beim Testen ausgeführt wurden.

Der Administrator kann auch die Standardbetriebszeit für Upgrades auf bestimmte Versionen überschreiben, was in den folgenden Situationen sinnvoll sein kann:

Der Administrator schließt die Qualifikation der Version vor dem Ende der Betriebszeit ab und möchte, dass Upgrades mit der nächsten Flotte fortgeführt werden. Die Betriebszeit wird daher auf null gesetzt.
Der Administrator benötigt mehr Zeit, um die neue Version zu qualifizieren, bevor Upgrades mit der nächsten Flotte fortgesetzt werden können, da er ein Problem mit einigen der Arbeitslasten festgestellt hat. Er setzt die Betriebszeit daher auf das Maximum von 30 Tagen.

Der Administrator verwendet Wartungsfenster und -ausschlüsse, damit GKE Cluster aktualisiert, wenn es für die Bank die wenigsten Störungen verursacht. GKE berücksichtigt die Wartungsverfügbarkeit für Cluster, die in einer Roll-out-Sequenz aktualisiert werden.

Der Administrator hat Wartungsfenster für seine Cluster konfiguriert, damit GKE Cluster nur nach den Geschäftszeiten aktualisiert.
Der Administrator verwendet Wartungsausschlüsse, um vorübergehend zu verhindern, dass Cluster aktualisiert werden, wenn Probleme mit den Arbeitslasten des Clusters erkannt werden.

Der Administrator verwendet eine Mischung aus Surge-Upgrades und Blau/Grün-Upgrades für seine Knoten, wobei je nach den Arbeitslasten, die auf diesen Knoten ausgeführt werden, ein Gleichgewicht zwischen Geschwindigkeit und Risikotoleranz gesucht wird.

Flottenbasierte Roll-out-Berechtigung

Damit Cluster automatisch mit Roll-out-Sequenzierung aktualisiert werden, müssen alle Cluster in allen Flotten in einer Roll-out-Sequenz dasselbe Upgrade-Ziel erhalten. Cluster müssen in derselben Release-Version registriert sein. Außerdem wird empfohlen, dass Cluster dieselbe Nebenversion ausführen und dass die Upgrade-Ziele pro Nebenversion festgelegt werden. Bei einigen Releases, wie dem Release im folgenden Beispiel, haben Cluster aus mehreren Nebenversionen dasselbe Ziel erhalten, was bedeutet, dass die Cluster in der Roll-out-Sequenz mit mehreren Nebenversionen erfolgreich aktualisiert werden können.

Sie können den Status des Versions-Roll-outs in einer Sequenz prüfen, um weitere Informationen zum Status zu erhalten und zu ermitteln, ob Probleme mit der Versionsberechtigung das Fortsetzen der Upgrades verhindern. Je nach Versionsabweichungen müssen Sie möglicherweise Maßnahmen ergreifen, z. B. ein manuelles Upgrade eines Clusters ausführen oder ihn aus einer Gruppe entfernen, damit die Clusterupgrades fortgesetzt werden. Wenn ein Cluster in einer Roll-out-Sequenz kein zulässiges Upgradeziel hat, führt GKE kein automatisches Upgrade des Clusters durch, bis die vorhandene Nebenversion des Clusters das Ende des Supports erreicht hat.

Informationen zur Fehlerbehebung in Bezug auf die Roll-out-Berechtigung finden Sie unter Fehler bei der Roll-out-Berechtigung beheben.

Beispiel für einen GKE-Release

Der Release 2025-R45 legt beispielsweise ein Upgradeziel für mehrere Nebenversionen in Clustern fest, die für den Regular Channel registriert sind. Ein Upgradeziel kann eine neue Nebenversion (1.30 bis 1.31) oder einfach eine neue Patchversion (1.31.x-gke.x bis 1.31.13-gke.1023000) sein. In diesem Release wurden im Regular Channel die folgenden neuen Versionen für Cluster in bestimmten Nebenversionen zur Verfügung gestellt:

Cluster unter 1.30 wurden auf 1.31.13-gke.1023000 aktualisiert.
Cluster unter 1.31 wurden auf 1.32.9-gke.1108000 aktualisiert.
Cluster unter 1.32 wurden auf 1.33.5-gke.1162000 aktualisiert.

Die am weitesten vorgelagerte Gruppe erhält alle Upgradeziele

Bei Clustern in der ersten Gruppe in einer Sequenz, die keine vorgelagerte Gruppe hat, um neue Versionen zu qualifizieren, aktualisiert GKE alle Cluster mit geeigneten Upgradezielen, unabhängig davon, ob sich diese Upgradeziele voneinander unterscheiden. Wenn in der ersten Gruppe einer Sequenz beispielsweise einige Cluster mit Version 1.30 ausgeführt wurden, könnten diese Cluster auf Version 1.31.13-gke.1023000 aktualisiert werden, während Cluster mit Version 1.32 auf Version 1.33.5-gke.1162000 aktualisiert werden könnten. Dies liegt daran, dass GKE für die erste Gruppe in einer Abfolge alle Upgradeziele als für diese Cluster qualifiziert betrachtet, da es keine vorgelagerte Gruppe gibt, um eine neue Version zu qualifizieren.

Eine vorgelagerte Gruppe darf nur eine Version qualifizieren

Damit das Upgrade von Clustern in einer nachgelagerten Gruppe beginnen kann, muss die vorgelagerte Gruppe ein einzelnes, gemeinsames Upgradeziel erfolgreich qualifiziert haben, für das alle Cluster in der nachgelagerten Gruppe berechtigt sind. Wenn die vorgelagerte Gruppe Cluster enthält, die erfolgreich auf zwei verschiedene Versionen aktualisiert wurden (was passieren kann, wenn die vorgelagerte Gruppe die erste Gruppe in einer Sequenz ist), qualifiziert die vorgelagerte Gruppe die niedrigere der beiden Versionen als gemeinsames Upgradeziel für die nachgelagerte Gruppe. Wenn in der vorgelagerten Gruppe beispielsweise einige Cluster auf 1.31.13-gke.1023000 und andere auf 1.33.5-gke.1162000 aktualisiert wurden, qualifiziert die Gruppe 1.31.13-gke.1023000 als gemeinsames Upgradeziel für die nachgelagerte Gruppe.

Cluster mit Versionen, die neuer als das Upgradeziel sind, verhindern keine Upgrades.

Wenn in einer nachgelagerten Gruppe Cluster vorhanden sind, auf denen eine neuere Version als das von einer vorgelagerten Gruppe qualifizierte Upgradeziel ausgeführt wird, aktualisiert GKE die für das Upgradeziel berechtigten Cluster und ignoriert die Cluster, auf denen bereits eine neuere Version ausgeführt wird. Dieses Verhalten verhindert nicht, dass die Roll-out-Sequenz fortgesetzt wird, solange mindestens ein Cluster in der nachgelagerten Gruppe für das Upgrade-Ziel infrage kommt.

Wenn die vorgelagerte Gruppe beispielsweise das Upgrade auf Version 1.32 qualifiziert hat und in der nachgelagerten Gruppe Cluster mit Version 1.31 und Version 1.33 ausgeführt werden, aktualisiert GKE die Cluster mit Version 1.31 auf Version 1.32 und ignoriert die Cluster mit Version 1.33.

Eine vorgelagerte Gruppe muss eine Version qualifizieren, die mit den Clustern der nächsten Gruppe übereinstimmt

Wenn Cluster in einer vorgelagerten Gruppe eine andere Version als jene qualifizieren würden, für die Cluster in der nächsten Gruppe berechtigt sind, könnte GKE die Cluster auch nicht automatisch in nachgelagerten Gruppen aktualisieren.

Wenn beispielsweise alle Cluster in der ersten Gruppe auf 1.31.13-gke.1023000 aktualisiert wurden, die Cluster in der zweiten Gruppe jedoch eine neuere Version wie 1.32.9-gke.1108000 ausführen, werden die Cluster der zweiten Gruppe nicht automatisch aktualisiert. Die erste Gruppe würde 1.31.13-gke.1023000 qualifizieren, aber die Cluster in der zweiten Gruppe (derzeit mit 1.32) sind nur für das Upgrade-Ziel 1.33.5-gke.1162000 berechtigt, sodass GKE diese Cluster nicht automatisch aktualisieren kann. Informationen zum Fortführen von Upgrades in diesem Fall finden Sie unter Berechtigung zwischen Gruppen korrigieren.

Die vorgelagerte Gruppe hat mehrere Upgradeziele für die nachgelagerte Gruppe qualifiziert

Wenn GKE die Cluster in der vorgelagerten Gruppe mehrmals aktualisiert hat, bevor die Cluster in der nachgelagerten Gruppe aktualisiert wurden, aktualisiert GKE die Cluster in der nachgelagerten Gruppe auf die neueste Version, die von der vorgelagerten Gruppe qualifiziert wurde und für die die Cluster in der nachgelagerten Gruppe berechtigt sind. Bei Upgrades der Steuerungsebene kann diese Version höchstens eine Nebenversion später als die Version der Steuerungsebene der Cluster in der Downstream-Gruppe sein. Bei Knoten-Upgrades kann diese Version gleich der Version der Steuerungsebene der Cluster in der nachgelagerten Gruppe sein, aber nicht später.

Dieses Szenario ist beispielsweise relevant, wenn Sie Wartungsausschlüsse konfiguriert haben, um Upgrades für Ihre Downstream-Gruppe, die Ihre Produktionscluster enthält, vorübergehend zu verhindern. In Ihrer Upstream-Gruppe, die Vorproduktionscluster umfasst, wurden jedoch keine Wartungsausschlüsse verwendet, um Upgrades zu verhindern. Ihre vorgelagerte Gruppe wurde also mehrmals aktualisiert, wodurch mehrere potenzielle Upgradeziele infrage kamen, während Ihre nachgelagerte Gruppe nicht aktualisiert wurde.

Upgrades, die nicht innerhalb von 30 Tagen abgeschlossen werden, werden zwangsweise in die Betriebsphase versetzt, um die Sequenz zu entblocken.

Damit eine Roll-out-Sequenz Cluster-Upgrades abschließt, beginnt GKE den Betriebszeitraum für eine Gruppe, wenn die Upgrades der Steuerungsebene oder der Knoten nicht innerhalb der maximalen Upgrade-Zeit (30 Tage) für alle Cluster abgeschlossen sind. Die Upgrades für alle verbleibenden Cluster in der Gruppe können während des Soak-Zeitraums fortgesetzt werden. Weitere Informationen finden Sie in der Zeile für FORCED_SOAKING in der Tabelle mit Statusinformationen für eine Roll-out-Sequenz.

So funktioniert die flottenbasierte Roll-out-Sequenzierung mit anderen Upgradefunktionen

Die Roll-out-Sequenzierung ist ein Feature in einer Sammlung von Features, mit denen Sie den Upgradeaspekt des Clusterlebenszyklus steuern können. In diesem Abschnitt wird erläutert, wie dieses Feature mit einigen der anderen verfügbaren Features im Zusammenhang mit Clusterupgrades funktioniert.

So funktioniert die flottenbasierte Roll-out-Sequenzierung mit Wartungsfenstern und -ausschlüssen

GKE berücksichtigt Wartungsfenster und Wartungsausschlüsse, wenn Cluster mit Roll-out-Sequenzierung aktualisiert werden. GKE startet ein Clusterupgrade nur innerhalb des Wartungsfensters eines Clusters. Mit einem Wartungsausschluss können Sie vorübergehend verhindern, dass ein Cluster aktualisiert wird. Wenn GKE einen Cluster aufgrund eines Wartungsfensters oder -ausschlusses nicht upgraden kann, kann dies dazu führen, dass Clusterupgrades in einer Gruppe nicht abgeschlossen werden. Wenn ein Clusterupgrade aufgrund von Wartungsfenstern oder -ausschlüssen nicht innerhalb von 30 Tagen abgeschlossen werden kann, geht die Gruppe in die Betriebsphase über, unabhängig davon, ob alle Cluster aktualisiert wurden.

Sie können Wartungsausschlüsse als temporäre Maßnahme verwenden, um zu verhindern, dass eine Sequenz ein Roll-out für eine Gruppe durchführt und mit der nächsten Gruppe fortfährt. Weitere Informationen finden Sie unter Abschluss des Versions-Roll-outs der Gruppe verzögern.

So funktioniert die flottenbasierte Roll-out-Sequenzierung, wenn die Nutzung verworfener APIs und Elemente erkannt wird

GKE pausiert Clusterupgrades, wenn die Nutzung bestimmter verworfener APIs und Features erkannt wird. Automatische Upgrades werden für Cluster in einer Gruppe in einer Roll-out-Sequenz ebenfalls angehalten. Weitere Informationen finden Sie unter Einstellung von Kubernetes und GKE.

So funktioniert die Roll-out-Sequenzierung mit Upgradestrategien für Knoten

Knotenupgrades verwenden ihre konfigurierte Strategie für Knotenupgrades, wenn für sie ein Upgrade in einer Roll-out-Sequenz durchgeführt wird. Wie bei Clusterupgrades ohne Roll-out-Sequenzierung verwendet GKE Surge-Upgrades für Autopilot-Knoten. Weitere Informationen finden Sie unter Automatische Knotenupgrades.

Wenn Knotenupgrades nicht innerhalb von 30 Tagen abgeschlossen werden können, wechselt die Gruppe in die Betriebsphase, unabhängig davon, ob alle Cluster aktualisiert wurden. Dies kann passieren, wenn die Upgradestrategie für Knoten dazu führt, dass das Upgrade eines Knotens für einen Standardcluster länger dauert, insbesondere wenn es sich um einen großen Knotenpool handelt. Dies kann auch aufgrund von Wartungsfenstern der Fall sein, die nicht groß genug sind, um ein Upgrade eines Knotens abzuschließen.

So funktioniert die Roll-out-Sequenzierung mit Release-Versionen

Für die Verwendung der Roll-out-Sequenzierung sind Release-Versionen erforderlich. Alle Cluster in allen Gruppen einer Roll-out-Sequenz müssen sich in derselben Release-Version befinden.

Mehrere Upgrades innerhalb einer Sequenz erhalten

Wenn eine neue Version zu einem Upgradeziel für die Release-Version wird, während Clusterupgrades auf ein vorheriges Upgradeziel weiterhin in der Roll-out-Sequenz fortgesetzt werden, kann eine vorgelagerte Gruppe mit dem Roll-out einer neuen Version beginnen, während eine nachgelagerte Gruppe noch das vorherige Upgrade erhält. Wenn beispielsweise die dritte Gruppe in einer Sequenz 1.31.12-gke.1265000 einführt, kann die erste Gruppe in der Sequenz gleichzeitig 1.31.13-gke.1008000 einführen.

Überlegungen bei der Auswahl der flottenbasierten Roll-out-Sequenzierung

Ziehen Sie die Verwendung einer Roll-out-Sequenzierung in Betracht, wenn Sie Clusterupgrades verwalten möchten, indem Sie neue Versionen in einer Umgebung qualifizieren, bevor Sie sie in einer anderen bereitstellen.

Diese Strategie ist jedoch möglicherweise nicht die richtige Wahl für Ihre Umgebung, wenn eine der folgenden Aussagen zutrifft:

Sie haben Cluster, die sich nicht in derselben Release-Version oder Nebenversion in derselben Produktionsumgebung befinden.
Sie müssen Upgrades automatisieren, die nicht nur fünf Bereitstellungsphasen zugeordnet werden können, da Sie lediglich eine Roll-out-Sequenz mit bis zu fünf Gruppen von Clustern erstellen können. Sie können Gruppen in mehreren Roll-out-Sequenzen nicht verknüpfen, um eine Roll-out-Sequenz mit mehr als fünf Gruppen zu erstellen. Flottenbasierte Sequenzen können bis zu fünf Flotten umfassen.
Sie führen häufig manuelle Upgrades durch, die dazu führen, dass Cluster in einer Gruppe unterschiedliche automatische Upgrade-Zielversionen haben.

Einschränkungen der flottenbasierten Roll-out-Sequenzierung

Für ein erfolgreiches Upgrade Ihrer Cluster mit Roll-out-Sequenzierung müssen Sie die folgenden Einschränkungen beachten:

Achten Sie darauf, dass alle Cluster in einer Roll-out-Sequenz in derselben Release-Version registriert sind. Außerdem empfehlen wir, dass alle Cluster dieselbe Nebenversion ausführen, um ein Upgradeziel zu qualifizieren. Weitere Informationen finden Sie unter Roll-out-Berechtigung.
Erstellen Sie eine lineare Roll-out-Sequenz ohne Zyklen (eine Gruppe hat eine nachgelagerte Gruppe als vorgelagerte Gruppe) oder Zweige (eine Gruppe hat mehr als eine nachgelagerte Gruppe).
Erstellen Sie eine Roll-out-Sequenz zwischen Clustern in derselben Organisation. Sie können keine Sequenzen mit Clustern über mehrere Organisationen hinweg erstellen.

Bekannte Probleme bei der flottenbasierten Roll-out-Sequenzierung

Wenn eine Gruppe Cluster an verschiedenen Standorten enthält, ist ein Clusterupgrade aufgrund des graduellen Roll-outs der neuen Version möglicherweise vorübergehend nur für einige Cluster verfügbar. Dies ist für die erste Gruppe von Clustern wahrscheinlicher und sollte innerhalb einer Woche gelöst werden.
Wenn eine Roll-out-Sequenz eine leere Gruppe enthält, hängt es von folgenden Bedingungen ab, wie sich dies auf die Versionsqualifizierung auswirkt:
- Wenn die leere Gruppe keine vorgelagerte Gruppe hat, können Clusterupgrades nicht mit der nachgelagerten Gruppe fortfahren, da die leere Gruppe keine Versionen qualifizieren kann.
- Wenn die leere Gruppe eine vorgelagerte Gruppe hat, wechseln alle ausstehenden Clusterupgrades in den Status COMPLETE und werden an die nachgelagerte Gruppe weitergegeben.