Clusterupgrades mit Roll-out-Sequenzierung

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. Zur Verwendung dieses Features sollten Sie mit Cluster-Upgrades, Release-Versionen und Flottenmanagement vertraut sein.

Weitere Informationen finden Sie unter Roll-out von Clusterupgrades sequenzieren.

Upgrades umgebungsübergreifend qualifizieren

Verwenden Sie Folgendes, um Cluster automatisch mit Roll-out-Sequenzierung zu aktualisieren: Flotten oder Team-Bereiche, in denen Sie Ihre Cluster mit derselben Release-Version und derselben Nebenversion in Bereitstellungsphasen gruppiert haben. Wählen Sie die Sequenz von Flotten oder Teambereichen aus und legen Sie fest, wie viel Betriebstestzeit zwischen den einzelnen Clustergruppen gewünscht ist. Wenn GKE dann eine neue Version für automatische Upgrades in der Release-Version auswählt, werden Ihre Gruppen von Clustern in der von Ihnen definierten Reihenfolge aktualisiert. Sie können prüfen, ob Arbeitslasten mit einer neuen Version wie erwartet ausgeführt werden, bevor Upgrades für Ihre Produktionscluster beginnen.

Flottenbasierte Roll-out-Sequenz

Das folgende Diagramm zeigt, wie GKE Cluster automatisch in einer mit Flotten organisierten Roll-out-Sequenz aktualisiert:

Flottenbasierte Roll-out-Sequenz. Sie können Cluster in Flotten organisieren oder mit Bereichen weiter in Flotten unterteilen.

Wenn bei einer flottenbasierten Sequenz GKE ein neues Upgradeziel in der Release-Version zur Verfügung stellt, in der alle Cluster in dieser Sequenz registriert sind, aktualisiert GKE diese Flottencluster in dieser Sequenz, wobei die vorgelagerten Clustern der Flotte die neue Version für Cluster in der nachgelagerten Flotte qualifizieren (für bis zu drei Flotten). Bezieht sich in einer Roll-out-Sequenz vorgelagert auf die vorherige Gruppe und nachgelagert auf die nächste Gruppe.

Während der konfigurierten Betriebszeit zwischen Flotten – nach Abschluss von Upgrades in der vorgelagerten Flotte und bevor sie in der nachgelagerten Flotte beginnen – können Sie prüfen, ob Ihre Arbeitslasten auf den aktualisierten Clustern wie erwartet ausgeführt werden.

Teambasierte Roll-out-Sequenz

Wenn Sie die Cluster in einer Flotte weiter nach Team oder Anwendung unterteilt haben, können Sie eine Roll-out-Sequenz zwischen Teambereichen erstellen. Teambereiche sind ein Konstrukt auf Unternehmensflottenebene, mit dem Teilmengen von Flottenclustern bestimmten Anwendungsteams zugeordnet werden können. Sie können verwendet werden, um eine Reihe von teambasierten Funktionen zu ermöglichen, einschließlich Zugriffssteuerung und teamübergreifende Beobachtbarkeit sowie Rollout-Sequenzierung.

Bereichsbasierte Roll-out-Sequenzen. Sie können Cluster in Flotten organisieren oder mit Bereichen weiter in Flotten unterteilen.

Mit Teambereichen können Sie in einer Flotte mehrere Roll-out-Sequenzen erstellen, die jeweils eigene Release-Versionen, Upgrade-Ziele und unabhängige Betriebszeiten haben. Eine teambasierte Roll-out-Sequenz funktioniert genauso wie eine flottenbasierte Roll-out-Sequenz, außer dass Upgrades zwischen den Clustern eines bestimmten Teams in jeder Flotte qualifiziert werden und nicht von Flotte zu Flotte. Dies ist besonders nützlich für Anwendungsoperatoren, die Upgrades in den Clustern ihres eigenen Teams verwalten möchten.

