Wer braucht Blue-Green? Geschichten aus dem Schützengraben der Live-Cluster-Upgrades
Einen Kubernetes-Cluster live zu aktualisieren, klingt vielleicht nach einem Spiel mit dem Feuer – aber fragt man genug Engineers, findet man überraschend viele, die die Streichhölzer griffbereit haben.
In einer idealen Welt würden wir alle Blue-Green-Deployments mit chirurgischer Präzision durchführen: einen neuen Cluster hochfahren, die Umgebung spiegeln, alle Integrationstests durchlaufen lassen und erst umschalten, wenn die Sterne günstig stehen. Aber in der echten Welt? Viele Teams sagen: „Ist mir egal, dann eben in-place."
Und ehrlich gesagt funktioniert es öfter, als man erwarten würde.
Der bequeme Weg ist nicht immer der falsche
Das Geständnis, das diese Welle der Kameradschaft auslöste, war simpel: „Ich aktualisiere den Cluster in-place, weil ich zu faul für Blue-Green bin."
Es gab keine große architektonische Ausrede oder aufwendige Risikobewertung. Nur einen ganz menschlichen Moment von „Ich hab einfach keine Lust." Und die Reaktion? Über 700 Upvotes und ein Kommentarbereich, der sich wie Gruppentherapie für DevOps-Engineers las, die schon mal freitags Änderungen live geschaltet haben.
Es stellt sich heraus: Viele Leute machen das ständig. Und sie überleben, um davon zu erzählen.
Die Realität von Cluster-Upgrades in freier Wildbahn
Man würde Horrorgeschichten von kaputten Deployments und panischen Rollbacks erwarten – und ja, ein paar davon gibt es –, aber größtenteils ist es einfach eine Mischung aus trockenem Humor, Stammeswissen und dem gemeinsamen Verständnis, dass niemand die Zeit oder das Budget für makellose Infrastruktur-Hygiene hat.
Ein Kommentator brachte es unverblümt auf den Punkt: „Ich mache das seit Jahren in-place. Blue/Green schaue ich mir vielleicht 2026 mal an."
Ein anderer stimmte zu: „Ja, hier auch AKS ... wir machen das von Anfang an in-place ... wir haben genug Umgebungen, um vorher alles zu testen." Das ist ein roter Faden: gründlich testen, die Luft anhalten und auf Upgrade drücken.
Aber verwechseln Sie den lockeren Ton nicht mit Leichtsinn. Viele dieser Engineers haben einen Spielplan, auch wenn er eher Grabenkampf als chirurgischer Präzisionsschlag ist. Sie staffeln Node-Pool-Upgrades, drainen Nodes vorsichtig, prüfen CRDs doppelt und proben das Upgrade oft zuerst auf einem Staging-System.
„Alles in Default" und andere mutige Manöver
Die MVP-Auszeichnung für Chaos-Gelassenheit geht an die Leute, die Dev, QA und Prod in einem einzigen Cluster betreiben – manchmal sogar im selben Namespace. Ein Kommentar traf die Stimmung genau: „Ja, das ist gleichzeitig auch der Dev- und QA-Cluster." Direkt gefolgt von: „Die ganz Mutigen nutzen sogar einen einzigen Namespace für alle drei."
Man kann das kollektive Entsetzen jedes Compliance-Beauftragten hören, der das hier liest. Und trotzdem ist der Himmel noch nicht eingestürzt – zumindest noch nicht.
Manche gaben zu, dass sie nicht einmal einen separaten Dev-Cluster haben. Ein Nutzer brachte es auf den Punkt: „Ich habe keinen Dev-Cluster, beantwortet das Ihre Frage?" Ja. Ja, das tut es.
Die Kosten dafür, es „richtig" zu machen
Hier ist der Punkt: Bei Blue-Green-Deployments geht es nicht nur um Best Practices. Es geht um Ressourcen. Zeit, Geld, Personal. Und viele Teams – besonders Startups oder kleinere Engineering-Organisationen – müssen das theoretisch Beste gegen das praktisch „gut genug" abwägen.
Ein Architekt sprach den Elefanten im Raum an: „Der Chefarchitekt erzählt mir gerne, dass wir nicht reif genug sind, weil wir kein Blue-Green oder keinen laufenden Backup-Cluster haben. Ich muss ihn dann daran erinnern, dass wir genau so angefangen haben, es aber wegen der Kosten … der Komplexität wieder eingestellt haben."
Das ist keine Faulheit. Das sind Kompromisse. Die Art, die jeder Engineer jeden Tag eingeht.
EKS, AKS und die Kuscheldecke der Managed Control Planes
Bei Nutzern von Managed Services wie EKS und AKS ist ein spürbarer Vertrauensschub zu beobachten. Wenn jemand anderes die Control Plane im Blick behält, fällt es leichter zu sagen: „Ja, machen wir es einfach live."
Wie ein Nutzer schrieb: „Verwalte jetzt EKS, im vorherigen Job war es self-managed – beides geht in-place problemlos, man muss vorher nur die Breaking Changes lesen."
Das eigentliche Kopfzerbrechen? Node-Upgrades. Besonders wenn man Dinge wie Jenkins betreibt, die mit beweglichen Zielen nicht gut zurechtkommen. Oder bei self-managed Setups, wo sich jeder Upgrade-Schritt anfühlt, als würde man mit verbundenen Augen eine Bombe entschärfen.
„Lernen macht Spaß" (bis es das nicht mehr tut)
Die Geschichten häufen sich – von Entwicklern, die Nodes gelöscht haben, weil sie dachten, das würde das Upgrade beschleunigen, nur um zu spät zu merken, dass sie keine funktionierenden Node-Pools mehr hatten, bis hin zu solchen, die jedem Entwickler ein Cluster-Admin-Zertifikat in die Hand gedrückt und auf das Beste gehofft haben.
Ein Veteran brachte die Haltung auf den Punkt: „Manchmal ist es besser, einfach reinzuspringen und es unterwegs herauszufinden. Wenn es Produktion ist, wette ich, dass man es bis zum Morgen rausgefunden hat." Eine Aussage, die sich weniger wie ein Ratschlag anfühlt und mehr wie eine DevOps-Mutprobe.
Also ... wer braucht wirklich Blue-Green?
Ist Blue-Green ein Luxus? Ein Zeichen von Reife? Oder einfach nur eine weitere Checkbox auf der großen DevOps-Wunschliste?
Vielleicht alles drei. Der Punkt ist nicht, dass Blue-Green falsch ist – der Punkt ist, dass man auch nicht falsch liegt, wenn man es nicht macht.
Was die Schützengräben uns zeigen, ist, dass Teams es zum Laufen bringen. Sie biegen Best Practices so zurecht, dass sie zu ihrer Realität passen. Sie priorisieren Testabdeckung, gewissenhaftes Lesen der Dokumentation und Trockenläufe auf Staging – auch wenn sie am Ende auf „Upgrade" klicken, direkt auf demselben Prod-Cluster, der gerade Traffic bedient.
Und sie tun es, weil es das ist, was ihre Infrastruktur, ihr Budget und ihr Geschäft zulassen.
Die eigentliche Lektion: Das Chaos annehmen, aber es respektieren
Das ist keine Feier von Cowboy-Engineering. Es ist die Anerkennung, dass echte Infrastrukturarbeit in der unordentlichen Mitte zwischen Theorie und Praxis stattfindet.
Wenn Sie in-place aktualisieren, gut. Machen Sie es sorgfältig. Kennen Sie Ihre Abhängigkeiten. Drainen Sie Ihre Nodes. Lesen Sie die Breaking Changes. Und wenn Sie das Glück haben, sich den Luxus von Blue-Green leisten zu können, umso besser – aber das macht Sie nicht moralisch überlegen.
Entscheidend ist, zu wissen, warum man es so macht, wie man es macht.
Denn am Ende des Tages ist es Kubernetes egal, ob man faul, vorsichtig oder brillant ist. Es interessiert nur, ob man etwas kaputt macht.
Und wenn es passiert – nicht falls –, bleibt nur zu hoffen, dass die DNS-Umstellung schnell geht, die CRDs sich benehmen und der Rollback-Plan nicht einfach nur „dem Provider die Schuld geben" lautet.