Diskussion: Rolling-, Blue-Green- und Canary-Deployments im Vergleich

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Maschinelle Übersetzung; massgebend ist das Original. Original

«Blue-Green verwenden, wenn eine Mischung von Versionen inakzeptabel ist» verspricht mehr, als die Strategie liefert, weil Blue und Green die Datenbank, die Nachrichtenwarteschlange und jeden anderen zustandsbehafteten unterstützenden Dienst gemeinsam nutzen. Ab dem Moment, in dem der grüne Stack startet (Probedatenverkehr, Aufwärmen, Zustandsprüfungen), lesen und schreiben beide Versionen dieselben Daten, und nach dem Umschalten bleibt der blaue Stack für das sofortige Rollback aktiv und weiterhin verbunden. Die Versionsmischung, die Blue-Green laut Artikel vermeidet, besteht daher während des gesamten Zeitfensters auf der Datenebene, und die im ersten Aufzählungspunkt geforderte Kompatibilität von Schema und Nachrichtenformat ist ebenso erforderlich wie bei einem Rolling Update; nur prozesslokaler Zustand (In-Memory-Caches, Sticky Sessions, langlebige Verbindungen) ist tatsächlich getrennt. Auch das «sofortige Rollback, solange der alte Stack noch läuft» gilt nur, bis die neue Version etwas geschrieben hat, das die alte nicht lesen kann; danach ist das Rollback eine Datenmigration und keine Umschaltung des Datenverkehrs. Die Bedingung sollte lauten: Blue-Green, wenn die Inkompatibilität im prozesslokalen Zustand oder im Deployment-Verfahren selbst liegt, niemals als Ersatz für Expand-and-Contract an der Datenbank.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

'Graceful shutdown on SIGTERM' in the first bullet has a second half that decides whether a rolling update is really zero-error. When a Pod is deleted, the kubelet sends SIGTERM and the endpoint controller removes the Pod from its EndpointSlices at the same time, but the removal has to propagate to every kube-proxy and every ingress or mesh proxy, so requests keep arriving for a moment after the process has been told to stop; a server that closes its listener on SIGTERM immediately produces connection refused errors during every rollout. The usual fix is to keep serving for a few seconds first: a `preStop` hook, for which Kubernetes 1.30 and later offer the built-in `sleep` action (`lifecycle: {preStop: {sleep: {seconds: 5}}}`) without a shell in the image, and a server that keeps accepting during that window. The delay counts against `terminationGracePeriodSeconds`, which defaults to 30 seconds, so a slow drain needs the period raised; `minReadySeconds` on the Deployment slows the other side of the rollout so a new Pod must stay ready for a while before the next old one is removed.