GKE-Upgrades planbar und sicher: So hilft Rollout Sequencing

Selbst bei einem vollständig verwalteten Service wie GKE bringen Standard-Upgrades mehrere operative Hürden mit sich, die ein DevOps- oder Platform-Team ausbremsen können:

• Das Risiko "Alles auf einmal": Ohne Sequenzierung sind alle Cluster eines Release Channels automatisch upgrade-fähig, sobald eine neue Version zum Standard wird. Liegen Dev- und Prod-Umgebungen im selben Release Channel, können beide im gleichen Zeitfenster aktualisiert werden – ohne Puffer, um Bugs in den unteren Umgebungen abzufangen, bevor sie bei Kunden ankommen.
• Manuelles Gatekeeping: Viele Teams behelfen sich mit Maintenance Windows oder Exclusions, um Upgrades in Produktion manuell zu blockieren, während in Dev getestet wird. Das erfordert ständiges manuelles Eingreifen, akribisches Tracking und bedeutet eine hohe kognitive Last für das SRE-Team.
• Abhängigkeiten und API Deprecations: Kubernetes entwickelt sich schnell. Jede Minor-Version (z. B. 1.33 auf 1.34) kann bestimmte API-Versionen als deprecated kennzeichnen. Trifft ein Upgrade auf einen Cluster mit einem inkompatiblen Helm-Chart oder Operator, starten Services womöglich nicht mehr – und es droht längere Downtime.
• Version Drift: Aus Vorsicht aktualisieren Teams ihre Cluster oft manuell, einen nach dem anderen. Das führt zu Version Drift: Ihre Umgebungen laufen auf leicht unterschiedlichen Patch-Versionen, und es lässt sich nicht mehr garantieren, dass ein Bug aus der Produktion in einer niedrigeren Umgebung reproduzierbar ist.

Rollout Sequencing bringt Struktur, Vorhersagbarkeit und Automatisierung in den Upgrade-Prozess. Deshalb wird es im Enterprise-Umfeld zum Standard für das GKE-Management:

• Deklarativer Lebenszyklus der Infrastruktur: So wie Sie Terraform für Ihre Ressourcen einsetzen, lässt sich mit Rollout Sequencing Ihre Upgrade-Policy als Code definieren. Sie legen die Upstream-/Downstream-Beziehungen zwischen Clustern fest, die Ausführung übernimmt die Control Plane von Google.
• Garantierte "Soak Periods": Sie können programmatisch eine Soak-Zeit von bis zu 30 Tagen erzwingen. So lässt sich beispielsweise vorschreiben, dass eine Version 7 Tage lang fehlerfrei in der Staging Fleet laufen muss, bevor die Production Fleet für diese Version freigegeben wird.
• Bedingte Promotion: Es entsteht eine Promotion-Logik. Eine Version rückt nur dann in die nächste Stufe auf, wenn alle Cluster der vorherigen Stufe erfolgreich aktualisiert wurden. So entsteht eine Sicherheitsbarriere, die Ihre kritischsten Umgebungen schützt.
• Synchronisation auf Flottenebene: Die Funktion baut auf dem Konzept der Fleets auf – logischen Gruppierungen von GKE-Clustern. Statt 100 einzelne Cluster zu konfigurieren, definieren Sie eine oder mehrere Rollout-Sequenzen, die die gesamte Organisationsstruktur steuern.

Google bietet zwei Ansätze, wie Sie Ihre Cluster-Upgrade-Pipeline aufbauen können – je nach Teamstruktur und Risikotoleranz.

Strategie 1: Fleet-basierte Sequenz

Diese Strategie basiert auf dem Prinzip der umgebungsweiten Promotion. Sie organisieren Ihre Cluster in Fleets nach Umgebung (z. B. dev-fleet, test-fleet, prod-fleet). Alle Cluster in allen Gruppen einer Rollout-Sequenz müssen sich im selben Release Channel befinden.

• So funktioniert es: Sie definieren eine Sequenz aus Fleets und legen die Soak-Zeit zwischen den Gruppen fest. Wählt GKE eine neue Version für automatische Upgrades im Release Channel aus, werden Ihre Cluster-Gruppen in der von Ihnen festgelegten Reihenfolge aktualisiert. So können Sie validieren, dass workloads mit der neuen Version wie erwartet laufen, bevor die nächste Gruppe in der Kette an der Reihe ist.

Eine Fleet-basierte Rollout-Sequenz

• Geeignet für: Organisationen mit klar abgegrenzten, umgebungsbasierten Cluster-Gruppen.

Strategie 2: Rollout Sequencing mit Custom Stages (Preview)

Für größere Organisationen oder Teams mit Canary-Anforderungen bieten Custom Stages einen präziseren Ansatz. Statt eine ganze Fleet auf einmal zu bewegen, arbeiten Sie mit Cluster Selectors auf Basis von Labels.

• So funktioniert es: Innerhalb Ihrer Production Fleet richten Sie eine Canary Stage ein. Beispielsweise versehen Sie 5 % Ihrer Produktions-Cluster mit dem Label canary: true. Die Rollout-Sequenz aktualisiert zunächst diese Cluster. Bleiben sie stabil, fährt die Sequenz mit den Clustern der weiteren Stages innerhalb derselben Production Fleet fort.

Eine Rollout-Sequenz mit Custom Stages

• Geeignet für: Große globale Footprints, in denen selbst die Produktion in Wellen aktualisiert werden muss, um Ausfälle zu vermeiden.

Rollout Sequencing ist eine von mehreren Funktionen, mit denen Sie den Upgrade-Aspekt des Cluster-Lebenszyklus steuern.

Beim Upgrade von Clustern mit Rollout Sequencing berücksichtigt GKE die konfigurierten Maintenance Windows und Maintenance Exclusions. Ein Cluster-Upgrade wird nur innerhalb des Maintenance Windows des jeweiligen Clusters gestartet. Mit einer Maintenance Exclusion können Sie einen Cluster vorübergehend vom Upgrade ausnehmen. Kann GKE einen Cluster aufgrund eines Maintenance Windows oder einer Exclusion nicht aktualisieren, kann das dazu führen, dass Cluster-Upgrades innerhalb einer Gruppe nicht abgeschlossen werden.

GKE pausiert automatische Upgrades für Cluster in einer Gruppe einer Rollout-Sequenz außerdem, sobald die Nutzung bestimmter deprecated APIs und Features erkannt wird.