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. Die GKE bietet auch eine frühere Version dieses Features, die flottenbasierte Roll-out-Sequenzierung, die jedoch einen eingeschränkteren Funktionsumfang hat und für neue Umgebungen nicht 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. Sie können beispielsweise zuerst die Cluster in der Entwicklungsumgebung, dann in der Testumgebung und schließlich in der Produktionsumgebung aktualisieren. Diese progressive Strategie bietet eine integrierte Testphase, in der 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 die 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 Roll-out-Sequenzierung logisch gruppieren können, ohne alle Konfigurationen und Funktionen auf Flottenebene aktivieren zu müssen. Die einfache Mitgliedschaft ist eine gute Wahl, wenn Sie die Roll-out-Sequenzierung verwenden möchten, ohne einige der anderen Auswirkungen der vollständigen Flottenverwaltung, z. B. die Gleichheit von Namespaces auf Flottenebene, zu berücksichtigen. Weitere Informationen finden Sie unter Lightweight-Mitgliedschaften.

Strategie für die Roll-out-Sequenz auswählen

GKE bietet zwei Versionen der Roll-out-Sequenzierung. Beide Versionen basieren auf denselben Grundprinzipien progressiver, flottenbasierter 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 eine detailliertere Kontrolle und mehr Flexibilität, aber keine umfassende Unterstützung für die Google Cloud Console. Mit benutzerdefinierten Phasen können Sie mithilfe von Labels bestimmte Phasen innerhalb einer Flotte definieren. Das ist eine gute Wahl für komplexere Roll-out-Strategien, z. B. die Bereitstellung einer neuen Version in einer kleinen Teilmenge von Produktionsclustern vor einem umfassenderen Roll-out. Darüber hinaus haben Sie mehr Kontrolle über Roll-outs, z. B. können Sie einen Roll-out auf eine bestimmte Version initiieren, die Arten von Upgrades auswählen, die in einer Sequenz eingeführt werden sollen, und Roll-outs pausieren oder abbrechen. Wählen Sie diese Option aus, wenn Sie zum ersten Mal eine Roll-out-Sequenz erstellen.
  • Flottenbasierte Roll-out-Sequenzierung: Diese Version des Features wird in der Google Cloud Console umfassender unterstützt, hat aber ansonsten eine eingeschränkte Funktionalität und wird nicht empfohlen, wenn Sie zum ersten Mal eine Roll-out-Sequenz erstellen.

Der Rest dieses Dokuments bezieht sich nur auf die Roll-out-Sequenzierung mit benutzerdefinierten Phasen.

Roll-out-Sequenzierung mit benutzerdefinierten Phasen

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

  • Definieren Sie eine Sequenz mit detaillierten Phasen, die mithilfe von Labels auf bestimmte Teilmengen von Clustern innerhalb einer Flotte abzielen können. Dies ist eine gute Wahl für Strategien wie phasenweise Roll-outs.
  • Die neuen API-Objekte RolloutSequence und Rollout bieten mehr Kontrolle und Beobachtbarkeit.

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 einen 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 aktualisiert, die benutzerdefinierte Phasen verwendet. Die Phase ist auf Cluster mit einem label-selector namens canary in der Flotte prod ausgerichtet:

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

Wenn GKE eine neue Version einführt, werden zuerst die Cluster in der Test-Flotte und dann die Cluster in der Staging-Flotte aktualisiert. Anschließend priorisiert GKE in der Produktionsflotte Cluster, die mit dem label-selector übereinstimmen. Da prod-cluster-1 mit canary: true gekennzeichnet ist, aktualisiert die GKE diesen Cluster als Nächstes. Die GKE aktualisiert am Ende des Prozesses alle verbleibenden Cluster in der Produktionsflotte (in der Hauptphase), da diese Phase keine Labelauswahl hat.

