Roll-out-Sequenzierung mit benutzerdefinierten Phasen

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 frühere Version dieser Funktion, die Sequenzierung des Flotten-Rollouts, die einen eingeschränkteren Funktionsumfang hat und nicht für neue Umgebungen empfohlen wird.

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 mit benutzerdefinierten Phasen 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 Bake-Zeit, sodass Sie potenzielle Probleme erkennen und beheben können, bevor das Upgrade Ihre kritischsten Systeme erreicht.

Die Roll-out-Sequenzierung basiert auf dem Konzept von Flotten, bei denen es sich um logische Gruppierungen von GKE-Clustern handelt, die einer Umgebung (z. B. Test) zugeordnet sind. Wenn Sie diese Funktion verwenden möchten, definieren Sie eine Sequenz aus Flotten und legen die Übergangszeit 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 für die Bereitstellungssequenzierung logisch gruppieren können, ohne alle Konfigurationen und Funktionen auf Flottenebene zu aktivieren. Die einfache Mitgliedschaft ist eine gute Wahl, wenn Sie Roll-out-Sequenzen verwenden möchten, ohne dass die anderen Auswirkungen der vollständigen Flottenverwaltung wie die Namespace-Gleichheit auf Flottenebene gelten. Weitere Informationen finden Sie unter Lightweight-Mitgliedschaften.

Strategie für die Roll‑out-Reihenfolge auswählen

GKE bietet zwei Versionen der Roll-out-Sequenzierung. Beide Versionen basieren auf denselben Grundprinzipien für progressive, flottenbasierte Upgrades. Wir empfehlen jedoch, für neue Umgebungen die Roll-out-Sequenzierung mit benutzerdefinierten Phasen zu verwenden:

  • Roll-out-Sequenzierung mit benutzerdefinierten Phasen (empfohlen für neue Umgebungen): Diese Version ist eine Weiterentwicklung des flottenbasierten Modells und bietet mehr detaillierte Kontrolle und Flexibilität, aber keine Google Cloud -Konsolenunterstützung. Mit benutzerdefinierten Phasen können Sie bestimmte Phasen innerhalb einer Flotte mithilfe von Labels definieren. Das ist eine gute Wahl für komplexere Roll-out-Strategien, z. B. wenn Sie eine neue Version auf einer kleinen Teilmenge von Produktionsclustern bereitstellen möchten, bevor Sie sie auf alle Cluster ausweiten. Außerdem haben Sie mehr Kontrolle über Roll-outs. Sie können beispielsweise einen Roll-out für eine bestimmte Version starten, die Arten von Upgrades auswählen, die in einer Sequenz bereitgestellt werden sollen, und Roll-outs pausieren oder abbrechen. Wählen Sie diese Option aus, wenn Sie zum ersten Mal eine Roll-out-Sequenz erstellen.
  • Sequenzierung für die Einführung auf Flottenbasis:Diese Version der Funktion kann nur mit der Google Cloud -Konsole verwendet werden. Sie bietet ansonsten aber weniger Funktionen und wird nicht empfohlen, wenn Sie zum ersten Mal eine Einführungssequenz erstellen.

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 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 Roll-outs.
  • 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 Stufenziele sind Cluster mit einem label-selector namens canary in der Flotte prod:

Roll-out-Sequenz mit benutzerdefinierten Phasen in GKE
Abbildung: Roll-out-Sequenz mit benutzerdefinierten Phasen

