Zero-Downtime-Deployments ohne Kubernetes: Bewährte Ansätze

Zero-Downtime-Deploys ohne Kubernetes: Die „uralten Methoden“ liefern immer noch ab

Seit Jahren ist Kubernetes der Lieblingshammer der Branche, und jedes Software-Deployment-Problem sah aus wie ein Nagel. Ein Grund, warum Leute danach greifen, ist einfach: Kubernetes lässt Zero-Downtime-Deployments so leicht wirken wie das Umlegen eines Schalters. Neue Version ausrollen, die alte am Leben halten, bis die neue stabil läuft, den Load Balancer den Traffic umverteilen lassen, fertig.

Leute haben aber schon lange vor dem großen Auftritt von Kubernetes Code ohne Downtime ausgeliefert, und sie tun es heute noch, oft mit weit weniger Komplexität, weniger beweglichen Teilen und deutlich geringerer kognitiver Last. Wer mit Engineers abhängt, die schon eine Weile in den Schützengräben stehen, hört immer wieder dasselbe: Kubernetes ist bequem, aber nur einer von mehreren Wegen und nicht mal immer der beste.

In einer Welt, in der „nutz einfach Kubernetes“ zum Standardrefrain geworden ist, erleben die sogenannten „uralten Methoden“ des Deployments ein Comeback. Mit Nostalgie hat das wenig zu tun, sie funktionieren einfach immer noch erschreckend gut.

Der Load Balancer als ursprünglicher MVP

Die häufigste Antwort erfahrener Engineers kommt mit einem Achselzucken, als ginge es um eine Frage zur Schwerkraft: Zwei Server betreiben und den Load Balancer die Arbeit machen lassen.

Dieser Ansatz ist älter als manche Cloud-Engineers von heute. Sie ziehen zwei Instanzen hoch (oder zwanzig), richten einen Load Balancer darauf aus und aktualisieren eine Instanz nach der anderen. Solange Ihre App weiß, wie man sich höflich verabschiedet (dazu später mehr), können Sie neuen Code ausrollen, ohne dass es jemand bemerkt.

Spektakulär ist das nicht, aber kugelsicher. Ein grobes Werkzeug, sicher, aber eines, dem man seit Jahrzehnten vertraut. „Wir machen das seit über 30 Jahren so“, sagte ein Engineer, und die Runde nickte im Grunde unisono.

Mit NGINX oder HAProxy haben Sie das Kernfeature bereits eingebaut: Health-Checks, Connection Draining und sanfte Übergabe. Ein Kommentator erinnerte sogar daran, dass NGINX Upstreams tauschen kann, ohne Pakete zu verlieren, ganz ohne Tränen und Drama.

Blue-Green-Deployments als klassisches Muster

Wenn Kubernetes-Deploys das moderne Web-Framework für Uptime sind, dann sind Blue-Green-Deployments das HTML 1.0 dieser Technik: einfach, direkt und immer noch bestens wirksam.

Das Playbook sieht so aus:

• Sie deployen die neue Version in die grüne Umgebung.
• Sie halten die blaue Umgebung mit der stabilen Version am Laufen.
• Wenn Grün alle Ihre Checks besteht, schalten Sie den Traffic um.
• Wenn alles schiefgeht, schalten Sie den Traffic zurück zu Blau.

Das ist das Deployment-Äquivalent zum Umschalten der HDMI-Ports an Ihrem Fernseher: wenig Aufwand, hohe Zuverlässigkeit und null Downtime, es sei denn, Sie zählen die Millisekunden, die das Routing zum Aufholen braucht.

Engineers im Thread schwören darauf, und manche prahlen sogar damit, wie schnell sie das können. Eine Person erzählte, sie hätten früher ganze Flotten mit über tausend Servern in unter einer Minute umgeschaltet, einfach durch Austauschen von Symlinks. Apropos...

Symlinks, der UNIX-Trick, der einfach nicht sterben will

Gäbe es eine Hall of Fame für einfache Deployment-Hacks, wäre das First-Ballot-Material.

Vor Containern, vor Orchestrierungsplattformen und vor modernem Config-Management deployten Leute Apps, indem sie einen Symlink namens current aktualisierten, sodass er vom alten Release-Verzeichnis auf das neue zeigte.

Der Ablauf sieht so aus:

1. Neuen Code nach /var/www/releases/version-329320 hochladen
2. Den current-Symlink darauf umbiegen
3. Bei Bedarf den Webserver neu starten (oder sanft neu laden)
4. Mit etwas Koffeinhaltigem feiern

Weil das Aktualisieren eines Symlinks eine atomare Operation ist, passiert der Wechsel buchstäblich sofort. Und zurückrollen? Zeigen Sie current einfach wieder auf das alte Verzeichnis. Sie müssen nichts neu bauen, nichts erneut auf eine Container-Plattform deployen und nicht mit zugedrückten Augen beten, dass nichts kaputtgeht.

Wer dieses Muster heute nutzt, kombiniert es oft mit Tools wie Ansibles deploy_helper, aber spezielles Tooling brauchen Sie nicht. Ein Bash-Skript funktioniert genauso gut, solange Sie hin und wieder alte Releases aufräumen.

DNS ist technisch machbar, praktisch aber chaotisch

Ein paar Engineers gaben zu, DNS für Zero-Downtime-Deploys ausprobiert zu haben. Die Idee ist einfach: eine niedrige TTL setzen, den A-Record auf den neuen Server umbiegen und die Propagierung den Rest erledigen lassen.