Die teambasierte Roll-out-Sequenzierung befindet sich in der Vorschau, während die flottenbasierte Roll-out-Sequenzierung allgemein verfügbar ist.

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 oder Bereiche) 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 legt ein neues automatisches Upgrade-Ziel für Cluster in einer Nebenversion in einer bestimmten Release-Version fest, wobei der Versionshinweis in etwa so aussieht: „Steuerungsebenen und Knoten mit automatischem Upgrade im Regular Channel werden mit diesem Release von Version 1.21 auf Version 1.22.15-gke.1000 aktualisiert.“
  2. GKE beginnt mit dem Upgrade der Clustersteuerungsebenen auf die neue Version in der ersten Gruppe von Clustern. Nachdem GKE die Steuerungsebene eines Clusters aktualisiert hat, aktualisiert GKE die Knoten des Clusters. GKE berücksichtigt beim Upgrade von Clustern in einer Roll-out-Sequenz die Wartungsverfügbarkeit.
  3. GKE führt die folgenden Schritte für Upgrades der Steuerungsebene aus:
    1. GKE beginnt mit dem Betriebszeitraum für Upgrades der Steuerungsebene, nachdem alle Upgrades der Clustersteuerungsebene in der ersten Gruppe abgeschlossen wurden oder 30 Tage seit Beginn der Aktualisierungen vergangen sind.
    2. Nach Abschluss des Betriebszeitraums für die Upgrades der Clustersteuerungsebene in der ersten Gruppe beginnt GKE in der zweiten Gruppe mit den Upgrades der Steuerungsebene.
  4. Parallel zu Upgrades der Steuerungsebene führt GKE die folgenden nächsten Schritte für Knotenupgrades aus:
    1. GKE beginnt mit dem Betriebszeitraum für Knotenupgrades, nachdem alle Knotenupgrades des Clusters in der ersten Gruppe abgeschlossen wurden oder 30 Tage seit Beginn der Knotenupgrades vergangen sind.
    2. GKE startet Knotenupgrades in der zweiten Gruppe für Cluster, in denen die Steuerungsebene bereits nach dem Betriebszeitraum für Knotenupgrades in der ersten Gruppe aktualisiert wurde.
  5. GKE wiederholt diese Schritte von der zweiten Gruppe bis zur dritten Gruppe, bis Cluster in allen Gruppen in der Roll-out-Sequenz auf das neue Upgrade-Ziel aktualisiert wurden.

Prüfen Sie, wenn Cluster in jeder Gruppe aktualisiert werden, während der Betriebszeit, ob Ihre Arbeitslasten 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. Weitere Informationen finden Sie unter So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures.

Upgrades in einer Roll-out-Sequenz steuern

Bei Clusterupgrades in einer Roll-out-Sequenz werden Clustergruppen in der von Ihnen definierten Reihenfolge aktualisiert und die Betriebszeit jeder Gruppe wird von Ihnen ausgewählt. Während Upgrades ausgeführt werden, können Sie den Status einer Roll-out-Sequenz prüfen und nach Bedarf die Roll-out-Sequenz verwalten. Sie können den Prozess auch so steuern:

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

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

Der Plattformadministrator einer Community-Bank verwaltet beispielsweise drei Hauptbereitstellungsumgebungen, jeweils mit einer Gruppe von Clustern, die in einer Flotte organisiert sind: Tests, Staging und Produktion. Wie es bei der Roll-out-Sequenzierung erforderlich ist, hat der Administrator jeden Cluster bei allen drei Flotten in derselben Release-Version (in diesen Flotten der Regular Channel) registriert, wobei in allen Clustern dieselbe Nebenversion ausgeführt wird.

Der Administrator verwendet die Roll-out-Sequenzierung, um die Reihenfolge festzulegen, in der GKE Cluster in diesen Umgebungen aktualisiert. Wenn Sie den Roll-out bestellen, kann der Administrator prüfen, ob seine Arbeitslasten wie erwartet mit Clustern in einer neuen GKE-Version ausgeführt werden, bevor die Produktionsumgebung auf die neue Version aktualisiert wird. Diese Sequenz wird durch das Diagramm einer flottenbasierten Roll-out-Sequenz veranschaulicht.