Wenn GKE eine neue Version einführt, werden zuerst die Cluster in der Testflotte und dann die Cluster in der Staging-Flotte aktualisiert. 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 Übergangszeit 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

  • Übergangszeit: Ein konfigurierbarer Wartezeitraum, der nach dem Upgrade aller Cluster in einer Phase eintritt. Diese Übergangszeit ermöglicht es Ihnen, die neue Version in einer Umgebung zu validieren und potenzielle Probleme zu erkennen, bevor das Upgrade in der nächsten Umgebung fortgesetzt wird. Sie können für jede Phase in Ihrer Sequenz eine Übergangszeit von bis zu 30 Tagen konfigurieren. Eine längere Übergangszeit in der Vorproduktionsphase gibt Ihnen mehr Zeit für die Validierung.
  • RolloutSequence: Dieses Objekt ist die primäre Ressource, mit der Sie die Upgradesequenz 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 die Soak-Periode abgeschlossen ist, bevor das Upgrade in die nächste Phase übergeht. Jedes RolloutSequence hat ein Rollout für jede neue Version, die eingeführt 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 Roll-outs aufrufen, den Fortschritt verfolgen und sehen, ob und warum bestimmte Cluster nicht für ein Upgrade infrage kommen. Jede Rollout ist mit einer bestimmten RolloutSequence verknüpft, die die Reihenfolge angibt, in der die Version eingeführt wird.
  • Dediziertes Hostprojekt: Wir empfehlen, ein dediziertesGoogle Cloud -Projekt zum Hosten Ihres RolloutSequence-Objekts zu verwenden. Wenn Sie die Sequenz in einem dedizierten Projekt platzieren, erhalten Sie einen neutralen, zentralen Kontrollpunkt für Ihre Rollout-Sequenz. Dies ist eine ähnliche Best Practice wie für die Verwaltung von CI/CD-Pipelines.
Best Practice:

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

  • Phasen: Eine Phase ist ein Schritt in der Roll-out-Sequenz. Jede Phase enthält eine Gruppe von Clustern, die gemeinsam aktualisiert werden.
  • Flotten: Flotten sind die primäre Methode zum Gruppieren von Clustern. Eine Phase in einer Rollout-Sequenz kann auf eine oder mehrere Flotten verweisen. Eine einzelne Roll-out-Sequenz kann Flotten umfassen, die in mehreren Google Cloud Organisationen gehostet werden.
  • Label-Selektoren: Eine Rollout-Sequenz besteht aus einer oder mehreren Phasen. Jede Phase enthält Cluster aus einer oder mehreren Flotten. Sie können Label-Selektoren für Cluster verwenden, um eine Flotte in mehrere Phasen aufzuteilen. Dieser Ansatz ermöglicht Strategien wie stufenweise Roll-outs, bei denen zuerst eine kleine Teilmenge von Produktionsclustern 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 Übergangszeit 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 startet einen neuen Roll-out in der Roll-out-Sequenz. Ein Roll-out wird standardmäßig gestartet, wenn GKE ein neues Ziel für automatische Upgrades für Cluster mit einer Nebenversion in einer bestimmten Release-Version festlegt. Bei der sequenziellen Einführung mit benutzerdefinierten Phasen können Sie alternativ ein neues Roll-out für eine bestimmte Version auslösen, die Sie auswählen.

  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 die von der ersten Gruppe qualifizierte Version 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 den Betriebszeitraum auch, 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 aktualisiert die Knoten von Clustern in der zweiten Gruppe, die eine neuere Version als die von der ersten Gruppe qualifizierte Version haben, nicht.

  5. GKE wiederholt diese Schritte von der zweiten Gruppe bis zur dritten Gruppe, bis Cluster in allen Gruppen in der Roll-out-Sequenz auf die neue Version aktualisiert wurden.

Prüfen Sie, wenn Cluster in jeder Gruppe aktualisiert werden, während der Übergangszeit, 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. Weitere Informationen zum Steuern dieses Prozesses finden Sie hier:

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 in der kritischen Produktionsumgebung der Bank eingesetzt werden. 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 anhand einer kleinen Teilmenge des Produktions-Traffics validieren, bevor sie vollständig eingeführt wird.