Während der konfigurierten Übergangszeit zwischen den Phasen können Sie prüfen, ob Ihre Arbeitslasten auf den aktualisierten Clustern wie erwartet ausgeführt werden. Das vorherige Beispiel zeigt eine benutzerdefinierte Phase in der Produktionsflotte. Sie können jedoch jeder 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. In dieser Übergangszeit 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 Übergangszeit von bis zu 30 Tagen konfigurieren. Eine längere Übergangszeit in einer 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, mit denen geprüft wird, ob Cluster in früheren Phasen vollständig aktualisiert wurden und ihre Soak-Zeit abgeschlossen haben, bevor das Upgrade mit der nächsten Phase fortgesetzt wird. Jede RolloutSequence hat eine 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 Cluster nicht für ein Upgrade infrage kommen. Jede Rollout ist mit einer bestimmten RolloutSequence verknüpft, die die Sequenz darstellt, in der die Version eingeführt wird.
  • Dediziertes Hostprojekt: Wir empfehlen, ein dediziertesGoogle 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 Roll-out-Sequenzen. Dies ist eine ähnliche Best Practice 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 Roll-out-Sequenz kann auf eine oder mehrere Flotten verweisen. Eine einzelne Roll-out-Sequenz kann Flotten enthalten, die in mehrerenGoogle Cloud -Organisationen gehostet werden.
  • Label-Selektoren: Eine Roll-out-Sequenz besteht aus einer oder mehreren Phasen. Jede Phase enthält Cluster aus einer Flotte. Sie können Label-Selektoren für Cluster verwenden, um eine Flotte weiter in mehrere Phasen aufzuteilen. Dieser Ansatz ermöglicht Strategien wie gestaffelte 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. Die GKE startet einen neuen Roll-out in der Roll-out-Sequenz. Ein Roll-out wird standardmäßig gestartet, wenn die GKE ein neues Ziel für automatische Upgrades für Cluster mit einer Nebenversion in einer bestimmten Release-Version festlegt. Für die Roll-out-Sequenzierung mit benutzerdefinierten Phasen können Sie alternativ ein neues Roll-out über eine Roll-out-Sequenz 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 auch mit dem Betriebszeitraum, 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 Steuerungsebenen der Cluster der ersten Gruppe möglicherweise mehrmals, bevor die Steuerungsebenen der Cluster der zweiten Gruppe aktualisiert werden. In diesem Fall wählt GKE die neueste Version aus, die auch die folgenden Attribute hat:
        • Die Version wird von der ersten Gruppe qualifiziert.
        • Die Version ist höchstens eine Nebenversion neuer als die Version der Steuerungsebene der Cluster der zweiten Gruppe.
      • GKE aktualisiert die Steuerungsebene von Clustern in der zweiten Gruppe nicht, die eine neuere Version als die von der ersten Gruppe qualifizierte Version haben.

  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. Die 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 von der ersten Gruppe qualifiziert.
        • Die Version ist nicht neuer als die Version der Cluster-Steuerungsebene der zweiten Gruppe.
      • Die Knoten von Clustern in der zweiten Gruppe, die eine neuere Version als die von der ersten Gruppe qualifizierte Version haben, werden von GKE nicht aktualisiert.

  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 wie erwartet mit Clustern ausgeführt werden, auf denen die neue GKE-Version ausgeführt wird.

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

Ein Plattformadministrator einer Community-Bank verwaltet drei Hauptbereitstellungsumgebungen: Tests, Staging und Produktion. Die Produktionscluster sind über 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, wobei in allen Clustern dieselbe Nebenversion ausgeführt wird.

Das Hauptziel des Administrators besteht darin, dafür zu sorgen, dass neue GKE-Versionen gründlich geprüft werden, bevor sie in die kritische Produktionsumgebung der Bank gelangen. Außerdem sollen Cluster zuerst in einer Region mit weniger Traffic, dann in einer Region mit mehr Traffic und schließlich in der wichtigsten Region aktualisiert werden. Dazu verwenden sie die Roll-out-Sequenzierung mit benutzerdefinierten Phasen, um eine progressive Upgradestrategie zu definieren, die das Labeln der Produktionscluster nach ihrer Region umfasst. So kann eine neue Version vor der vollständigen Einführung mit einem kleinen Teil des Produktions-Traffics validiert werden.

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öheres Verkehrsaufkommen) werden mit prod-region: europe-west1 gekennzeichnet.
  • Cluster in us-east1 (kritischster Traffic) sind nicht mit Labels versehen. Die letzte Phase für eine Flotte innerhalb einer Sequenz muss als „Catch-all“ 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 umfasst fünf verschiedene Phasen:

  1. Testen: Diese Phase umfasst alle Cluster in der testing-Flotte. Der Administrator legt eine Übergangszeit von drei Tagen fest, um eine gründliche Validierung zu ermöglichen.
  2. Staging: Diese Phase umfasst alle Cluster in der Flotte staging mit einer Übergangszeit von drei Tagen.
  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 einzuschließen. In dieser Phase kann der Administrator eine kleine Teilmenge von Produktionsclustern mit einer dreitägigen Übergangszeit auf Probleme überwachen.
  4. Produktion in der 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 Übergangszeit 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 bietet Administratoren eine detaillierte Kontrolle über ihre Produktionsupgrades und verbessert die Sicherheit und Zuverlässigkeit des Upgradeprozesses erheblich, da potenzielle Probleme erkannt werden, bevor sie sich auf die gesamte Produktionsumgebung auswirken können.

