Roll-out-Sequenzierung mit benutzerdefinierten Phasen

Autopilot Standard

Rollout sequencing with custom stages

• Rollout-Sequenzierung mit benutzerdefinierten Phasen (Vorschau)
• Rollout-Sequenzierung (GA)

Vorschau

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

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 allgemein verfügbare Version der Roll-out-Sequenzierung, die ein lineareres Modell ohne benutzerdefinierte Phasen verwendet.

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

• Cluster-Upgrades
• Flottenverwaltung – Übersicht
• Release-Versionen
• Versionsverwaltungsschema in GKE
• Soak-Tests

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 allgemein verfügbare und 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.

• Roll-out-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 Roll-out-Strategien, z. B. wenn Sie eine neue Version auf einer kleinen Teilmenge von Produktionsclustern bereitstellen, bevor Sie sie in größerem Umfang einführen. Wählen Sie diese Option aus, wenn Sie mehr Flexibilität benötigen oder die neuesten Funktionen für die Roll-out-Sequenzierung testen möchten.

Der Rest dieses Dokuments bezieht sich nur auf die Bereitstellungsreihenfolge mit benutzerdefinierten Phasen.

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:

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.

Wichtige Konzepte

• Soak-Zeit: Dieser Zeitraum ist ein konfigurierbarer Wartezeitraum, der nach dem Upgrade aller Cluster in einer Phase eintritt. So können Sie die neue Version in einer Umgebung validieren und potenzielle Probleme erkennen, bevor das Upgrade in der nächsten Umgebung fortgesetzt wird. Sie können für jede Phase in Ihrer Sequenz eine Wartezeit von bis zu 30 Tagen konfigurieren. Eine längere Testphase in einer Vorproduktionsphase gibt Ihnen mehr Zeit für die Validierung.
• RolloutSequence: Dies ist die primäre Ressource, mit der Sie die Upgrade-Reihenfolge definieren. RolloutSequence enthält eine geordnete Reihe von Phasen, in denen geprüft wird, ob Cluster in früheren Phasen vollständig aktualisiert wurden und ihre Betriebszeit abgeschlossen ist, bevor das Upgrade mit der nächsten Phase fortgesetzt wird.
• Rollout: Mit diesem Objekt können Sie den Fortschritt eines einzelnen Versionsupgrades in Ihrer Sequenz beobachten. Mit Rollout können Sie den Status des Rollouts aufrufen, den Fortschritt verfolgen und sehen, ob und warum bestimmte Cluster nicht für ein Upgrade infrage kommen.
• Dediziertes Hostprojekt: Wir empfehlen, ein dediziertes Google Cloud-Projekt zum Hosten Ihrer RolloutSequence-Objekte zu verwenden. Wenn Sie die Sequenz in einem dedizierten Projekt platzieren, erhalten Sie einen neutralen, zentralen Kontrollpunkt für Ihre Rollout-Sequenzen. Dies ist eine ähnliche Best Practice wie für die Verwaltung von CI/CD-Pipelines.

Best Practice:

Erstellen und verwalten Sie Ihre RolloutSequence-Ressourcen in einem dedizierten Hostprojekt.

• Phasen: Eine Phase ist ein Schritt in der Roll-out-Sequenz. Jede Phase enthält eine Gruppe von Clustern, die zusammen aktualisiert werden.
• Flotten: Flotten sind die primäre Methode zum Gruppieren von Clustern. Eine Phase in einer Rollout-Sequenz kann nur auf eine Flotte verweisen.
• Label-Selektoren: Eine Einführungsserie besteht aus einer oder mehreren Phasen. Jede Phase enthält Cluster aus einer Flotte. Mit Labelselektoren für Cluster können Sie eine Flotte in mehrere Phasen aufteilen. Dieser Ansatz ermöglicht Strategien wie stufenweise Roll-outs, bei denen zuerst ein kleiner Teil der Produktionscluster aktualisiert wird.

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:

1. 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.“

2. 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.

3. 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.