Zur Umsetzung dieses Plans 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 dienen. Der Administrator muss diesen verbleibenden Clustern daher 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. Test: Diese Phase umfasst alle Cluster in der testing-Flotte. Der Administrator legt eine dreitägige Übergangszeit fest, um eine gründliche Validierung zu ermöglichen.
  2. Staging: Diese Phase umfasst alle Cluster in der staging-Flotte mit einer dreitägigen Übergangszeit.
  3. Produktion in Region us-west1: Diese Phase ist auf die Produktionsflotte ausgerichtet, verwendet aber einen label-selector, um nur die Cluster mit dem Label prod-region: us-west1 einzubeziehen. In dieser Phase kann der Administrator Probleme in einer kleinen Teilmenge von Produktionsclustern mit einer dreitägigen Testphase überwachen.
  4. Produktion in Region europe-west1: Diese Phase umfasst die Cluster in der production-Flotte mit dem Label prod-region: europe-west1. Der Administrator legt eine längere Übergangszeit von vier Tagen für eine gründlichere Validierung fest.
  5. Produktion in 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 Übergangszeit 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 Definition von RolloutSequence und verkürzt die Testdauer für die us-west1-Phase der Produktionsflotte. Da durch diese Änderung der RolloutSequence-Definition die standardmäßige Betriebszeit für alle aktuellen und zukünftigen Roll-outs aktualisiert wird, notiert sich der Administrator, die Betriebszeit 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 Übergangszeit 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.

Außerdem kann der Administrator einen Roll-out verwalten, indem er z. B. einen Roll-out pausiert, wenn Probleme auftreten, oder eine Phase abschließt, wenn er mit den Änderungen in dieser Phase zufrieden ist und sofort fortfahren möchte.

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.

So startet GKE die Einführung einer neuen Version

Standardmäßig erstellt GKE einen neuen Roll-out, wenn ein neues Ziel für automatische Upgrades festgelegt wird. Die Version, die GKE für das Roll-out auswählt, hängt von der Nebenversion und der Release-Version der Cluster in der Sequenz ab. Wenn Ihre Cluster beispielsweise die GKE-Version 1.35 im Regular channel ausführen und GKE das Ziel für das automatische Upgrade auf 1.35.5-gke.1000000 festlegt, erstellt GKE eine neue Rollout.

Sie können aber auch eine Version auswählen, die in GKE eingeführt werden soll.

Bestimmte Version bereitstellen

Sie können auch einen Roll-out für eine bestimmte Version starten, wenn Sie beispielsweise schnell eine Sicherheitslücke schließen oder ein kritisches Problem mit Ihren GKE-Clustern beheben möchten. Durch diese Aktion wird ein Rollout-Objekt erstellt und ein Roll-out in Ihrer Roll-out-Sequenz wird auf dieselbe Weise initiiert wie beim Festlegen eines Ziels für automatische Upgrades durch GKE. Informationen zum Einführen einer neuen Version finden Sie unter Bestimmte Version einführen.

Wenn Sie eine neue Version so schnell wie möglich auf einem Cluster bereitstellen müssen, können Sie alternativ manuelle Cluster-Upgrades für die einzelnen Cluster durchführen. Manuelle Cluster-Upgrades werden auf Clusterebene durchgeführt.

Auswählen der Upgradetypen, die GKE in einer Roll-out-Sequenz ausführt

Standardmäßig führt GKE alle Arten von Clusterupgrades in einer Rollout-Sequenz aus, einschließlich Patch- und Nebenversionsupgrades für die Steuerungsebene und die Knoten.

Es gibt vier Haupttypen von Upgrades:

  • Upgrades der Patchversionen der Steuerungsebene
  • Upgrades der Patchversionen der Knoten
  • Nebenversionsupgrades der Steuerungsebene
  • Upgrades von Nebenversionen der Knoten

Sie können den Umfang von Clusterupgrades in einer Roll-out-Sequenz einschränken, sodass nur bestimmte Arten von Upgrades durchgeführt werden. Wenn Sie beispielsweise möchten, dass GKE nur Upgrades der Steuerungsebene und keine Knotenupgrades ausführt, können Sie dies für Ihre Rollout-Sequenz angeben.

Wenn Sie den Umfang von Clusterupgrades für eine Roll-out-Sequenz einschränken, führt GKE diese Art von automatischem Upgrade für keine Cluster in der Roll-out-Sequenz durch, mit Ausnahme von erforderlichen obligatorischen automatischen Upgrades. Weitere Informationen finden Sie unter Rollouts für obligatorische automatische Upgrades. Wenn Sie den Umfang von Clusterupgrades einschränken, werden laufende Rollouts des eingeschränkten Typs nicht abgebrochen. GKE verhindert dadurch nur, dass zukünftige Rollouts dieses Typs erstellt werden.

