Clusterupgrades mit Roll-out-Sequenzierung

Sie können die Reihenfolge und den zeitlichen Ablauf von Clusterupgrades in GKE-Clustern (Google Kubernetes Engine) in mehreren Umgebungen mithilfe von Roll-out-Sequenzierung verwalten. Sie können beispielsweise eine neue Version in Vorproduktionsclustern qualifizieren, bevor Sie Produktionscluster upgraden. Informationen für den Einstieg finden Sie unter Clusterupgrades in Produktionsumgebungen verwalten.

In diesem Dokument wird die private Vorschau für die Roll-out-Sequenzierung erläutert. Weitere Informationen dazu, wie sich dieses Feature nach dieser Startphase ändert, finden Sie unter Änderung der Roll-out-Sequenzierung nach der privaten Vorschau.

Zum Verwalten von Clusterupgrades mithilfe der Roll-out-Sequenzierung organisieren Sie zuerst Ihre Cluster in Flotten und Flottenbereichen. Mit Flotten können Sie Cluster logisch gruppieren und normalisieren, z. B. nach ihrer Zugehörigkeit zu einer bestimmten Bereitstellungsphase wie Testen, Staging oder Produktion. Mit Bereichen können Sie Teilmengen von Flottenmitgliedsclustern für bestimmte Anwendungsteams erstellen. In diesem Dokument wird erläutert, wie Sie Cluster mithilfe von Bereichen organisieren und Roll-out-Sequenzen erstellen.

Nachdem Sie Ihre Cluster in Bereichen organisiert haben, wählen Sie die Reihenfolge der Bereiche aus und definieren eine Betriebszeit zwischen Bereichen. Weitere Informationen zur Verwendung von Bereichen zum Organisieren von Clustern finden Sie im Beispiel für den Einzelhandel.

Wenn eine neue Version für automatische Upgrades in der Release-Version ausgewählt wird, aktualisiert GKE Ihre Cluster in der von Ihnen definierten Sequenz. Da diese Verwaltungsstrategie darin besteht, eine neue Version in mehreren Umgebungen zu qualifizieren, sollten sich alle Cluster in einer Roll-out-Sequenz in derselben Release-Version und in derselben Nebenversion befinden, um erfolgreiche kontinuierliche Upgrades auf neue Versionen zu ermöglichen.

Die Roll-out-Sequenzierung bietet zusätzliche Kontrolle über die Verwendung von Release-Versionen, wobei GKE neue Versionen in jedem Kanal qualifiziert, bevor Versionen zum nächsten Kanal hochgestuft werden.

Beispiel: Ein Einzelhandelsunternehmen führt Änderungen aus der Testphase in die Produktion ein

In diesem Beispiel sehen Sie, wie Sie Flotten und Bereiche verwenden können, um Cluster zur Verwaltung von Clusterupgrades mit Roll-out-Sequenzierung zu gruppieren. Sie registrieren Cluster bei einer Flotte, wenn Sie sie gemeinsam verwalten möchten. Mit Bereichen können Sie Cluster innerhalb einer Flotte weiter gruppieren.

Ein Einzelhandelsunternehmen führt beispielsweise eine Vielzahl von Anwendungen über mehrere GKE-Cluster aus, darunter eine Online-Shopping-Website und eine Datenbank. Für jede dieser Anwendungen werden die Arbeitslasten auf einer Gruppe von Clustern ausgeführt. Diese Gruppe von Clustern wird in mehreren Phasen der Bereitstellung repliziert, einschließlich Tests, Staging und Produktion.

Dieses Einzelhandelsunternehmen verwendet die folgenden Bereiche, um Cluster zu gruppieren, auf denen die Online-Shopping-Website und die Online-Datenbank ausgeführt werden:

  • Bereiche für die Online-Shopping-Website:

    • Der Bereich online-shop in der Flotte testing hat mehrere Cluster, die alle im Regular Channel registriert sind.
    • Der Bereich online-shop in der Flotte staging hat mehrere Cluster, die alle im Regular Channel registriert sind.
    • Der Bereich online-shop in der Flotte production hat mehrere Cluster, die alle im Regular Channel registriert sind.

  • Bereiche für die Datenbank:

    • Der Bereich database in der Flotte testing hat mehrere Cluster, die alle im Stable Channel registriert sind.
    • Der Bereich database in der Flotte staging hat mehrere Cluster, die alle im Stable Channel registriert sind.
    • Der Bereich database in der Flotte production hat mehrere Cluster, die alle im Stable Channel registriert sind.