In der Praxis funktioniert das so einigermaßen, bis es eben nicht mehr funktioniert. Das Caching-Verhalten ist über ISPs, Firmennetzwerke, Browser und Geräte hinweg unvorhersehbar. Ein Engineer meinte, man könne es machen, „wenn Komplexität ein Anliegen ist“, aber andere meldeten sich schnell mit Horrorgeschichten über DNS-Änderungen, die Minuten, Stunden oder, ja, noch länger dauerten.

Für kleinen Maßstab oder etwas Informelles ist das in Ordnung. DNS als Load Balancer zu nutzen ist aber, als würde man einen Truthahn in der Mikrowelle braten: technisch möglich und erschreckend inkonsistent.

Session Draining als Geheimzutat sanfter Shutdowns

Ob Sie Kubernetes, ein selbstgebautes Skript oder einen Haufen verrosteter Server im Besenschrank verwenden, die goldene Regel für Zero Downtime bleibt dieselbe: Ihre App muss herunterfahren können, ohne Nutzern die Tür vor der Nase zuzuschlagen.

Der Trick besteht darin, auf SIGTERM zu lauschen, das Signal, das Ihrem Prozess sagt, er solle mit dem Herunterfahren beginnen, statt sofort zu sterben. Engineers im Thread haben praktisch von den Dächern geschrien, dass genau hier der Schlüssel zu reibungslosen Deployments liegt.

Die Grundidee:

• Die App empfängt SIGTERM.
• Sie nimmt keine neuen Anfragen mehr an.
• Sie lässt aktive Anfragen fertig laufen.
• Nach einer Karenzzeit killt das System sie, falls sie noch hängt.

Jedes Web-Framework, das etwas taugt, unterstützt das auf die eine oder andere Weise. Ein Engineer sagte, in Go sei es „ein Zweizeiler“, Spring Boot hat es eingebaut, und sogar Python-Frameworks unterstützen es. Wenn Ihre App SIGTERM sauber behandelt, können Sie Updates mit fast jeder Infrastruktur ausrollen.

Cloud-Plattformen bieten Zero Downtime als Service

Falls Sie Managed Services bevorzugen, gibt es gute Nachrichten: Heutzutage hat so ziemlich jede Cloud herausgefunden, wie man Zero-Downtime-Deploys handhabt, ohne dass Sie die Feinheiten der Pod-Eviction verstehen müssen.

Google Cloud Run zieht neue Revisionen hoch und leitet den Traffic schrittweise um. AWS ECS und Fargate machen seit Jahren Rolling Updates mit Load Balancern. Und Azure App Service lässt Sie in Staging-Slots deployen und diese umschalten wie ein Zauberer, der Becher tauscht.

All das basiert auf denselben alten Ideen, die Leute seit Jahrzehnten nutzen: mehrere Instanzen, Load Balancing und Health-Checks.

Docker ohne Kubernetes ist immer noch völlig machbar

Viele Leute im Thread betreiben alles in Docker, sparen sich aber die Mühe mit Kubernetes. Sie nutzen:

• Docker Compose mit manueller Skalierung
• Traefik als Reverse Proxy
• docker-swarm für leichtgewichtige Orchestrierung
• einfache Rolling Updates, ein Container nach dem anderen

Die Idee ist dieselbe wie beim Betrieb mehrerer Server, nur dass jeder „Server“ ein Container ist. Traefik macht es besonders einfach, weil es Traffic nur zu Containern leitet, die sich selbst als gesund melden.

Ein Engineer beschrieb einen Workflow, bei dem CI/CD eine zweite Kopie des App-Images hochfährt, wartet, bis sie gesund ist, Traffic dorthin leitet, den Rest des Dienstes aktualisiert und dann die Staging-Kopie herunterfährt. Das klingt schick, die Grundstruktur ist aber sehr traditionell.

Der kniffligste Teil sind Datenbank-Migrationen

Wenn ein Bösewicht Zero-Downtime-Deployments heimsucht, dann sind es Datenbankänderungen. Neuer Code erwartet neue Spalten oder Tabellen, während alter Code noch läuft, und Sie dürfen keines von beiden kaputtmachen.

Die Antwort aus dem Thread ist derselbe Rat, den man überall von erfahrenen Teams hört: Schreiben Sie Migrationen, die alten Code nicht kaputtmachen.

Das bedeutet üblicherweise:

• neue Spalten hinzufügen statt umzubenennen
• aufhören, in alte Spalten zu schreiben, bevor sie gelöscht werden
• destruktive Änderungen im selben Deploy vermeiden
• das Schema später aufräumen, nachdem alle alten App-Versionen weg sind

Wenn Sie das beherrschen, verschwindet die Hälfte Ihrer Deployment-Angst.

Brauchen Sie also wirklich Kubernetes?

Wenn Sie in globalem Maßstab arbeiten, mit Diensten, die über noch mehr Dienste mit anderen Diensten sprechen, dann sicher, Kubernetes hilft. Und wenn Sie ein großes Team koordinieren, das konsistentes Tooling und Leitplanken braucht, verdient es sich sein Geld absolut.

Betreiben Sie aber ein paar Web-Apps, messen Sie Ihre Flotte in Servern statt in Kontinenten, und wollen Sie etwas, das funktioniert, ohne einen Teil Ihres Lebens YAML zu widmen? Dann liefern die alten Methoden immer noch ab: Load Balancer, zwei Server, Symlinks, Reverse Proxys, SIGTERM, Blue-Green und Health-Checks. Diese Werkzeuge sind einfach, vorhersehbar und bombenfest.

Zero-Downtime-Deployments ohne Kubernetes sind keine verlorene Kunst. Unzählige Teams machen das ganz selbstverständlich, und Engineers betreiben es seit Jahrzehnten ohne viel Aufhebens in der Produktion. Daran wird sich so bald nichts ändern.