Da GKE die Knoten eines Clusters nicht auf eine Version aktualisiert, die neuer als die Steuerungsebene ist, können Sie auch Knotenupgrades einschränken, indem Sie den Umfang von Upgrades der Steuerungsebene einschränken.

Informationen zum Einschränken des Umfangs automatischer Upgrades in einer Roll-out-Sequenz finden Sie unter Auswählen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz durchführt.

Das Einschränken des Bereichs einer Roll-out-Sequenz funktioniert ähnlich wie Wartungsausschlüsse. Wartungsausschlüsse werden jedoch entweder für einzelne Cluster oder Knotenpools innerhalb eines Clusters festgelegt.

Roll-outs für obligatorische automatische Upgrades

Unabhängig davon, ob Ihr Cluster in einer Rollout-Sequenz registriert ist, führt GKE automatische Clusterupgrades für Sicherheit und Kompatibilität durch. Wenn die Steuerungsebenen der Cluster in Ihrer Roll-out-Sequenz seit 90 Tagen nicht aktualisiert wurden oder die Cluster eine Nebenversion ausführen, die das Ende des Supports erreicht hat, erstellt GKE einen obligatorischen Roll-out, um automatische Upgrades durchzuführen. Diese Rollouts tragen dazu bei, dass Ihr Cluster leistungsfähig, verfügbar und sicher bleibt. GKE erstellt Rollouts für diese Szenarien, unabhängig von Einschränkungen des Umfangs von Rollouts, Wartungsausschlüssen oder anderen Gründen für Verzögerungen.

Diese Arten von Roll-outs können nicht pausiert oder abgebrochen werden. GKE führt diese Arten von Clusterupgrades unabhängig von der Registrierung für die Roll-out-Sequenz durch.

Weitere Informationen zu diesen Richtlinien finden Sie in den folgenden Abschnitten:

Roll-out-Berechtigung

Damit eine Version über eine Sequenz mit benutzerdefinierten Phasen eingeführt werden kann, müssen Cluster in ihrem Release-Channel für ein Upgrade-Ziel infrage kommen. Wenn eine neue GKE-Version verfügbar ist, erstellt das System ein Rollout-Objekt, wenn Cluster in der Sequenz für die neue Version infrage kommen. Wir empfehlen, alle Cluster in derselben Release-Version zu registrieren. Wenn dies nicht der Fall ist, wählt GKE eine Version aus der konservativsten Version in der Sequenz aus. Wenn beispielsweise Cluster aus Stable- und Regular-Channels gemischt sind, 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 in einem SOAKING-Zustand mit einer bestimmten Version 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 im Blick behalten. Wenn Sie Versionsabweichungen feststellen, die einen Cluster ungeeignet machen, müssen Sie möglicherweise Maßnahmen ergreifen, z. B. den Cluster manuell aktualisieren oder einen Cluster in einer Einführungssequenz ignorieren, damit die Einführung fortgesetzt werden kann. Wenn ein Cluster nicht für Roll-outs infrage kommt, führt GKE kein automatisches Upgrade des Clusters durch, bis Roll-outs für obligatorische automatische Upgrades erstellt werden müssen, wie im vorherigen Abschnitt beschrieben.

Cluster mit Versionen, die neuer als die Zielversion für das Upgrade 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, aktualisiert GKE die Cluster, 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 können Rollouts für mehrere neue Versionen abgeschlossen werden, während eine nachfolgende Phase pausiert wird (z. B. durch einen Wartungsausschluss) oder noch ein vorheriges Upgrade verarbeitet. Wenn die nachfolgende Phase bereit ist, ein neues Upgrade zu akzeptieren, führt GKE ein Upgrade auf die neueste qualifizierte Version durch. Bei Upgrades der Steuerungsebene kann 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 für Ihre Produktionscluster vorübergehend zu verhindern. Wenn für Ihre Pre-Production-Cluster nicht dieselben Wartungsausschlüsse festgelegt waren, werden diese Cluster möglicherweise mehrmals aktualisiert, wodurch mehrere neue Versionen infrage kommen. Ihre Produktionsumgebungen werden jedoch nicht aktualisiert.