4. 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.

5. 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 .

Warnung :GKE kann möglicherweise nicht mit automatischen Upgrades in einer Roll-out-Sequenz fortfahren, wenn Versionsabweichungen zwischen den Clustern der Gruppen in der Sequenz auftreten. Weitere Informationen finden Sie unter Roll-out-Berechtigung.

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:

• Sie können die Standardbetriebszeit für eine Gruppe in einer Roll-out-Sequenz ändern. Das ist nützlich, wenn Tests ergeben, dass eine bestimmte Version mehr oder weniger Betriebszeit benötigt. Durch diese Änderung der Testzeit wird die Standardtestzeit für alle aktuellen und zukünftigen Rollouts (für jede Version) aktualisiert, die nach der Änderung erstellt werden.

• 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.

Achtung :Wenn Sie eine Sequenz während eines Roll-outs ändern, insbesondere Änderungen, die sich auf die beteiligten Cluster auswirken, werden alle vorhandenen Roll-outs von GKE sofort abgebrochen. Wenn Sie nur die Soak-Zeit einer Sequenz ändern, wird der Roll-out von GKE nicht abgebrochen.

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

Der Plattformadministrator einer Community-Bank verwaltet drei Hauptbereitstellungsumgebungen: Tests, Staging und Produktion. Die Produktionscluster sind auf mehrere Regionen verteilt und haben unterschiedliche Kritikalitätsstufen. Um Upgrades effektiv zu verwalten, gruppiert der Administrator die Cluster in jeder Umgebung in Flotten. Wie es bei der Roll-out-Sequenzierung erforderlich ist, ist jeder Cluster bei allen drei Flotten in derselben Release-Version (in diesem Fall der Regular Channel) registriert und in allen Clustern wird dieselbe Nebenversion ausgeführt.

Das primäre Ziel des Administrators ist es, dafür zu sorgen, dass neue GKE-Versionen gründlich geprüft werden, bevor sie die kritische Produktionsumgebung der Bank erreichen. Außerdem möchten sie Cluster in einer Region mit geringerem Traffic nach und nach aktualisieren, dann zu einer Region mit höherem Traffic und schließlich zu ihrer wichtigsten Region wechseln. Dazu verwenden sie die Roll-out-Sequenzierung mit benutzerdefinierten Phasen, um eine progressive Upgradestrategie zu definieren, die das Labeln der Produktionscluster nach Region umfasst. So können sie eine neue Version mit einem kleinen Teil des Produktionstraffics testen, bevor sie vollständig eingeführt wird.

Um diesen Plan umzusetzen, wendet der Administrator die folgenden Labels auf die Cluster in der Produktionsflotte an:

• Cluster in us-west1 (weniger Traffic) sind mit prod-region: us-west1 gekennzeichnet.
• Cluster in europe-west1 (höherer Traffic) sind mit prod-region: europe-west1 gekennzeichnet.
• Cluster in us-east1 (wichtigster Traffic) sind nicht gekennzeichnet. Die letzte Phase für eine Flotte in einer Sequenz muss als „Auffangbecken“ für alle verbleibenden Cluster fungieren. Daher muss der Administrator diesen verbleibenden Clustern keine Labels hinzufügen.

Als Nächstes definieren sie in einem dedizierten Hostprojekt, das zum Verwalten von CI/CD-Konfigurationen verwendet wird, ein RolloutSequence-Objekt. Diese neue Sequenz hat fünf verschiedene Phasen:

1. Testen: Diese Phase umfasst alle Cluster in der testing-Flotte. Der Administrator legt eine Betriebszeit von drei Tagen fest, um eine gründliche Validierung zu ermöglichen.
2. Staging: Diese Phase umfasst alle Cluster in der staging-Flotte mit einer dreitägigen Soak-Zeit.
3. Produktion in Region us-west1: Diese Phase zielt auf die Produktionsflotte ab, verwendet aber einen label-selector, um nur die Cluster mit dem Label prod-region: us-west1 einzubeziehen. In dieser Phase kann der Administrator drei Tage lang Probleme in einer kleinen Teilmenge von Produktionsclustern beobachten.
4. Produktion in Region europe-west1: Diese Phase umfasst die Cluster in der Flotte production, die das Label prod-region: europe-west1 haben. Der Administrator legt eine längere Betriebszeit von vier Tagen für eine gründlichere Validierung fest.
5. Produktion in der Region us-east1: Diese letzte Phase umfasst die verbleibenden Cluster in der production-Flotte, d. h. alle Cluster in us-east1.

Dieser Ansatz gibt dem Administrator eine detaillierte Kontrolle über seine Produktionsupgrades und verbessert die Sicherheit und Zuverlässigkeit des Upgrade-Prozesses erheblich, da potenzielle Probleme erkannt werden, bevor sie sich auf die gesamte Produktionsumgebung auswirken können.

Bei einem routinemäßigen Patch-Upgrade werden die automatisierten Tests der Bank in der Staging-Umgebung viel schneller als erwartet abgeschlossen. Der Administrator stellt fest, dass die neue Version stabil ist, und entscheidet, dass die dreitägige Betriebszeit nach dem Upgrade der Staging-Flotte für diese Art von Routineupdate unnötig lang ist.

Um die Einführung zu beschleunigen, ändert der Administrator die RolloutSequence-Definition und verkürzt die Testdauer für die us-west1-Phase der Produktionsflotte. Da durch diese Änderung der RolloutSequence-Definition die standardmäßige Testzeit für alle aktuellen und zukünftigen Roll-outs aktualisiert wird, notiert sich der Administrator, die Testzeit nach Abschluss dieses speziellen Patch-Roll-outs wieder auf den ursprünglichen Zeitraum von drei Tagen zurückzusetzen. So wird sichergestellt, dass die standardmäßige, vorsichtigere Testphase für zukünftige Upgrades auf Nebenversionen eingehalten wird.

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.

Roll-out-Berechtigung

Damit eine Version über eine Sequenz mit benutzerdefinierten Phasen eingeführt werden kann, müssen Cluster für ein Upgrade-Ziel aus ihrem Release-Channel infrage kommen. Wenn eine neue GKE-Version verfügbar wird, erstellt das System ein Rollout-Objekt, wenn Cluster in der Sequenz für die neue Version infrage kommen. Wir empfehlen zwar, dass alle Cluster in derselben Release-Version registriert sind. Wenn dies jedoch nicht der Fall ist, wählt GKE eine Version aus der konservativsten Release-Version in der Sequenz aus. Wenn Cluster beispielsweise sowohl den Stable- als auch den Regular-Channel verwenden, wählt GKE die Version aus dem Stable Channel aus.

Die Rollout durchläuft dann die in Ihrer RolloutSequence definierten Phasen. Innerhalb einer bestimmten Phase können die Einführung der Steuerungsebene und die Einführung des Knotenpools parallel erfolgen. Eine wichtige Regel für diesen Ablauf ist, dass eine Phase, die sich mit einer bestimmten Version im Status SOAKING befindet, nicht für den Beginn eines neuen Rollout für eine neuere Version infrage kommt. So wird sichergestellt, dass eine Version vollständig validiert wird, bevor das nächste Upgrade beginnt. Sie können den Fortschritt und die Eignung jedes Clusters beobachten, indem Sie das Rollout-Objekt überwachen. Wenn Sie Versionsabweichungen feststellen, die einen Cluster unzulässig machen, müssen Sie möglicherweise Maßnahmen ergreifen, z. B. den Cluster manuell aktualisieren, damit die Sequenz fortgesetzt werden kann. Wenn ein Cluster nicht für Roll-outs infrage kommt, führt GKE erst dann ein automatisches Upgrade des Clusters durch, wenn die aktuelle Version das Ende des Supports erreicht hat.

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