Das Einzelhandelsunternehmen testet neue Versionen für seine GKE-Cluster mit der folgenden Qualifizierungsstrategie. Die Bereiche online-shop und database in den Flotten testing staging und production sind jeweils in unabhängigen Roll-out-Sequenzen organisiert. Wenn neue Versionen in der Release-Version der Roll-out-Sequenz (Regular für online-shop und Stable für database) verfügbar werden und GKE mit automatischen Upgrades beginnt, wird die neue Version in dieser Reihenfolge in jedem Bereich qualifiziert.

Eine neue GKE-Nebenversion 1.28 würde beispielsweise die Produktion für eine Anwendung in der folgenden Reihenfolge durchlaufen:

  1. 1.28 ist in der Release-Version der Roll-out-Sequenz verfügbar.
  2. GKE aktualisiert Cluster im Testbereich, die unter 1.27 bis 1.28 ausgeführt werden.
  3. Sobald die Cluster im Testbereich das Upgrade 1.28 qualifiziert haben, führt GKE Upgrades für Cluster im Staging-Bereich aus, die unter 1.27 bis 1.28 ausgeführt werden.
  4. Sobald die Cluster im Staging-Bereich das Upgrade 1.28 qualifiziert haben, führt GKE Upgrades für Cluster im Produktionsbereich aus, die unter 1.27 bis 1.28 ausgeführt werden.

So wird eine Roll-out-Sequenz erstellt

Zum Verwalten von Clusterupgrades mit Roll-out-Sequenzierung müssen Sie zuerst Ihre Cluster in Bereichen organisieren. Sie können sowohl Autopilot- als auch Standardcluster angeben.

Wenn Sie Ihre Cluster in Bereichen organisieren möchten, registrieren Sie Ihre Cluster bei Flotten und binden sie an Bereiche. Nachdem Sie Ihre Cluster in Bereichen organisiert haben, können Sie eine Roll-out-Sequenz erstellen.

Wenn Sie eine Roll-out-Sequenz erstellen, definieren Sie die Reihenfolge, in der Bereiche aktualisiert werden. Sie können bis zu drei Bereiche in einer Sequenz haben. Wählen Sie zwischen dem Versions-Roll-out jedes Bereichs (maximal 30 Tage) die gewünschte Betriebszeit aus.

Eine Roll-out-Sequenz ist wie eine verknüpfte Liste definiert. Ein Bereich kann einen vorgelagerten und einen nachgelagerten Bereich haben. Damit GKE die Cluster in einem Bereich aktualisieren kann, muss der vorgelagerte Bereich die Version qualifiziert haben. Dazu muss er die Upgrades fertigstellen und den Betriebszeitraum abschließen. Sobald GKE die Clusterupgrades in einem Bereich abgeschlossen hat, können die Clusterupgrades mit dem nachgelagerten Bereich fortfahren.

Im Beispiel für den Einzelhandel hat die Roll-out-Sequenz mit den Test-, Staging- und Produktionsbereichen folgende Referenzen:

  • Der Bereich online-shop in der Flotte testing:
    • Vorgelagerter Bereich: keiner
    • Nachgelagerter Bereich: Bereich online-shop in der Flotte staging
  • Der Bereich online-shop in der Flotte staging
    • Vorgelagerter Bereich: Bereich online-shop in der Flotte testing
    • Nachgelagerter Bereich: Bereich online-shop in der Flotte production
  • Der Bereich online-shop in der Flotte production
    • Vorgelagerter Bereich: Bereich online-shop in der Flotte staging
    • Nachgelagerter Bereich: keiner (für die Beschreibung wird er jedoch als nachgelagerter Bereich aufgelistet, da er der letzte Bereich in der Sequenz ist)