Erzwungener Betrieb nach 30 Tagen

Damit ein Roll-out-Vorgang für das Upgrade von Clustern abgeschlossen wird, 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 Soaking-Zeitraums fortgesetzt werden.

So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures

Die Roll-out-Sequenzierung funktioniert zusammen 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. Mit beiden der folgenden Methoden kann GKE auf bestimmte Arten von Upgrades beschränkt werden:

    Keine dieser Methoden, mit denen der Umfang von Clusterupgrades eingeschränkt wird, verhindert jedoch obligatorische automatische Upgrades. 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.

  • Strategien für Knotenupgrades: Die Roll-out-Sequenzierung hat keine Auswirkungen auf Ihre 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. Dieses Verhalten kann auftreten, 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 von verworfenen APIs: Die Erkennung der Verwendung von verworfenen APIs 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 aktualisieren, 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 fortgesetzt, wenn sie das festgelegte Ziel für automatische Upgrades wird.

  • Clusterbenachrichtigungen: GKE bietet Benachrichtigungen für die Roll-out-Sequenzierung sowie andere verfügbare Clusterbenachrichtigungen. Weitere Informationen finden Sie unter Benachrichtigungen für die Rollout-Sequenzierung.

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 spätere 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.

Benachrichtigungen zur Roll-out-Sequenzierung

GKE sendet Clusterbenachrichtigungen, die wichtige Informationen zu Clusterupgrades auf Clusterebene enthalten. Außerdem stellt GKE Benachrichtigungen zu Roll-out-Sequenzen mit benutzerdefinierten Phasen und den Roll-outs bereit, die mit diesen Roll-out-Sequenzen stattfinden. GKE sendet beispielsweise Benachrichtigungen, wenn eine Rollout-Phase beginnt, abgeschlossen wird oder blockiert ist. Außerdem sendet GKE eine Benachrichtigung, wenn Sie eine Rollout-Sequenz falsch konfiguriert haben. Weitere Informationen finden Sie im Dokument Clusternachrichten und in den entsprechenden Abschnitten für RolloutEvent und RolloutSequenceEvent.

Roll-out verwalten

Wenn GKE eine neue Version für die Cluster in Ihrer Rollout-Sequenz bereitstellt, können Sie die folgenden Aktionen verwenden, um den Prozess zu steuern, während Sie prüfen, wie Ihr Cluster und Ihre Arbeitslasten auf die Änderung reagieren. Außerdem können Sie einen neuen Roll-out erstellen, um eine bestimmte Version bereitzustellen.

Während Upgrades ausgeführt werden, können Sie den Status prüfen. Je nachdem, wie das Upgrade verläuft, können Sie die in den folgenden Unterabschnitten beschriebenen Aktionen ausführen.

Roll‑out pausieren

Sie können ein laufendes Roll-out pausieren. Wenn Sie beispielsweise ein potenzielles Problem mit Ihren Clustern und der neuen Version feststellen, die eingeführt wird, können Sie den Roll-out vorübergehend pausieren. GKE startet keine neuen Upgradevorgänge für diese Version. So können Sie bei Bedarf Probleme untersuchen. GKE beendet laufende Upgradevorgänge nicht, startet aber keine neuen, auch nicht für nachfolgende Phasen.

Informationen zum Pausieren eines Roll-outs finden Sie unter Roll-out pausieren.

Nachdem Sie einen Roll-out pausiert haben, können Sie ihn entweder fortsetzen oder abbrechen. Ein Roll-out kann für bis zu 90 Tage pausiert werden. Nach 90 Tagen bricht GKE die Einführung ab.

