Früher war ein Software-Release ein Ereignis mit Ankündigung: "Wartungsarbeiten heute Nacht von 2 bis 4 Uhr." Heute erwarten Nutzer, dass Anwendungen rund um die Uhr verfügbar sind – und Teams deployen mehrmals täglich. Damit das ohne Ausfallzeit funktioniert, gibt es etablierte Strategien. Dieser Artikel erklärt die drei wichtigsten – Blue-Green, Canary und Rolling Updates – sowie die Bausteine, die ein Zero-Downtime-Deployment überhaupt erst möglich machen.
Was bedeutet Zero-Downtime überhaupt?
Zero-Downtime-Deployment heißt: Während du eine neue Version ausrollst, bleibt die Anwendung für die Nutzer durchgehend erreichbar. Keine Fehlerseiten, keine abgebrochenen Anfragen, keine Wartungshinweise. Die alte Version wird erst aus dem Verkehr gezogen, wenn die neue nachweislich funktioniert und bereitsteht, Anfragen zu übernehmen.
Die gemeinsame Grundvoraussetzung aller Strategien: Du musst mehr als eine Instanz deiner Anwendung betreiben können, und ein Load Balancer oder Router muss den Traffic gezielt umleiten können. Wer nur einen einzigen Server hat, kann echtes Zero-Downtime nur sehr eingeschränkt erreichen.
Rolling Update: schrittweiser Austausch
Das Rolling Update ist die Standardstrategie in Container-Orchestrierern wie Kubernetes. Die Idee: Du hast mehrere identische Instanzen (z. B. fünf Pods). Statt alle gleichzeitig auszutauschen, ersetzt das System sie nacheinander – eine neue Instanz hoch, eine alte runter, dann die nächste.
- Vorteil: Kein zusätzlicher Infrastrukturbedarf, da nicht die doppelte Kapazität nötig ist. Standardmäßig in Kubernetes integriert.
- Nachteil: Während des Rollouts laufen alte und neue Version gleichzeitig. Deine Anwendung muss damit umgehen können (Stichwort Kompatibilität). Ein Rollback dauert ähnlich lange wie das Update selbst.
Zwei Parameter steuern das Verhalten: maxUnavailable (wie viele Instanzen währenddessen offline sein dürfen) und maxSurge (wie viele zusätzliche Instanzen temporär hochgefahren werden). Mit maxUnavailable: 0 stellst du sicher, dass nie Kapazität verloren geht. Mehr Hintergrund zur Orchestrierung findest du in unserem Artikel zu den Kubernetes-Grundlagen.
Blue-Green-Deployment: Umschalten per Knopfdruck
Beim Blue-Green-Deployment betreibst du zwei vollständige, identische Produktionsumgebungen: Blue (die aktuell live laufende) und Green (die neue Version). Du deployst die neue Version komplett nach Green, testest sie dort in Ruhe – im echten Produktionsumfeld, aber ohne echten Nutzer-Traffic. Wenn alles passt, schaltet der Load Balancer den gesamten Traffic auf einen Schlag von Blue auf Green um.
- Vorteil: Das Umschalten ist sofort und sauber. Ein Rollback ist trivial – du leitest den Traffic einfach zurück auf Blue, das ja noch unverändert bereitsteht. Du kannst Green vor dem Go-Live gründlich validieren.
- Nachteil: Du brauchst zeitweise die doppelte Infrastruktur, was kostspielig sein kann. Datenbank-Schemata zwischen den beiden Umgebungen sauber zu halten, erfordert Sorgfalt.
Blue-Green ist ideal, wenn ein sofortiges, vollständiges Umschalten gewünscht ist und du dir den doppelten Footprint zumindest temporär leisten kannst.
Canary-Deployment: vorsichtig herantasten
Das Canary-Deployment (benannt nach dem Kanarienvogel im Bergbau) ist die vorsichtigste Strategie. Statt sofort den ganzen Traffic umzuleiten, schickst du zunächst nur einen kleinen Anteil – etwa 5 % der Nutzer – auf die neue Version. Du beobachtest Metriken wie Fehlerrate, Latenz und Ressourcenverbrauch genau. Sieht alles gut aus, erhöhst du den Anteil schrittweise auf 25 %, 50 % und schließlich 100 %.
- Vorteil: Probleme treffen nur einen Bruchteil der Nutzer. Du sammelst echte Produktionsdaten, bevor du voll ausrollst. Das Risiko eines fehlerhaften Releases wird drastisch reduziert.
- Nachteil: Der Prozess ist komplexer und braucht gutes Monitoring sowie idealerweise Automatisierung, die anhand von Metriken selbst entscheidet, ob weiter ausgerollt oder zurückgerollt wird.
Canary-Deployments leben von guter Observability. Tools wie Prometheus und Grafana liefern die Metriken, anhand derer du die Gesundheit des Canary bewertest. Setze klare Schwellenwerte: Steigt die Fehlerrate über einen definierten Wert, wird automatisch zurückgerollt.
Die unverzichtbaren Bausteine
Health Checks
Ohne aussagekräftige Health Checks ist kein Zero-Downtime-Deployment sicher. Der Orchestrierer muss zuverlässig wissen, ob eine neue Instanz wirklich bereit ist, Traffic zu übernehmen. In Kubernetes unterscheidet man:
- Readiness Probe: Ist die Instanz bereit, Anfragen zu empfangen? Erst wenn ja, leitet der Load Balancer Traffic dorthin.
- Liveness Probe: Läuft die Instanz noch korrekt, oder hängt sie und muss neu gestartet werden?
- Startup Probe: Gibt langsam startenden Anwendungen genug Zeit, bevor die anderen Probes greifen.
Ein guter Health-Check-Endpunkt prüft nicht nur, ob der Prozess lebt, sondern auch, ob kritische Abhängigkeiten wie die Datenbank erreichbar sind.
Graceful Shutdown
Wenn eine alte Instanz aus dem Verkehr gezogen wird, darf sie laufende Anfragen nicht abrupt abbrechen. Sie muss das Signal (typischerweise SIGTERM) abfangen, keine neuen Anfragen mehr annehmen, aber die noch laufenden zu Ende bearbeiten und dann sauber herunterfahren. Diesen Graceful Shutdown muss deine Anwendung aktiv unterstützen.
Die größte Hürde: Datenbankmigrationen
Code lässt sich relativ leicht ohne Downtime austauschen – die Datenbank ist der eigentliche Knackpunkt. Da während des Rollouts alte und neue Anwendungsversion gleichzeitig auf dasselbe Schema zugreifen, müssen Migrationen rückwärtskompatibel sein.
Die bewährte Technik heißt Expand and Contract (auch "Parallel Change"):
- Expand: Erweitere das Schema additiv, ohne Bestehendes zu brechen – etwa eine neue Spalte hinzufügen. Die alte Version ignoriert sie, die neue nutzt sie.
- Migrate: Rolle die neue Anwendungsversion aus, die beide Wege beherrscht. Migriere Daten im Hintergrund.
- Contract: Erst nachdem die alte Version vollständig verschwunden ist, entfernst du in einem späteren Release die nicht mehr benötigten alten Spalten.
Niemals solltest du in einem Deployment gleichzeitig eine Spalte umbenennen oder löschen, auf die die noch laufende alte Version angewiesen ist – das führt unweigerlich zu Fehlern.
Feature Flags als Ergänzung
Eine wertvolle Ergänzung sind Feature Flags. Sie entkoppeln das Ausrollen von Code vom Aktivieren einer Funktion. Du deployst neuen Code, der hinter einem ausgeschalteten Flag schlummert, und aktivierst das Feature erst später per Konfiguration – ganz ohne erneutes Deployment. Geht etwas schief, schaltest du das Flag einfach wieder aus. Das macht Releases entspannter und Rollbacks von einzelnen Features sekundenschnell.
Welche Strategie für wen?
- Rolling Update: Der pragmatische Standard für die meisten Teams, besonders mit Kubernetes. Guter Kompromiss aus Einfachheit und Sicherheit.
- Blue-Green: Wenn du sofortiges Umschalten, einfache Rollbacks und gründliches Vortesten brauchst und dir die doppelte Infrastruktur leisten kannst.
- Canary: Für kritische Anwendungen mit großer Nutzerbasis, bei denen das Risiko eines fehlerhaften Releases minimiert werden muss und gutes Monitoring vorhanden ist.
In der Praxis kombinieren viele Teams die Ansätze – etwa ein Rolling Update mit einer kurzen Canary-Phase am Anfang. Wichtig ist vor allem, dass dein gesamter Deployment-Prozess automatisiert und in einer CI/CD-Pipeline abgebildet ist, damit jeder Schritt reproduzierbar und nachvollziehbar bleibt.
Häufige Fragen
Brauche ich Kubernetes für Zero-Downtime-Deployments?
Nein. Kubernetes macht es bequem, aber das Prinzip funktioniert auch klassisch: mehrere Instanzen hinter einem Load Balancer (z. B. Nginx oder HAProxy), die du nacheinander austauschst. Auch viele PaaS-Anbieter erledigen Zero-Downtime-Deployments automatisch.
Was ist der Unterschied zwischen Blue-Green und Canary?
Bei Blue-Green schaltet der gesamte Traffic auf einmal von alt auf neu um, nachdem die neue Umgebung validiert wurde. Bei Canary wird der Traffic schrittweise prozentual verschoben, während du Metriken beobachtest. Canary ist vorsichtiger, Blue-Green ist schneller im finalen Umschalten.
Wie schnell sollte ein Rollback gehen?
So schnell wie möglich. Bei Blue-Green ist es ein sofortiges Zurückschalten des Load Balancers. Plane Rollbacks immer von Anfang an ein – ein Deployment ohne erprobten Rollback-Weg ist ein Risiko, egal welche Strategie du nutzt.
Reicht ein Server mit Neustart nicht aus?
Für unkritische interne Tools vielleicht. Sobald echte Nutzer betroffen sind, sorgt selbst ein kurzer Neustart für Fehlerseiten und abgebrochene Anfragen. Echtes Zero-Downtime braucht mindestens zwei Instanzen und einen Mechanismus zur Traffic-Umleitung.