Wenn eine Phase in der Sequenz Cluster enthält, auf denen eine neuere Version als die Zielversion eines Roll-outs ausgeführt wird, führt GKE ein Upgrade der Cluster durch, die für die Zielversion infrage kommen, und ignoriert die Cluster, auf denen bereits eine neuere Version ausgeführt wird. Dieses Verhalten verhindert nicht, dass die Roll-out-Sequenz in die nächste Phase übergeht.

Wenn beispielsweise die Zielversion eines Roll-outs für eine Phase 1.32 ist und in dieser Phase Cluster mit Version 1.31 und 1.33 ausgeführt werden, aktualisiert GKE die Cluster mit Version 1.31 auf 1.32 und ignoriert die Cluster, die bereits Version 1.33 verwenden.

In der vorherigen Phase wurden mehrere Upgradeziele für die nachfolgende Phase qualifiziert.

In einer vorherigen Phase einer Sequenz werden möglicherweise Rollouts für mehrere neue Versionen abgeschlossen, während eine nachfolgende Phase pausiert ist (z. B. aufgrund eines Wartungsausschlusses) oder noch ein vorheriges Upgrade verarbeitet wird. Wenn die nächste Stufe bereit ist, ein neues Upgrade zu akzeptieren, führt GKE ein Upgrade auf die neueste qualifizierte Version durch. Bei Upgrades der Steuerungsebene darf diese Version höchstens eine Nebenversion später als die Version der Steuerungsebene der Cluster in der nachfolgenden Phase sein. Bei Knotenupgrades kann diese Version gleich der Version der Steuerungsebene der Cluster in der nachfolgenden Phase sein, aber nicht später.

Dieses Szenario ist beispielsweise relevant, wenn Sie Wartungsausschlüsse konfiguriert haben, um Upgrades in Ihren Produktionsclustern vorübergehend zu verhindern. Wenn Ihre Pre-Production-Cluster nicht dieselben Wartungsausschlüsse hatten, werden diese Cluster möglicherweise mehrmals aktualisiert, wodurch mehrere neue Versionen infrage kommen. Ihre Produktionsphasen werden jedoch nicht aktualisiert.

Erzwungener Betrieb nach 30 Tagen

Damit eine Roll-out-Sequenz Cluster-Upgrades abschließt, beginnt GKE den Betriebszeitraum für eine Gruppe, wenn die Upgrades der Steuerungsebene bzw. 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.

So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures

Die Roll-out-Sequenzierung funktioniert mit anderen GKE-Upgradefunktionen:

• Wartungsfenster und -ausschlüsse: Sie können weiterhin Wartungsfenster und -ausschlüsse verwenden, um zu steuern, wann Upgrades für Ihre Cluster ausgeführt werden können. 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 Phase nicht abgeschlossen werden. Wenn ein Clusterupgrade aufgrund von Wartungsfenstern oder -ausschlüssen nicht innerhalb von 30 Tagen abgeschlossen werden kann, geht die Phase in die Betriebsphase über, unabhängig davon, ob alle Cluster aktualisiert wurden. Rollouts der Steuerungsebene und des Knotenpools können in einer bestimmten Phase parallel ausgeführt werden.

• Strategien für Knotenupgrades: Die Roll-out-Sequenzierung hat keine Auswirkungen auf die konfigurierten Strategien für Knotenupgrades (z. B. Blau/Grün-Upgrades). Ähnlich 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.

• Release-Kanäle: Wir empfehlen, alle Cluster in einer Roll-out-Sequenz im selben Release-Kanal zu registrieren.

• Erkennung der Verwendung verworfener Einstellungen: Die Erkennung der Verwendung verworfener Einstellungen in GKE funktioniert weiterhin wie erwartet. Upgrades für Cluster, die eine verworfene API verwenden, werden möglicherweise pausiert.