Wenn Sie einen Roll-out pausieren, werden nachfolgende Roll-outs nicht verhindert. Diese Roll-outs können jedoch nicht die pausierte Roll-out-Phase überholen. Wenn GKE beispielsweise bereits 1.34.8-gke.1000000 für die erste und zweite Phase eingeführt hat und Sie das Roll-out in der dritten Phase pausieren, kann GKE ein neues Roll-out auf 1.35.5-gke.1163000 starten und Cluster in den ersten beiden Phasen aktualisieren. GKE startet jedoch erst dann Upgrades auf 1.35.5-gke.1163000 in der dritten Phase, wenn der Roll-out von 1.34.8-gke.1000000 in der dritten Phase abgeschlossen oder abgebrochen wurde.

Wenn für eine Rollout-Sequenz mehrere Rollouts laufen und Sie alle pausieren möchten, müssen Sie jeden Rollout einzeln pausieren. Wenn Sie verhindern möchten, dass GKE zusätzliche Roll-outs startet, können Sie auswählen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz ausführt.

Roll-out fortsetzen

Sie können einen pausierten Roll-out, der weniger als 90 Tage pausiert wurde, fortsetzen, nachdem Sie potenzielle Probleme untersucht haben und bereit sind, mit den Upgrades fortzufahren. Sie können ein pausiertes Rollout nur fortsetzen, wenn kein anderes Rollout desselben Typs (Rollout der Steuerungsebene oder Knoten-Rollout) gleichzeitig in derselben Phase ausgeführt wird. Sie können auch einen Roll-out fortsetzen, der aus technischen oder geschäftlichen Gründen automatisch von GKE pausiert wurde. Wir empfehlen jedoch, dies nur mit Vorsicht zu tun.

Wenn Sie den Roll-out fortsetzen, startet GKE neue Upgradevorgänge, um die neue Version in den Phasen der Roll-out-Sequenz weiter bereitzustellen.

Informationen zum Fortsetzen einer Einführung finden Sie unter Einführung fortsetzen.

Roll-out abbrechen

Sie können einen Roll-out abbrechen, auch wenn er aktiv oder pausiert ist. Wenn Sie einen Roll-out abbrechen, erstellt GKE nicht automatisch einen neuen Roll-out für dieselbe Version. Wenn Sie ein Roll-out abbrechen, wird jedoch nicht verhindert, dass GKE später Versionen bereitstellt. Wenn Sie verhindern möchten, dass GKE auch spätere Versionen bereitstellt, brechen Sie alle laufenden Roll-outs ab und beschränken Sie den Umfang von Clusterupgrades in der Roll-out-Sequenz.

Informationen zum Abbrechen eines Rollouts finden Sie unter Rollout abbrechen.

Wenn Sie dieselbe Version bereitstellen möchten, die abgebrochen wurde, stellen Sie eine bestimmte Version bereit.

Roll-out-Phase abschließen

Wenn Sie sicher sind, dass die Einführung einer Version in die nächste Phase der Einführungssequenz übergehen kann, weil Sie beispielsweise Ihre Tests in dieser Phase abgeschlossen haben, können Sie die Einführung manuell fortsetzen, indem Sie die Phase abschließen. Wenn Sie die Phase abschließen, werden alle Cluster, die GKE noch nicht aktualisiert hat, nicht im Rahmen dieses Roll-outs aktualisiert. Wenn Sie die Phase abschließen, wird auch die verbleibende Betriebszeit übersprungen. Diese Aktion bedeutet auch, dass Sie die Übergangszeit auf Ebene der Rollout-Sequenz nicht ändern müssen.

Informationen zum Abschließen einer Roll-out-Phase finden Sie unter Roll-out-Phase abschließen.

Roll-out durch Ändern der Roll-out-Sequenz verwalten

Sie können einen Roll-out auch verwalten, indem Sie Aktionen ausführen, die sich auf die gesamte Roll-out-Sequenz auswirken. Sie sollten jedoch zuerst die in den vorherigen Abschnitten beschriebenen Maßnahmen ergreifen, z. B. die Unterbrechung eines Roll-outs. Einige Änderungen an einer Roll-out-Sequenz können dazu führen, dass laufende Roll-outs abgebrochen werden. Außerdem wird dadurch beeinflusst, wie zukünftige Roll-outs in der Sequenz funktionieren. Wenn Sie nur einen Roll-out ändern möchten, verwenden Sie die bereitgestellten Tools, um einen Roll-out zu verwalten, anstatt die gesamte Sequenz zu ändern.