Der Administrator verwendet die Betriebszeit zwischen diesen zu aktualisierenden Flotten, um zu prüfen, ob ihre Arbeitslasten wie erwartet mit Clustern mit der neuen GKE-Version ausgeführt werden. Für die Testflotte legt der Administrator die Betriebszeit auf 14 Tage fest, sodass er zwei volle Wochen Zeit hat, um zu testen, wie die Arbeitslasten ausgeführt werden. Für das Staging legt er die Betriebszeit auf 7 Tage fest, da er nicht so viel zusätzliche Zeit benötigt, nachdem die Arbeitslasten bereits beim Testen ausgeführt wurden.

Der Administrator kann auch die Standardbetriebszeit für Upgrades auf bestimmte Versionen überschreiben, was in den folgenden Situationen sinnvoll sein kann:

  • Der Administrator schließt die Qualifikation der Version vor dem Ende der Betriebszeit ab und möchte, dass Upgrades mit der nächsten Flotte fortgeführt werden. Die Betriebszeit wird daher auf null gesetzt.
  • Der Administrator benötigt mehr Zeit, um die neue Version zu qualifizieren, bevor Upgrades mit der nächsten Flotte fortgesetzt werden können, da er ein Problem mit einigen der Arbeitslasten festgestellt hat. Er setzt die Betriebszeit daher auf das Maximum von 30 Tagen.

Der Administrator verwendet Wartungsfenster und -ausschlüsse, um sicherzustellen, dass 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, um sicherzustellen, dass GKE Cluster nur nach den Geschäftszeiten aktualisiert.
  • Der Administrator verwendet Wartungsausschlüsse, um vorübergehend zu verhindern, dass Cluster aktualisiert werden, wenn Probleme mit den Arbeitslasten des Clusters erkannt werden.

Der Administrator verwendet eine Mischung aus Surge-Upgrades und Blau/Grün-Upgrades für seine Knoten, wobei je nach den Arbeitslasten, die auf diesen Knoten ausgeführt werden, ein Gleichgewicht zwischen Geschwindigkeit und Risikotoleranz gesucht wird.

Administrator wechselt zu teambasierten Roll-out-Sequenzen

Wenn der Administrator entscheidet, Cluster in einer Flotte nach Anwendung weiter zu gruppieren und den Administratoren des Anwendungsteams mehr Kontrolle über ihre Clusterupgrades zu geben, können sie Teambereiche verwenden. Mit Teambereichen können Anwendungsteamadministratoren unabhängige Roll-out-Sequenzen mit den Gruppen von Clustern erstellen, die ihren Teams zugewiesen sind. Diese werden möglicherweise mit verschiedenen Release-Versionen oder mit unterschiedlichen Betriebszeiten ausgeführt.

Wenn das Datenbankteam beispielsweise den Stable Channel und längere Betriebszeiten verwenden soll, während die Cluster des Frontend-Website-Teams den Rapid Channel und kürzere Betriebszeiten verwenden möchten, kann es mit den Teambereichen ein separat Rollout-Sequenzen erstellen. Diese Art von Sequenz wird im Diagramm der teambasierten Roll-out-Sequenz dargestellt. Folgen Sie dazu in Ihrer Umgebung der Anleitung für den Wechsel zwischen flottenbasierten und teambasierten Roll-out-Sequenzen.

Beachten Sie, dass zur Nutzung dieser Funktion Cluster mit einzelner Mandantenfähigkeit erforderlich sind. Das heißt, jeder einzelne Cluster ist nur einem einzelnen Team zugeordnet. Freigegebene Cluster, die in der allgemeinen Verwaltung des Flottenteams unterstützt werden, werden für die Roll-out-Sequenzierung nicht unterstützt. Weitere Informationen zum Verwalten von Clustern für Teams finden Sie unter Flottenteamverwaltung.

Roll-out-Berechtigung

Damit Cluster automatisch mit Roll-out-Sequenzierung aktualisiert werden, müssen alle Cluster in allen Gruppen (Flotten oder Bereichen) in einer Roll-out-Sequenz dasselbe Upgrade-Ziel erhalten. Cluster müssen in derselben Release-Version registriert sein. Außerdem wird empfohlen, dass Cluster dieselbe Nebenversion ausführen und dass die Upgrade-Ziele pro Nebenversion festgelegt werden. Bei einigen Releases, wie dem Release im folgenden Beispiel, haben Cluster aus mehreren Nebenversionen dasselbe Ziel erhalten, was bedeutet, dass die Cluster in der Roll-out-Sequenz mit mehreren Nebenversionen erfolgreich aktualisiert werden können.