Wenn Sie einen Bereich erstellen oder aktualisieren, legen Sie nur den vorgelagerten Bereich dieses Bereichs fest. Wenn Sie einen Bereich beschreiben, können Sie sowohl den vorgelagerten Bereich als auch den nachgelagerten Bereich dieses Bereichs sehen.

Der erste Bereich in der Roll-out-Sequenz hat keinen vorgelagerten Bereich, um Versionen für seine Cluster zu qualifizieren. Er erhält alle verfügbaren Upgrade-Ziele von GKE für seine Release-Version.

Informationen zum Erstellen einer Roll-out-Sequenz finden Sie unter Roll-out-Sequenz konfigurieren.

Überlegungen bei der Auswahl der 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.

Dies 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 für mehr als drei Bereitstellungsphasen automatisieren, da Sie nur eine Roll-out-Sequenz mit bis zu drei Bereichen erstellen können.
  • Sie können die Flottenverwaltung nicht verwenden.
  • Sie führen häufig manuelle Upgrades durch.
  • Sie können Ihre Cluster nicht auf neue Versionen upgraden, wenn sie aufgrund der Verwendung verworfener Kubernetes-Features oder APIs in Ihrer Release-Version aktualisiert werden.

So funktioniert die Versionsqualifizierung in einem Roll-out

Mit Clusterupgrades in einer Roll-out-Sequenz qualifizieren Cluster im vorgelagerten Bereich eine neue GKE-Version für Cluster im nachgelagerten Bereich. Insbesondere werden neue Versionen unabhängig voneinander für die Steuerungsebene und die Knoten des Clusters validiert. Bei einem Clusterupgrade aktualisiert GKE zuerst die Steuerungsebene des Clusters und beginnt dann mit Knotenupgrades. Sobald die Upgrades auf Steuerungsebene abgeschlossen sind, können sie im nächsten Bereich beginnen. Damit Upgrades von Knotenpools jedoch im nachgelagerten Bereich beginnen können, müssen Upgrades der Steuerungsebene im nachgelagerten Bereich und Knotenupgrades im vorgelagerten Bereich abgeschlossen werden.

Nachdem Sie eine Roll-out-Sequenz erstellt haben, werden Clusterupgrades allgemein mit folgenden Schritten fortgesetzt:

  1. GKE legt ein neues automatisches Upgrade-Ziel für Cluster in einer Nebenversion fest. Der Versionshinweis enthält etwa die folgende Meldung: „Steuerungsebenen und Knoten mit automatischem Upgrade im Regular Channel werden von Version 1.21 auf Version 1.22.15-gke.1000 aktualisiert.“
  2. GKE startet automatische Upgrades für die Cluster im ersten Bereich. Für jeden Cluster wird zuerst die Steuerungsebene aktualisiert. Anschließend werden Knotenupgrades gestartet, wenn das Upgrade der Steuerungsebene für den Cluster abgeschlossen ist.
  3. Der Betriebszeitraum für eine Steuerungsebene oder ein Knotenupgrade beginnt, wenn die Upgrades für die Steuerungsebene oder die Knoten im Bereich abgeschlossen sind oder der maximale Zeitraum von 30 Tagen seit Beginn der Upgrades vergangen ist. Plattformadministratoren können anhand der Betriebszeit prüfen, ob Clusterupgrades im Bereich erfolgreich waren. Wenn für den Upgradetyp keine Betriebszeit konfiguriert ist, beginnt GKE mit Upgrades im nachgelagerten Bereich.
  4. Sobald der Betriebszeitraum für das Upgrade der Steuerungsebene oder das Knotenupgrade im vorgelagerten Bereich abgeschlossen ist und die Version als qualifiziert gilt, werden für den nachgelagerten Bereich die Schritte 2 und 3 wiederholt, bis alle Cluster in allen Bereiche in der Roll-out-Sequenz auf das neue Upgrade-Ziel aktualisiert wurden.