Wenn Sie jedoch ändern möchten, wie eine Roll-out-Sequenz für alle Roll-outs funktioniert, nicht nur für den Roll-out einer neuen Version, lesen Sie den folgenden Abschnitt Roll-out-Sequenz verwalten.

Einzelne Cluster-Upgrades steuern, um den Roll-out zu verwalten

Für einzelne Clusterupgrades können Sie die folgenden Tools verwenden, um Upgrades zu verwalten:

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

Weitere Informationen finden Sie unter So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures.

Roll‑out-Sequenz verwalten

Wenn Sie eine Rollout-Sequenz verwalten möchten, können Sie grundlegende Aktionen wie die folgenden ausführen:

  • Roll‑out-Sequenz auflisten
  • Roll-out-Sequenz beschreiben

Außerdem können Sie Aktionen wie das Ändern einer Roll-out-Sequenz und das Ignorieren eines Clusters in einer Roll-out-Sequenz ausführen. Diese Aktionen werden in den folgenden Unterabschnitten beschrieben.

Weitere Informationen zum Verwalten des Roll-outs einer Version anstelle der gesamten Roll-out-Sequenz finden Sie im vorherigen Abschnitt Roll-out verwalten.

Cluster in einer Roll-out-Sequenz ignorieren

Standardmäßig werden alle Cluster, die Teil einer Flotte in einer Roll-out-Sequenz sind, im Rahmen der Roll-out-Sequenz aktualisiert. Sie können Cluster bestimmten Phasen hinzufügen. Alle Cluster in einer Flotte, die nicht mit einem Label versehen sind, werden gemeinsam aktualisiert.

Wenn Sie jedoch einen Cluster haben, den Sie nicht in die Roll-out-Sequenz aufnehmen möchten, können Sie ihn so kennzeichnen, dass GKE ihn beim Roll-out neuer Versionen ignoriert. Dies kann beispielsweise erforderlich sein, wenn Sie zusätzliche Zeit benötigen, bevor Sie ein Upgrade für diesen bestimmten Cluster durchführen. Sie können einen oder mehrere Cluster in einer Roll-out-Sequenz ignorieren.

Wenn Sie einen Cluster in einer Roll-out-Sequenz ignorieren, berücksichtigt GKE ihn nicht beim Roll-out einer neuen Version und führt keine automatischen Upgrades für den Cluster durch. Ausgenommen sind obligatorische automatische Upgrades wie automatische Upgrades am Ende des Supports und automatische Upgrades für Steuerungsebenen, die seit 90 Tagen nicht aktualisiert wurden.

Informationen zum Ignorieren eines Clusters in einer Roll-out-Sequenz finden Sie unter Cluster in einer Roll-out-Sequenz ignorieren.

Roll-out-Sequenz ändern

Wenn Sie ändern möchten, wie Roll-outs in einer vorhandenen Roll-out-Sequenz ablaufen, haben Sie zwei Möglichkeiten:

  • Sie können eine Rollout-Sequenz ändern, indem Sie die YAML-Konfigurationsdatei bearbeiten, in der Sie die Sequenz definiert haben.
  • Cluster in der Sequenz ändern

Wenn Sie eine Roll-out-Sequenz ändern, passiert Folgendes:

  • Wenn Sie in einer Rollout-Sequenz eine Phase hinzufügen, entfernen oder bearbeiten, z. B. um die Projekt-ID oder die Label-Selektoren dieser Phase zu ändern, werden alle aktiven Rollouts in GKE abgebrochen.
  • Wenn Sie die Übergangszeit einer Phase ändern, werden aktive Rollouts in GKE nicht abgebrochen.

Informationen zum Ändern einer Roll-out-Sequenz finden Sie unter Roll-out-Sequenz ändern.