Während eines routinemäßigen Patch-Upgrades 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 diesen Roll-out zu beschleunigen, ändert der Administrator die Definition RolloutSequence und verkürzt die Soak-Dauer für die Phase us-west1 der Produktionsflotte. Da diese Änderung an der Definition von RolloutSequence die Standard-Übergangszeit für alle aktuellen und zukünftigen Roll-outs aktualisiert, merkt sich der Administrator, die Übergangszeit nach Abschluss dieses spezifischen 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 von Nebenversionen gilt.

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 ein Roll-out verwalten, indem er beispielsweise ein Roll-out pausiert, wenn er Probleme feststellt, 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 die GKE das Roll-out einer neuen Version

Standardmäßig erstellt die GKE ein neues 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 in Regular channel ausführen und die GKE ein Ziel für das automatische Upgrade auf 1.35.5-gke.1000000 festlegt, erstellt die GKE eine neue Rollout.

Sie können aber auch eine Version auswählen, die von GKE bereitgestellt werden soll.

Bestimmte Version einführen

Sie können auch ein Roll-out auf eine bestimmte Version initiieren, wenn Sie beispielsweise eine Sicherheitslücke schnell schließen oder ein kritisches Problem mit Ihren GKE-Clustern beheben möchten. Dadurch wird ein Rollout-Objekt erstellt, das einen Roll-out in Ihrer Roll-out-Sequenz initiiert, so wie wenn GKE ein automatisches Upgradeziel festlegt. Informationen zum Roll-out 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 Clusterupgrades für die einzelnen Cluster durchführen. Manuelle Clusterupgrades werden auf Clusterebene durchgeführt.

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

Standardmäßig führt GKE alle Arten von Clusterupgrades in einer Roll-out-Sequenz aus, einschließlich Upgrades der Patch- und Nebenversionen für die Steuerungsebene und die Knoten.

Es gibt vier Haupttypen von Upgrades:

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

Sie können den Umfang von Clusterupgrades in einer Roll-out-Sequenz so einschränken, dass nur bestimmte Arten von Upgrades ausgefü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 Roll-out-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 automatischen Upgrades. Weitere Informationen finden Sie unter Roll-outs für obligatorische automatische Upgrades. Wenn Sie den Umfang von Clusterupgrades einschränken, werden laufende Roll-outs des eingeschränkten Typs nicht abgebrochen. Es wird nur verhindert, dass die GKE zukünftige Roll-outs dieses Typs erstellt.

Da die GKE die Knoten eines Clusters nicht auf eine Version aktualisiert, die neuer als die Steuerungsebene ist, kann die Einschränkung des Umfangs von Upgrades der Steuerungsebene auch Knotenupgrades 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 ausführt.

Das Einschränken des Umfangs 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 Roll-out-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 wenn 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 Roll-outs tragen dazu bei, dass Ihr Cluster leistungsstark, verfügbar und sicher bleibt. Die GKE erstellt Roll-outs für diese Szenarien, unabhängig von Einschränkungen des Umfangs von Roll-outs, 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 für ein Upgradeziel aus ihrer Release-Version infrage kommen. Wenn eine neue GKE-Version verfügbar ist, erstellt das System ein Rollout-Objekt, sofern 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 die GKE eine Version aus der konservativsten Release-Version in der Sequenz aus. Wenn Cluster beispielsweise zwischen Stable und Regular Channel gemischt sind, wählt GKE die Version aus dem Stable Channel aus.