• Manuelle Upgrades: Wenn Sie Cluster in der ersten Phase einer Sequenz manuell upgraden, wird die Version dadurch nicht automatisch qualifiziert und es wird auch kein Roll-out ausgelöst. Der automatisierte Roll-out-Prozess wird durch die offiziellen Ziele für automatische Upgrades gesteuert, die für die Release-Version festgelegt sind. Bei einem manuellen Upgrade werden die Cluster aktualisiert. Die Sequenz wird für diese Version jedoch erst dann fortgesetzt, wenn sie das festgelegte Ziel für automatische Upgrades ist.

Mehrere Upgrades innerhalb einer Sequenz erhalten

Mit einer Release-Version wird ein Upgradeziel für den Cluster ausgewählt. Wenn eine neue Version verfügbar wird, während Upgrades auf ein vorheriges Ziel noch laufen, kann die erste Phase mit dem Roll-out einer neuen Version beginnen, auch wenn die späteren Phasen noch das vorherige Upgrade erhalten. Wenn beispielsweise die dritte Gruppe in einer Sequenz Version 1.31.12-gke.1265000 einführt, kann die erste Gruppe in der Sequenz gleichzeitig Version 1.31.13-gke.1008000 einführen.

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

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 führen häufig manuelle Upgrades durch, die dazu führen, dass Cluster in einer Gruppe unterschiedliche automatische Upgrade-Zielversionen haben.

Beschränkungen

Beim Aktualisieren von Clustern mit Rollout-Sequenzierung mit benutzerdefinierten Phasen gelten die folgenden Einschränkungen:

• Sie können die Google Cloud Console nicht verwenden, um Rollout-Sequenzen mit benutzerdefinierten Phasen zu erstellen oder anzusehen.
• Wenn in einer Roll-out-Sequenz auf eine Flotte verwiesen wird, müssen Sie die gesamte Flotte einbeziehen. Wenn Sie eine Phase definieren, die nur auf eine Teilmenge von Clustern aus einer Flotte mit label-selector ausgerichtet ist (z. B. für eine stufenweise Bereitstellung), müssen Sie auch eine nachfolgende „Catch-all“-Phase definieren, die alle verbleibenden Cluster aus derselben Flotte umfasst. Diese Auffangphase richtet sich an dieselbe Flotte, enthält aber kein label-selector. Dadurch werden automatisch alle Cluster einbezogen, die nicht von früheren Phasen in der Sequenz ausgewählt wurden.
• Wenn Sie eine Sequenz während der Einführung ändern, insbesondere Änderungen, die sich auf die beteiligten Cluster auswirken, werden alle vorhandenen Einführungen in GKE sofort abgebrochen. Wenn Sie nur die Soak-Zeit einer Sequenz ändern, wird der Roll-out von GKE nicht abgebrochen.
• Sie können einen aktiven Roll-out für eine bestimmte Version nicht manuell beschleunigen. Wenn Sie die Testdauer in der Definition der Roll-out-Sequenz ändern, wird die Standardtestdauer für alle aktuellen und zukünftigen Roll-outs aktualisiert, die nach der Änderung erstellt werden.
• Die GKE führt automatisch Upgrades von Clustern, die das Ende des Supports erreicht haben, auf eine unterstützte Version durch. Dieses Upgrade folgt möglicherweise nicht der definierten Einführungsreihenfolge.
• Eine Phase kann maximal auf eine Flotte verweisen. In einer Phase können nicht mehrere Flotten vorhanden sein.
• Auf eine einzelne Flotte kann nur in einer Rollout-Sequenz verwiesen werden. Zwei Rollout-Sequenzen dürfen nicht auf dieselbe Flotte verweisen.

Bekannte Probleme

In diesem Abschnitt werden die bekannten Probleme bei der sequenziellen Einführung mit benutzerdefinierten Phasen beschrieben.

• Wenn eine Phase in Ihrer Roll-out-Sequenz keine Cluster enthält, wird die Phase übersprungen. Die für diese Phase definierte Betriebszeit wird jedoch trotzdem abgewartet, bevor der Roll-out mit der nächsten Phase fortgesetzt wird.

Nächste Schritte

• Roll-out von Clusterupgrades mit benutzerdefinierten Phasen sequenzieren