Wenn Sie die Cluster in einer Sequenz ändern, passiert Folgendes:

  • Wenn Sie einen Cluster aus einer Roll-out-Sequenz entfernen, indem Sie ihn aus einer Flotte entfernen, werden aktive Roll-outs fortgesetzt. GKE kann den Cluster automatisch auf Grundlage der üblichen Verfahren für Cluster aktualisieren, die nicht in einer Sequenz registriert sind.

  • Wenn Sie einen Cluster in einer Rollout-Sequenz einer Flotte hinzufügen, aktualisiert GKE diesen Cluster im Rahmen aller aktiven Rollouts, die noch nicht die Phase erreicht haben, in der Sie ihn hinzugefügt haben. Wenn die Phase für den Roll-out abgeschlossen ist, führt GKE kein Upgrade des Clusters in diesem Roll-out durch.

    Wenn Sie einen Cluster erstellen möchten, der sofort der Zielversion einer Rollout-Phase entspricht, setzen Sie das Flag --cluster-version beim Erstellen des Clusters auf upgrade-target (Preview). Wenn Sie diesen Cluster beim Erstellen des Clusters für eine bestimmte Phase in einer Rollout-Sequenz registrieren, ermittelt GKE die Zielversion für diese Phase und erstellt den Cluster mit dieser Version.

    Eine Anleitung finden Sie unter Cluster erstellen, der der Zielversion einer Roll-out-Phase entspricht.

  • Wenn Sie einen Cluster in eine andere Phase verschieben, ohne die Konfiguration der Roll-out-Sequenz zu bearbeiten, passiert Folgendes, je nachdem, ob die Phase, in die Sie den Cluster verschieben, abgeschlossen ist:

    • Wenn Sie einen Cluster in eine Phase verschieben, deren Roll-out bereits abgeschlossen ist, führt GKE für diesen Cluster kein Upgrade durch.
    • Wenn Sie einen Cluster, der bereits in einem Roll-out aktualisiert wurde, in eine spätere, noch nicht abgeschlossene Phase verschieben, ignoriert GKE den Cluster und unterbricht den Fortschritt des Roll-outs nicht.

Informationen zum Ändern der Cluster in einer Sequenz finden Sie unter Cluster bei Google Cloud in Ihrer Flotte registrieren.

Beschränkungen

Beim Upgraden von Clustern mit Roll-out-Sequenzierung mit benutzerdefinierten Phasen gelten die folgenden Einschränkungen:

  • Sie können die Google Cloud Console nicht verwenden, um Roll-out-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. Diese Einschränkung bedeutet, dass Sie, wenn Sie eine Phase definieren, die nur auf eine Teilmenge von Clustern aus einer Flotte mit einem label-selector ausgerichtet ist (z. B. für eine stufenweise Bereitstellung), auch eine nachfolgende „Catch-all“-Phase definieren müssen, die alle verbleibenden Cluster aus derselben Flotte enthält. Diese Auffangphase richtet sich an dieselbe Flotte, enthält aber kein label-selector. Dadurch werden automatisch alle Cluster einbezogen, die in früheren Phasen der Sequenz nicht ausgewählt wurden.
  • 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 Übergangszeit einer Sequenz ändern, wird die Einführung von GKE nicht abgebrochen.
  • Auf eine einzelne Flotte kann nur in einer Rollout-Sequenz verwiesen werden. Zwei Rollout-Sequenzen können nicht auf dieselbe Flotte verweisen.
  • Pro Hostprojekt kann nur ein RolloutSequence-Objekt erstellt werden.
  • Sie können Cluster mit Roll-out-Sequenzierung, die beschleunigte automatische Patch-Upgrades verwenden, nicht aktualisieren.
  • Sie können eine Roll-out-Sequenz mit bis zu 15 Phasen erstellen.
  • Sie können bis zu 250 Cluster in eine Flotte aufnehmen. Für Cluster mit Lightweight-Mitgliedschaften können Sie eine Kontingenterhöhung auf bis zu 2.000 Cluster in einer Flotte beantragen. Weitere Informationen finden Sie unter Kontingente und Limits.
  • Sie können für jede Sequenz eine maximale Übergangszeit von bis zu 90 Tagen für alle Phasen konfigurieren.

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 Übergangszeit wird jedoch trotzdem abgewartet, bevor der Roll-out mit der nächsten Phase fortgesetzt wird.

Nächste Schritte