Sie können den Status des Versions-Roll-outs in einer Sequenz prüfen, um weitere Informationen zum Status zu erhalten und zu ermitteln, ob Probleme mit der Versionsberechtigung das Fortsetzen der Upgrades verhindern. Je nach Versionsabweichungen müssen Sie möglicherweise Maßnahmen ergreifen, z. B. ein manuelles Upgrade eines Clusters ausführen oder ihn aus einer Gruppe entfernen, damit die Clusterupgrades fortgesetzt werden. Wenn ein Cluster in einer Roll-out-Sequenz kein zulässiges Upgradeziel hat, führt GKE kein automatisches Upgrade des Clusters durch, bis die vorhandene Nebenversion des Clusters End of Life erreicht hat.

Informationen zur Fehlerbehebung in Bezug auf die Roll-out-Berechtigung finden Sie unter Fehler bei der Roll-out-Berechtigung beheben.

Beispiel für einen GKE-Release

Der Release 2022-R25 legt beispielsweise ein Upgradeziel für mehrere Nebenversionen in Clustern fest, die für den Regular Channel registriert sind. Ein Upgradeziel kann eine neue Nebenversion (1.20 bis 1.21) oder einfach eine neue Patchversion (1.21.x-gke.x bis 1.21.14-gke.4300) sein. In diesem Release wurden im Regular Channel die folgenden neuen Versionen für Cluster in bestimmten Nebenversionen zur Verfügung gestellt:

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

Die am weitesten vorgelagerte Gruppe erhält alle Upgradeziele

Bei Clustern in der ersten Gruppe in einer Sequenz, die keine vorgelagerte Gruppe hat, um neue Versionen zu qualifizieren, aktualisiert GKE alle Cluster mit geeigneten Upgradezielen, unabhängig davon, ob sich diese Upgradeziele voneinander unterscheiden. Wenn in der ersten Gruppe einer Sequenz beispielsweise Cluster mit 1.20 ausgeführt wurden, könnten diese Cluster auf 1.21.14-gke.4300 aktualisiert werden, während Cluster mit 1.24 auf 1.24.5-gke.600 aktualisiert werden. Dies liegt daran, dass GKE für die erste Gruppe in einer Abfolge alle Upgradeziele als für diese Cluster qualifiziert betrachtet, da es keine vorgelagerte Gruppe gibt, um eine neue Version zu qualifizieren.

Eine vorgelagerte Gruppe darf nur eine Version qualifizieren

Ob GKE in nachgelagerten Gruppen Cluster aktualisieren kann, hängt davon ab, ob die vorgelagerte Gruppe ein Upgrade-Ziel qualifiziert hat, für das alle Cluster in dieser Gruppe berechtigt sind. Das bedeutet in der Regel, dass alle Cluster mit derselben Nebenversion beginnen. Im Beispiel-Release hatten Cluster mit 1.20 und 1.21 jedoch dasselbe Upgrade-Ziel. Daher können Cluster, die beide Versionen ausführen, in derselben Gruppe das Upgrade auf 1.21.14-gke.4300 qualifizieren.

Wenn nicht alle Cluster in einer Gruppe dasselbe Upgradeziel haben, kann diese Gruppe kein Upgradeziel für die nächste Gruppe qualifizieren. In diesem Fall kann GKE Cluster in nachgelagerten Gruppen nicht automatisch aktualisieren. Wenn beispielsweise in der ersten Gruppe einige Cluster auf 1.21.14-gke.4300 und andere auf 1.23.8-gke.1900 aktualisiert wurden, können die Cluster der zweiten Gruppe nicht automatisch aktualisiert werden, da die Gruppe keine qualifizierte Version erhalten hat. Weitere Informationen zum Upgrade in dieser Situation finden Sie unter Berechtigung für eine Gruppe korrigieren.

Eine vorgelagerte Gruppe muss eine Version qualifizieren, die mit den Clustern der nächsten Gruppe übereinstimmt