Der Rollout durchläuft dann die in der RolloutSequence definierten Phasen. Innerhalb einer bestimmten Phase können das Roll-out der Steuerungsebene und das Roll-out des Knotenpools parallel ausgeführt werden. Eine wichtige Regel für diesen Ablauf ist, dass eine Phase, die sich mit einer bestimmten Version im Status SOAKING befindet, nicht für eine neue Rollout für eine neuere Version infrage kommt. So wird sichergestellt, dass eine Version vollständig validiert ist, bevor das nächste Upgrade beginnt. Sie können den Fortschritt und die Eignung jedes Clusters beobachten, indem Sie das Objekt Rollout überwachen. Wenn Sie Versionsabweichungen feststellen, die einen Cluster ungeeignet machen, müssen Sie möglicherweise Maßnahmen ergreifen, z. B. ein manuelles Upgrade des Clusters ausführen oder einen Cluster in einer Roll-out-Sequenz ignorieren, damit der Roll-out fortgesetzt werden kann. Wenn ein Cluster für keine 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, auf denen neuere Versionen als das Upgradeziel ausgeführt werden, verhindern keine Upgrades

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

Wenn die Zielversion eines Roll-outs für eine Phase beispielsweise 1.32 ist und diese Phase Cluster mit den Versionen 1.31 und 1.33 enthält, aktualisiert GKE die Cluster mit Version 1.31 auf 1.32 und ignoriert die Cluster, die bereits Version 1.33 haben.

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

In einer vorherigen Phase einer Sequenz können Roll-outs für mehrere neue Versionen abgeschlossen werden, während eine nachfolgende Phase pausiert ist (z. B. durch einen Wartungsausschluss) oder noch ein vorheriges Upgrade verarbeitet. In diesem Fall aktualisiert GKE die Phase auf die neueste qualifizierte Version, wenn die nachfolgende Phase für ein neues Upgrade bereit ist. Bei Upgrades der Steuerungsebene darf diese Version höchstens eine Nebenversion höher sein als die Version der Steuerungsebene der Cluster in der nachfolgenden Phase. Bei Knotenupgrades kann diese Version mit der Version der Steuerungsebene der Cluster in der nachfolgenden Phase übereinstimmen, darf aber nicht höher sein.

Dieses Szenario ist beispielsweise relevant, wenn Sie Wartungsausschlüsse konfiguriert haben, um Upgrades für Ihre Produktionscluster vorübergehend zu verhindern. Wenn Ihre Vorproduktionscluster nicht dieselben Wartungsausschlüsse hatten, werden diese Cluster möglicherweise mehrmals aktualisiert, wodurch mehrere neue Versionen qualifiziert werden, aber Ihre Produktionsphasen werden nicht aktualisiert.

Erzwungener Betrieb nach 30 Tagen

Damit eine Roll-out-Sequenz die Clusterupgrades abschließt, startet GKE den Betriebszeitraum für eine Gruppe, wenn die Upgrades der Steuerungsebene oder der Knoten nicht innerhalb der maximalen Upgradezeit (30 Tage) für alle Cluster abgeschlossen sind. Die Upgrades für alle verbleibenden Cluster in der Gruppe können während des Testzeitraums fortgesetzt werden.

So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures

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

  • Wartungsfenster und -ausschlüsse: Sie können weiterhin Wartungsfenster und -ausschlüsse verwenden, um zu steuern, wann Upgrades für Ihre Cluster durchgeführt werden können und wann nicht. 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 den beiden folgenden Methoden können Sie GKE auf bestimmte Arten von Upgrades beschränken:

    Keine dieser Methoden, die den Umfang von Clusterupgrades einschränken, 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. 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-Versionen: Wir empfehlen, alle Cluster in einer Roll-out-Sequenz in derselben Release-Version zu registrieren.

  • Erkennung der Nutzung verworfener APIs: Die Erkennung der Nutzung verworfener 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 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 wurden. Bei einem manuellen Upgrade werden die Cluster aktualisiert, aber die Sequenz wird für diese Version erst fortgesetzt, wenn sie zum festgelegten 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 zur Roll-out-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 in der ersten Phase mit dem Roll-out einer neuen Version begonnen werden, auch wenn in späteren Phasen noch das vorherige Upgrade erhalten wird. Wenn beispielsweise die dritte Gruppe in einer Sequenz die Version 1.31.12-gke.1265000 einführt, kann die erste Gruppe in der Sequenz gleichzeitig die 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

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

Roll-out verwalten