Während der Clusteraktualisierung können Sie den Status der Roll-out-Sequenz prüfen oder bei Bedarf in den Prozess eingreifen. Sie können beispielsweise folgende Aktionen ausführen:

  • Wenn Sie feststellen, dass die Version für den nachgelagerten Bereich qualifiziert ist, überschreiben Sie die Standardbetriebszeit mit null, damit Clusterupgrades sofort mit dem nächsten Bereich fortfahren können.
  • Wenn Sie ein Problem mit Ihren Clustern feststellen, die unter der neuen Version ausgeführt werden, können Sie die Betriebszeit erhöhen, um mehr Zeit für die Überprüfung des Problems zu haben, bevor Clusterupgrades für den nachgelagerten Bereich fortgesetzt werden. Sie können einem Cluster auch einen Wartungsausschluss in dem Bereich hinzufügen, in dem Cluster derzeit aktualisiert werden, um den Abschluss des Roll-outs in dem Bereich zu verhindern. Weitere Informationen finden Sie unter Abschluss des Roll-outs der Version im Bereich verzögern.

GKE kann möglicherweise nicht mit Upgrades fortfahren, wenn es Versionsabweichungen zwischen Clustern in den Roll-out-Sequenzen gibt. Weitere Informationen finden Sie unter Roll-out-Berechtigung.

Cluster können auch aufgrund von Wartungsfenstern oder -ausschlüssen, einer verworfenen API-Nutzung oder aus anderen Gründen nicht aktualisiert werden. Weitere Informationen finden Sie unter So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures.

Roll-out-Berechtigung

GKE verwaltet Clusterupgrades mit Roll-out-Sequenzierung mit Bereichen von Clustern in derselben Release-Version und derselben Nebenversion. Dies liegt daran, dass alle Cluster in dieser Version die neuen Versionen für Clusterupgrades qualifizieren müssen, damit die Clusterupgrades in einem nachgelagerten Bereich fortgesetzt werden können.

Damit GKE die Cluster in allen Bereichen der Roll-out-Sequenz erfolgreich aktualisieren kann, muss jeder Cluster für dieselbe neue Version berechtigt sein. Der Zweck der Roll-out-Sequenzierung besteht darin, einen Bereich von Clustern zu nutzen, um die neue Version für einen anderen Clusterbereich zu qualifizieren. Wenn keiner der Cluster für dieselbe neue Version berechtigt ist, kann GKE möglicherweise nicht mit Clusterupgrades fortfahren. Wenn beispielsweise Cluster im ersten Bereich einer Roll-out-Sequenz für ein Upgrade-Ziel qualifiziert sind, die Cluster im zweiten Bereich jedoch nicht für dieses Upgrade-Ziel qualifiziert sind, da sie mit einer anderen Nebenversion beginnen, kann GKE keine Clusterupgrades durchführen, da keine qualifizierte Version vorhanden ist. Weitere Informationen erhalten Sie im nächsten Abschnitt.

Wenn alle Cluster in einem Bereich aufgrund von Versionsabweichungen zwischen Clustern nicht dasselbe Upgrade-Ziel haben, wird der Bereich als teilweise berechtigt betrachtet. Sie können den Status des Versions-Roll-outs in einer Sequenz prüfen, um weitere Informationen zum Status und zu den Auswirkungen jedes Clusters auf den Status zu erhalten. Je nach Versionsabweichungen müssen Sie möglicherweise Maßnahmen ergreifen, z. B. ein manuelles Upgrade eines Clusters ausführen oder ihn aus einem Bereich entfernen, damit die Clusterupgrades fortgesetzt werden. Informationen zur Fehlerbehebung bei teilweiser Roll-out-Berechtigung finden Sie unter Fehlerbehebung bei Roll-out-Berechtigung.

Beispiel für Versionsabweichungen und Upgradeziele

Das folgende Beispiel zeigt, warum Cluster in Bereichen in einer Roll-out-Sequenz dieselbe Version ausführen sollten.

