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 sequenzielle Einführung auf Flottenbasis, die einen eingeschränkten 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 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 eintreten, z. B. die Gleichheit von Namespaces auf Flottenebene. Weitere Informationen finden Sie unter Lightweight Memberships.

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 eine detailliertere Steuerung und mehr Flexibilität, aber keine Cloud de Confiance -Konsolenunterstützung. 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 möchten, bevor Sie sie in größerem Umfang einführen. Außerdem haben Sie mehr Kontrolle über Roll-outs, z. B. können Sie einen Roll-out für eine bestimmte Version starten, 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.
  • Sequenzierung für die Einführung auf Flottenbasis:Diese Version des Features kann nur mit der Cloud de Confiance -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 Stufe zielt auf Cluster mit einem label-selector namens canary in der Flotte prod ab:

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

Wenn 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 keinen Label-Selektor 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 aber einer beliebigen Flotte mehrere Phasen hinzufügen oder nur eine Flotte mit mehreren Phasen verwenden.

Wichtige Konzepte

  • Soak Time (Einwirkzeit): 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 Testlaufzeit von bis zu 30 Tagen konfigurieren. Eine längere Testphase in einer Vorproduktionsphase gibt Ihnen mehr Zeit für die Validierung.
  • RolloutSequence: Dieses Objekt 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 die Testphase abgeschlossen ist, bevor das Upgrade in die nächste Phase übergeht. 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 Reihenfolge angibt, in der die Version eingeführt wird.
  • Dediziertes Hostprojekt: Wir empfehlen, ein dediziertesCloud de Confiance by S3NS -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.
  • Labelselektoren: Eine Rollout-Sequenz 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 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 Betriebszeit an, um auszuwählen, 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 Roll-out-Sequenzierung mit benutzerdefinierten Phasen können Sie alternativ auch einen neuen Roll-out für eine Roll-out-Sequenz für eine bestimmte Version auslösen.

  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 möglicherweise 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 höhere 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 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 kein Upgrade der Knoten von Clustern in der zweiten Gruppe durch, die eine neuere Version als die von der ersten Gruppe qualifizierte Version 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 die neue Version aktualisiert wurden.

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

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

Upgrades in einer Roll-out-Sequenz steuern

Bei Clusterupgrades in einer Roll-out-Sequenz werden Clustergruppen in der von Ihnen definierten Reihenfolge aktualisiert und die Betriebszeit jeder Gruppe wird von Ihnen ausgewählt. 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, bei der die Produktionscluster entsprechend ihrer Region gekennzeichnet werden. So können sie eine neue Version mit einem kleinen Teil des Produktionstraffics testen, 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. Daher muss der Administrator diesen verbleibenden Clustern keine Labels hinzufügen.

Als Nächstes definieren sie in einem dedizierten Hostprojekt, das für die Verwaltung 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 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 Testphase.
  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.

Außerdem kann der Administrator die Einführung verwalten, indem er z. B. die Einführung 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 GKE den Roll-out 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 in 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 bereitgestellt 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, wodurch ein Roll-out in Ihrer Roll-out-Sequenz auf dieselbe Weise wie beim Festlegen eines automatischen Upgradeziels durch GKE initiiert wird. Informationen zum Einführen einer neuen Version finden Sie unter Eine 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 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 ausfü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 Cluster-Upgrades aus Sicherheits- und Kompatibilitätsgründen 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 Rollouts können nicht pausiert oder abgebrochen werden. GKE führt diese Arten von Clusterupgrades unabhängig von der Registrierung für die Roll-out-Sequenzierung 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 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, alle Cluster in derselben Release-Version zu registrieren. 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 im Stable- als auch im Regular-Channel vorhanden sind, wählt GKE die Version aus dem Stable Channel aus.

Der Rollout durchläuft dann die in Ihrem 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 im Blick behalten. Wenn Sie Versionsabweichungen feststellen, die einen Cluster ausschließen, 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 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 nächste 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 nachfolgende 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 Knoten-Upgrades 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 die 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. Mit beiden der folgenden Methoden kann GKE auf bestimmte Arten von Upgrades beschränkt werden:

    Mit keiner dieser Methoden, die den Umfang von Cluster-Upgrades einschränken, werden jedoch obligatorische automatische Upgrades verhindert. 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 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 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 bietet GKE Benachrichtigungen zu Roll-out-Sequenzen mit benutzerdefinierten Phasen und den Roll-outs, die mit diesen Roll-out-Sequenzen stattfinden. GKE sendet beispielsweise Benachrichtigungen, wenn eine Rollout-Phase beginnt, abgeschlossen wird oder blockiert ist. GKE sendet auch eine Benachrichtigung, wenn Sie eine Rollout-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 GKE eine neue Version für die Cluster in Ihrer Bereitstellungsreihenfolge 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, die eingeführt wird, bemerken, können Sie den Roll-out vorübergehend pausieren. GKE startet keine neuen Upgradevorgänge auf 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 die gestaffelte Einführung pausiert haben, können Sie sie entweder fortsetzen oder abbrechen. Ein Roll-out kann für bis zu 90 Tage pausiert werden. Nach 90 Tagen wird der Rollout von GKE abgebrochen.

Wenn Sie ein Roll-out pausieren, wird dadurch nicht verhindert, dass nachfolgende Roll-outs gestartet werden. 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 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 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 angehaltenen Roll-out, der weniger als 90 Tage lang angehalten 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 (Steuerungsebenen- 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 Rollout abbrechen, wird in GKE nicht automatisch ein neuer Rollout für dieselbe Version erstellt. Wenn Sie ein Roll-out abbrechen, wird jedoch nicht verhindert, dass GKE spätere 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 Cluster-Upgrades 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.

Rollout-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 Einweichzeit übersprungen. Außerdem müssen Sie die Testlaufzeit auf der Ebene der Rollout-Sequenz nicht ändern.

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 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-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 Unterabschnitten 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 gemeinsam aktualisiert.

Wenn Sie jedoch einen Cluster haben, den Sie nicht in die Rollout-Sequenz aufnehmen möchten, können Sie ihn so kennzeichnen, dass GKE ihn beim Rollout neuer Versionen ignoriert. Das 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 oder die Reihenfolge der Phasen ändern, z. B. um die Projekt-ID oder die Label-Selektoren einer Phase zu ändern, werden alle aktiven Rollouts in GKE abgebrochen.
  • Wenn Sie die Soak-Zeit einer Phase ändern, werden aktive Rollouts von 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 Roll-out-Sequenz einer Flotte hinzufügen, aktualisiert GKE diesen Cluster im Rahmen aller aktiven Roll-outs, 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 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 Cloud de Confiance by S3NS in Ihrer Flotte registrieren.

Beschränkungen

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

  • Sie können die Cloud de Confiance 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 einem 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 in früheren Phasen der Sequenz nicht 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.
  • 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.
  • Cluster mit Roll-out-Sequenzierung, die beschleunigte automatische Patch-Upgrades verwenden, können nicht aktualisiert werden.
  • 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 anfordern. Weitere Informationen finden Sie unter Kontingente und Limits.
  • Sie können für jede Sequenz eine maximale Soak-Zeit von bis zu 90 Tagen für alle Phasen konfigurieren.

Bekannte Probleme

In diesem Abschnitt werden die bekannten Probleme bei der Einführung in Phasen 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