Wenn die GKE eine neue Version für die Cluster in Ihrer Roll-out-Sequenz bereitstellt, können Sie mit den folgenden Aktionen den Prozess steuern, während Sie prüfen, wie Ihr Cluster und Ihre Arbeitslasten auf die Änderung reagieren. Darüber hinaus 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 voranschreitet, können Sie die in den folgenden Abschnitten beschriebenen Aktionen verwenden.

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 gerade eingeführt wird, können Sie den Roll-out vorübergehend pausieren. GKE startet keine neuen Upgradevorgänge auf diese Version, sodass Sie bei Bedarf Probleme untersuchen können. Die 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 ein Roll-out pausiert haben, können Sie es entweder fortsetzen oder abbrechen. Ein Roll-out kann bis zu 90 Tage lang pausiert werden. Nach 90 Tagen bricht die GKE den Roll-out ab.

Wenn Sie ein Roll-out pausieren, werden nachfolgende Roll-outs nicht daran gehindert, zu starten. Diese Roll-outs überholen jedoch nicht die pausierte Roll-out-Phase. Wenn GKE beispielsweise bereits 1.34.8-gke.1000000 in der ersten und zweiten Phase eingeführt hat und Sie den Roll-out in der dritten Phase pausieren, kann GKE einen neuen 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 Roll-out-Sequenz mehrere Roll-outs ausgeführt werden und Sie alle pausieren möchten, müssen Sie jeden Roll-out einzeln pausieren. Wenn Sie verhindern möchten, dass die GKE zusätzliche Roll-outs startet, können Sie auswählen, welche Arten von Upgrades die GKE in einer Roll-out-Sequenz ausführt.

Roll-out fortsetzen

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

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 eines Roll-outs finden Sie unter Roll-out fortsetzen.

Roll-out abbrechen

Sie können einen Roll-out abbrechen, einschließlich Roll-outs, die aktiv sind oder pausiert wurden. Wenn Sie ein Roll-out abbrechen, erstellt GKE nicht automatisch ein neues Roll-out für dieselbe Version. Das Abbrechen eines Roll-outs verhindert jedoch nicht, dass GKE spätere Versionen einführt. Wenn Sie verhindern möchten, dass GKE auch spätere Versionen bereitstellt, brechen Sie alle laufenden Roll-outs ab und schränken Sie den Umfang der Clusterupgrades in der Roll-out-Sequenz ein.

Informationen zum Abbrechen eines Roll-outs finden Sie unter Roll-out 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 der Roll-out einer Version zur nächsten Phase in der Roll-out-Sequenz übergehen kann, weil Sie beispielsweise Ihre Tests in dieser Phase abgeschlossen haben, können Sie den Roll-out 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 Übergangszeit übersprungen. Diese Aktion bedeutet auch, dass Sie die Übergangszeit auf der Ebene der Roll-out-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. Bevor Sie dies tun, sollten Sie jedoch die in den vorherigen Abschnitten beschriebenen Maßnahmen ergreifen, z. B. das Pausieren eines Roll-outs. Einige Änderungen an einer Roll-out-Sequenz können dazu führen, dass laufende Roll-outs abgebrochen werden. Außerdem können sie sich darauf auswirken, wie zukünftige Roll-outs in der Sequenz funktionieren. Wenn Sie nur ein Roll-out ändern möchten, verwenden Sie die bereitgestellten Tools, um ein Roll-out zu verwalten, anstatt die gesamte Sequenz zu ändern.

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

Einzelne Clusterupgrades 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

Zum Verwalten einer Roll-out-Sequenz können Sie grundlegende Aktionen wie die folgenden ausführen:

  • Roll‑out-Sequenzen 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 Abschnitten beschrieben.

Weitere Informationen zum Verwalten des Roll-outs einer einzelnen 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, die sich in einer Flotte befinden und nicht mit einem Label versehen sind, werden zusammen 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 den Cluster beim Roll-out neuer Versionen ignoriert. Das kann beispielsweise erforderlich sein, wenn Sie vor dem Upgrade dieses bestimmten Clusters mehr Zeit benötigen. Sie können einen oder mehrere Cluster in einer Roll-out-Sequenz ignorieren.