Im Release 2022-R25 hat jede verfügbare Nebenversion in einer Release-Version ein Upgradeziel. Ein Upgradeziel kann eine neue Nebenversion oder einfach eine neue Patchversion sein. In der referenzierten Version wurden beispielsweise die folgenden neuen Versionen für Cluster mit bestimmten Nebenversionen verfügbar:

  • Cluster unter 1.20 und 1.21 wurden auf 1.21.14-gke.4300 aktualisiert.
  • Cluster unter 1.22 wurden auf 1.23.8-gke.1900 aktualisiert.
  • Cluster unter 1.24 wurden auf 1.24.5-gke.600 aktualisiert.

Der erste Bereich in einer Roll-out-Sequenz empfängt diesen Batch von Upgradezielen und kann Clusterupgrades starten. Für den ersten Bereich in einer Roll-out-Sequenz werden alle Upgradeziele als qualifiziert betrachtet, sodass automatische Upgrades unabhängig von den Versionsabweichungen im ersten Bereich fortgesetzt werden. Damit in diesem Bereich Upgradeziele jedoch für den nachgelagerten Bereich geeignet sind, muss jeder Cluster in diesem Bereich dasselbe Upgradeziel haben. Dies bedeutet in der Regel, dass die Cluster derzeit dieselbe Nebenversion haben. In diesem Beispiel hatten Cluster in 1.20 und 1.21 jedoch dasselbe Upgrade-Ziel.

Sobald GKE die Cluster im ersten Bereich aktualisiert hat, haben diese Cluster ein Upgrade-Ziel validiert. Wenn sich alle Cluster im ersten Bereich unter 1.20 oder 1.21 befanden, wurde 1.21.14-gke.4300 validiert. Wenn sich alle Cluster unter 1.22 befinden, wurde 1.23.8-gke.1900 validiert. Diese validierte Version wird jetzt an den nachgelagerten Bereich übergeben. Wenn es jedoch eine Versionsabweichung zwischen Clustern im ersten oder zweiten Bereich gibt, d. h., das Upgrade-Ziel unterschiedlich ist, stimmt die validierte Version möglicherweise nicht mit einer Version für die Cluster im nachgelagerten Bereich überein.

So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures

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 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 einem Bereich nicht abgeschlossen werden. Wenn ein Clusterupgrade aufgrund von Wartungsfenstern oder -ausschlüssen nicht innerhalb von 30 Tagen abgeschlossen werden kann, geht der Bereich 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 einen Bereich durchführt und mit dem nächsten Bereich fortfährt. Weitere Informationen finden Sie unter Abschluss des Roll-outs der Version im Bereich verzögern.

So funktioniert die 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 einem Bereich 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 Knotenpools

Für Knotenpool-Upgrades wird die konfigurierte Upgrade-Strategie für Knotenpools verwendet, wenn ein Upgrade in einer Roll-out-Sequenz erfolgt. Wie bei Clusterupgrades ohne Roll-out-Sequenzierung verwendet GKE Surge-Upgrades für Autopilot-Knoten. Weitere Informationen finden Sie unter Automatische Knotenupgrades.

Wenn ein Knotenupgrade nicht innerhalb von 30 Tagen abgeschlossen werden kann, geht der Bereich in die Betriebsphase über, unabhängig davon, ob alle Cluster aktualisiert wurden. Dies kann passieren, wenn die Upgradestrategie für Knotenpools dazu führt, dass das Upgrade eines Knotenpools 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 Knotenpools abzuschließen. Weitere Informationen finden Sie unter Überlegungen beim Konfigurieren eines Wartungsfensters.

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 Bereichen einer Roll-out-Sequenz müssen sich in derselben Release-Version befinden.

Patchversionen überspringen