Wenn Cluster in einer vorgelagerten Gruppe eine andere Version als jene qualifizieren würden, für die Cluster in der nächsten Gruppe berechtigt sind, könnte GKE die Cluster auch nicht automatisch in nachgelagerten Gruppen aktualisieren.

Wenn beispielsweise alle Cluster in der ersten Gruppe auf 1.21.14-gke.4300 aktualisiert werden würden, die Cluster in der zweiten Gruppe jedoch 1.22 ausführen (wobei das Upgrade-Ziel 1.23.8-gke.1900 ist), würden die Cluster der zweiten Gruppe nicht automatisch aktualisiert werden. Die erste Gruppe würde 1.21.14-gke.4300 qualifizieren, aber die Cluster in der zweiten Gruppe (derzeit mit 1.22) sind nur für das Upgrade-Ziel 1.23.8-gke.1900 berechtigt, sodass GKE diese Cluster nicht automatisch aktualisieren kann. Informationen zum Fortführen von Upgrades in diesem Fall finden Sie unter Berechtigung zwischen Gruppen korrigieren.

So funktioniert die Roll-out-Sequenzierung mit anderen Upgradefeatures

Die Roll-out-Sequenzierung ist ein Feature in einer Sammlung von Features, mit denen Sie den Upgradeaspekt des Clusterlebenszyklus steuern können. In diesem Abschnitt wird erläutert, wie dieses Feature mit einigen der anderen verfügbaren Features im Zusammenhang mit Clusterupgrades funktioniert.

So funktioniert die Roll-out-Sequenzierung mit Wartungsfenstern und -ausschlüssen

GKE berücksichtigt Wartungsfenster und Wartungsausschlüsse, wenn Cluster mit Roll-out-Sequenzierung aktualisiert werden. GKE startet ein Clusterupgrade nur innerhalb des Wartungsfensters eines Clusters. Mit einem Wartungsausschluss können Sie vorübergehend verhindern, dass ein Cluster aktualisiert wird. Wenn GKE einen Cluster aufgrund eines Wartungsfensters oder -ausschlusses nicht upgraden kann, kann dies dazu führen, dass Clusterupgrades in einer Gruppe nicht abgeschlossen werden. Wenn ein Clusterupgrade aufgrund von Wartungsfenstern oder -ausschlüssen nicht innerhalb von 30 Tagen abgeschlossen werden kann, geht die Gruppe in die Betriebsphase über, unabhängig davon, ob alle Cluster aktualisiert wurden.

Sie können Wartungsausschlüsse als temporäre Maßnahme verwenden, um zu verhindern, dass eine Sequenz ein Roll-out für eine Gruppe durchführt und mit der nächsten Gruppe fortfährt. Weitere Informationen finden Sie unter Abschluss des Roll-outs der Version in der Gruppe verzögern.

So funktioniert die Roll-out-Sequenzierung, wenn die Nutzung verworfener APIs und Elemente erkannt wird

GKE pausiert Clusterupgrades, wenn die Nutzung bestimmter verworfener APIs und Features erkannt wird. Automatische Upgrades werden für Cluster in einer Gruppe in einer Roll-out-Sequenz ebenfalls angehalten. Weitere Informationen finden Sie unter Einstellung von Kubernetes und GKE.

So funktioniert die Roll-out-Sequenzierung mit Upgradestrategien für Knoten

Knotenupgrades verwenden ihre konfigurierte Strategie für Knotenupgrades, wenn für sie ein Upgrade in einer Roll-out-Sequenz durchgeführt wird. 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. Weitere Informationen finden Sie unter Überlegungen beim Konfigurieren eines Wartungsfensters.

So funktioniert die Roll-out-Sequenzierung mit Release-Versionen

Für die Verwendung der Roll-out-Sequenzierung sind Release-Versionen erforderlich. Alle Cluster in allen Gruppen einer Roll-out-Sequenz müssen sich in derselben Release-Version befinden.

Mehrere Upgrades innerhalb einer Sequenz erhalten