Wenn Sie einen Cluster in einer Roll-out-Sequenz ignorieren, wird er von GKE beim Roll-out einer neuen Version nicht berücksichtigt. Außerdem werden für den Cluster keine automatischen Upgrades durchgeführt, mit Ausnahme von obligatorischen automatischen Upgrades, einschließlich automatischer Upgrades am Ende des Supports und automatischer 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 die Vorgehensweise bei Roll-outs in einer vorhandenen Roll-out-Sequenz ändern möchten, können Sie die Sequenz auf zwei Arten ändern:

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

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

  • Wenn Sie in einer Roll-out-Sequenz eine Phase hinzufügen, eine Phase entfernen, die Reihenfolge der Phasen ändern oder eine Phase bearbeiten, z. B. um die Projekt-ID oder die Labelselektoren dieser Phase zu ändern, bricht GKE alle aktiven Roll-outs ab.
  • Wenn Sie die Übergangszeit einer Phase ändern, bricht GKE aktive Roll-outs nicht ab.

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

Wenn Sie die Cluster in einer Sequenz ändern, geschieht 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 gemäß den typischen Verfahren für Cluster aktualisieren, die nicht in einer Sequenz registriert sind.
  • Wenn Sie einen Cluster in einer Roll-out-Sequenz zu einer Flotte hinzufügen, aktualisiert GKE diesen Cluster im Rahmen aller aktiven Roll-outs, die die Phase, in der Sie ihn hinzugefügt haben, noch nicht durchlaufen haben. Wenn die Phase für den Roll-out jedoch abgeschlossen ist, führt GKE kein Upgrade des Clusters in diesem Roll-out durch.

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

    • Wenn Sie einen Cluster in eine Phase verschieben, in der das Roll-out bereits abgeschlossen ist, führt GKE kein Upgrade des Clusters in diesem Roll-out 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 in Google Cloud bei Ihrer Flotte registrieren.

Beschränkungen

Die folgenden Einschränkungen gelten, wenn Sie Ihre Cluster mithilfe der Roll-out-Sequenzierung mit benutzerdefinierten Phasen aktualisieren:

  • Sie können die Google Cloud Console nicht verwenden, um Roll-out-Sequenzen mit benutzerdefinierten Phasen zu erstellen oder zu ändern. Sie können die Console jedoch verwenden, um ein Roll-out zu überwachen (Vorabversion).
  • Wenn eine Roll-out-Sequenz auf eine Flotte verweist, müssen Sie die gesamte Flotte einbeziehen. Diese Einschränkung bedeutet, dass Sie, wenn Sie eine Phase so definieren, dass sie nur auf eine Teilmenge von Clustern aus einer Flotte mit einem label-selector abzielt (z. B. für eine phasenweise Bereitstellung), auch eine nachfolgende „Catch-all“-Phase definieren müssen, die alle verbleibenden Cluster aus derselben Flotte enthält. Diese Catch-all-Phase ist auf dieselbe Flotte ausgerichtet, enthält aber keinen label-selector. Dadurch werden automatisch alle Cluster einbezogen, die nicht in früheren Phasen der Sequenz ausgewählt wurden.
  • Wenn Sie eine Sequenz während eines Roll-outs ändern, insbesondere Änderungen, die sich auf die beteiligten Cluster auswirken, bricht GKE alle vorhandenen Roll-outs sofort ab. Wenn Sie nur die Übergangszeit einer Sequenz ändern, bricht GKE den Roll-out nicht ab.
  • Eine Phase kann auf maximal eine Flotte verweisen. Sie können nicht mehrere Flotten in einer einzelnen Phase haben.
  • Eine einzelne Flotte kann nur in einer Roll-out-Sequenz referenziert werden. Zwei Roll-out-Sequenzen können nicht auf dieselbe Flotte verweisen.
  • Sie können Cluster mit Roll-out-Sequenzierung, die beschleunigte automatische Patchupgrades 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 Erhöhung des Kontingents auf bis zu 2.000 Cluster in einer Flotte beantragen. Weitere Informationen finden Sie unter Kontingente und Limits.
  • Sie können eine maximale Übergangszeit pro Sequenz von bis zu 90 Tagen für alle Phasen konfigurieren.

Bekannte Probleme

In diesem Abschnitt werden die bekannten Probleme bei der Roll-out-Sequenzierung 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 vergeht jedoch, bevor der Roll-out mit der nächsten Phase fortgesetzt wird.

Nächste Schritte