Cluster in einer Release-Version erhalten in der Regel alle ein bis zwei Wochen eine neue Patchversion, während Nebenversionen etwa alle vier Monate erhalten werden. Das bedeutet, dass Sie mit einer Sequenz aus den maximal drei Bereichen eine neue Nebenversion bis zu vier Monate lang qualifizieren können, bevor sie den Produktionsbereich erreicht: erstes Roll-out (maximal 30 Tage) + Betriebszeit des ersten Bereichs (maximal 30 Tage) + Roll-out des zweiten Bereichs (maximal 30 Tage) + Betriebszeit des zweiten Bereichs (maximal 30 Tage) = 120 Tage (~4 Monate). Dies ist das graduellste Roll-out. Der letzte Bereich muss ein Roll-out der Nebenversion innerhalb von vier Monaten ausführen, um zu verhindern, dass er hinter dem GKE-Releasezeitplan zurückliegt.

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 ein vorgelagerter Bereich mit dem Roll-out einer neuen Version beginnen, während ein nachgelagerter Bereich noch das vorherige Upgrade erhält. Wenn beispielsweise der dritte Bereich in einer Sequenz 1.24.2-gke.100 einführt, kann der erste Bereich in der Sequenz gleichzeitig 1.24.3-gke.500 einführen.

Laufendes Roll-out einer Version steuern

Wenn Sie eine Sequenz konfiguriert haben und eine neue Version für die Cluster in der Roll-out-Sequenz verfügbar ist, werden Upgrades automatisch gestartet.

Sie haben auch die Möglichkeit, den Status eines Versions-Roll-outs für eine gesamte Roll-out-Sequenz mit einem Befehl zu prüfen. Darüber hinaus haben Sie dieselben Kontrollen für den Upgradeprozess wie bei Clustern, die sich nicht in einer Roll-out-Sequenz befinden. Einige der relevanten Maßnahmen, die Sie ergreifen können, um den Roll-out-Prozess der Version zu beeinflussen, sind unter anderem:

  • Abschluss des Roll-outs der Version im Bereich verzögern
  • Betriebszeit für das Roll-out einer bestimmten Version überschreiben
  • Reihenfolge einer Sequenz ändern
  • Sequenz löschen

Weitere Informationen finden Sie unter Roll-out von Versionen steuern.

Status des Roll-outs einer Version in einer Sequenz prüfen

Sie können den Status des Versions-Roll-outs in einer Sequenz mit gcloud alpha container fleet scopes describe [SCOPE] --show-cluster-upgrade prüfen. Weitere Informationen finden Sie unter Status einer Roll-out-Sequenz prüfen.

Der Status eines Versions-Roll-outs umfasst den Status der einzelnen Bereiche und Cluster innerhalb dieses Bereichs. Wenn Sie den Befehl ausführen, können Sie das Flag --show-linked-cluster-upgrade verwenden, um den Status aller Bereiche innerhalb der Sequenz aufzurufen.

In der folgenden Tabelle sind die möglichen Status eines Clusters oder Bereichs aufgeführt:

Status Für Cluster Für Bereich
INELIGIBLE Dieser Cluster ist für dieses Upgrade nicht berechtigt. Einer oder mehrere Cluster in diesem Bereich sind für das Upgrade nicht berechtigt.
PENDING Das Upgrade wurde nicht gestartet oder das Upgrade wird für den Cluster ausgeführt. Das Upgrade wurde in keinem der Cluster im Bereich gestartet.
IN_PROGRESS – Das Upgrade hat bei mindestens einem Cluster begonnen, ist aber noch nicht für alle Cluster abgeschlossen.
SOAKING Das Upgrade ist auf dem Cluster abgeschlossen, befindet sich aber noch in der Betriebszeit. Das Upgrade ist auf allen Clustern abgeschlossen, befindet sich aber noch in der Betriebszeit.
FORCED_SOAKING Das Upgrade dauerte länger als die maximale Upgrade-Zeit (30 Tage) und wurde daher in die Betriebsphase übertragen. Das Upgrade kann auf dem Cluster andauern. Das Upgrade dauerte länger als die maximale Upgrade-Zeit (30 Tage) und wurde daher in die Betriebsphase übertragen. Das Upgrade kann auf den Clustern andauern.
COMPLETE Das Upgrade wird als "Fertig" betrachtet, was bedeutet, dass das Upgrade in diesem Cluster abgeschlossen ist. Das Upgrade wird als "Fertig" und bereit für den nachgelagerten Bereich betrachtet. Dies bedeutet, dass das Upgrade abgeschlossen ist.

Beispiel:

$gcloud alpha container fleet scopes describe scope-A --show-linked-cluster-upgrade

clusterUpgrades:
- scope: projects/${some_project_number}/locations/global/workspaces/scope-C
  spec: {}
  state:
    downstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-A
- scope: projects/${current_project_id}/locations/global/workspaces/scope-A
  spec:
    upstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-C
  state:
    downstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-B
- scope: projects/${current_project_id}/locations/global/workspaces/scope-B
  spec:
    upstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-A
  state: {}
createTime: '2022-09-07T19:53:49.442321517Z'
name: projects/${some_project_number}/locations/global/workspaces/scope-A
state:
  code: READY
uid: ${some-uuid}
updateTime: '2022-09-07T19:53:50.357882703Z'

Beschränkungen

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

  • Registrieren Sie einen Cluster nur in einem einzigen Bereich. Wenn ein Cluster in mehreren Bereichen registriert ist, kann GKE den Cluster nicht automatisch aktualisieren.
  • Erstellen Sie eine lineare Roll-out-Sequenz ohne Zyklen (ein Bereich hat einen nachgelagerten Bereich als vorgelagerten Bereich) oder Zweige (ein Bereich hat mehr als einen nachgelagerten Bereich).

Bekannte Probleme

  • Wenn ein Bereich 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 den ersten Cluster in einem Bereich wahrscheinlicher und sollte innerhalb einer Woche gelöst werden.
  • Wenn eine Roll-out-Sequenz einen leeren Bereich enthält, hängt es von folgenden Bedingungen ab, wie sich dies auf die Versionsqualifizierung auswirkt:
    • Wenn der leere Bereich keinen vorgelagerten Bereich hat, können Clusterupgrades nicht mit dem nachgelagerten Bereich fortfahren, da der leere Bereich keine Versionen qualifizieren kann.
    • Wenn der leere Bereich einen vorgelagerten Bereich hat, wechseln alle ausstehenden Clusterupgrades in den Status COMPLETE und werden an den nachgelagerten Bereich weitergegeben.
  • Je nachdem, wie GKE Patch- und Nebenversionsupgrades verfolgt, sehen Sie möglicherweise zwei Upgrades desselben Typs und derselben Version, aber mit unterschiedlichen Status, wenn Sie den Status des Bereichs prüfen.
  • Der Befehl gcloud alpha container fleet scopes describe <SCOPE_NAME> --show-linked-cluster-upgrade zeigt keine Status der Bereichsmitgliedschaft an. Führen Sie gcloud container fleet features describe clusterupgrade aus, um die Mitgliedschaft anzuzeigen.

So ändert sich die Roll-out-Sequenzierung nach der privaten Vorschau

Mit der Flottenverwaltung können Sie Ihre Cluster entweder in Gruppen mit Flotten oder mit Flotten und Bereichen organisieren. Bereiche bieten eine zusätzliche Granularität für Organisationen, die große Mengen an Clustern für verschiedene Teams betreiben, und können von einer anderen Gruppierungsebene innerhalb von Flotten profitieren. Eine Produktionsflotte enthält beispielsweise Gruppen von Produktionsarbeitslasten, die von verschiedenen Geschäftseinheiten in der Organisation verwaltet werden.

Für die private Vorschau des Features der Roll-out-Sequenzierung können Sie nur eine Roll-out-Sequenz zwischen Bereichen erstellen. Für die allgemeine Verfügbarkeit von Roll-out-Sequenzierung können Sie zwischen dem Erstellen von Roll-out-Sequenzen zwischen Flotten oder Bereichen wählen.

Für die allgemeine Verfügbarkeit werden Bereiche nur als Premium-Funktion angeboten. Der Zugriff auf Flotten und das Erstellen von Roll-out-Sequenzen von Flotten stehen jedoch als Standardfeature allen Kunden zur Verfügung. Wie bei anderen privaten Vorschauen fallen auch hier keine zusätzlichen Kosten für den Zugriff auf die Premium-Funktion zur Verwendung der Roll-out-Sequenzierung mit Bereichen an.

Nächste Schritte