Wenn eine neue Version zu einem Upgradeziel für die Release-Version wird, während Clusterupgrades auf ein vorheriges Upgradeziel weiterhin in der Roll-out-Sequenz fortgesetzt werden, kann eine vorgelagerte Gruppe mit dem Roll-out einer neuen Version beginnen, während eine nachgelagerte Gruppe noch das vorherige Upgrade erhält. Wenn beispielsweise die dritte Gruppe in einer Sequenz 1.24.2-gke.100 einführt, kann die erste Gruppe in der Sequenz gleichzeitig 1.24.3-gke.500 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.

Dies ist jedoch möglicherweise nicht die richtige Wahl für Ihre Umgebung, wenn eine der folgenden Aussagen zutrifft:

  • Sie haben Cluster, die sich nicht in derselben Release-Version oder Nebenversion in derselben Produktionsumgebung befinden.
  • Sie müssen Upgrades automatisieren, die nicht nur drei Bereitstellungsphasen zugeordnet werden können, da Sie lediglich eine Roll-out-Sequenz mit bis zu drei Gruppen von Clustern erstellen können. Sie können Gruppen in mehreren Roll-out-Sequenzen nicht verknüpfen, um eine Roll-out-Sequenz mit mehr als drei Gruppen zu erstellen.
  • Sie können die Flottenverwaltung nicht verwenden.
  • Sie führen häufig manuelle Upgrades durch, die dazu führen, dass Cluster in einer Gruppe unterschiedliche automatische Upgrade-Zielversionen haben.

Zum Erstellen teambasierter Roll-out-Sequenzen müssen Sie auch in Ihren Flotten-Hostprojekten GKE Enterprise aktivieren können.

Beschränkungen

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

  • Wenn Sie die teambasierte Roll-out-Sequenzierung verwenden, registrieren Sie einen Cluster nur in einem Teambereich. Wenn ein Cluster in mehreren Teambereichen registriert ist, kann GKE den Cluster nicht automatisch in einer teambasierten Roll-out-Sequenz aktualisieren.
  • Das Erstellen einer teambasierten Roll-out-Sequenz mit mehreren Teambereichen innerhalb derselben Flotte wird nicht unterstützt.
  • Erstellen Sie eine lineare Roll-out-Sequenz ohne Zyklen (eine Gruppe hat eine nachgelagerte Gruppe als vorgelagerte Gruppe) oder Zweige (eine Gruppe hat mehr als eine nachgelagerte Gruppe).
  • Erstellen Sie Roll-out-Sequenzen zwischen den Bereichen eines Teams oder Roll-out-Sequenzen zwischen Flotten. Sie können keine gemischten Sequenzen mit sowohl Flotten als auch Teambereichen in derselben Sequenz erstellen.
  • Achten Sie darauf, dass Ihre Cluster in einer Roll-out-Sequenz alle in derselben Release-Version registriert sind und dieselbe Nebenversion ausführen.

Bekannte Probleme

  • Wenn eine Gruppe Cluster an verschiedenen Standorten enthält, ist ein Clusterupgrade aufgrund des graduellen Roll-outs der neuen Version möglicherweise vorübergehend nur für einige Cluster verfügbar. Dies ist für die erste Gruppe von Clustern wahrscheinlicher und sollte innerhalb einer Woche gelöst werden.
  • Wenn eine Roll-out-Sequenz eine leere Gruppe enthält, hängt es von folgenden Bedingungen ab, wie sich dies auf die Versionsqualifizierung auswirkt:
    • Wenn die leere Gruppe keine vorgelagerte Gruppe hat, können Clusterupgrades nicht mit der nachgelagerten Gruppe fortfahren, da die leere Gruppe keine Versionen qualifizieren kann.
    • Wenn die leere Gruppe eine vorgelagerte Gruppe hat, wechseln alle ausstehenden Clusterupgrades in den Status COMPLETE und werden an die nachgelagerte Gruppe weitergegeben.
  • Je nachdem, wie GKE Patch- und Nebenversionsupgrades verfolgt, sehen Sie möglicherweise zwei Upgrades desselben Typs und derselben Version, aber mit unterschiedlichen Status, wenn Sie den Status des Bereichs prüfen.

Nächste Schritte