Einleitung #
Zero-Downtime-Deployments sind im modernen DevOps-Kontext nicht mehr wegzudenken. Eine der bewährtesten Strategien dafür ist das sogenannte Blue-Green Deployment. Dieser Artikel beschreibt, wie ein Blue-Green Deployment unter Kubernetes umgesetzt werden kann, erläutert die Vor- und Nachteile und führt durch eine beispielhafte Implementierung anhand konkreter YAML-Definitionen.
Funktionsweise #
graph LR
LB[Load Balancer] -->|Active Traffic| Blue[Blue Environment
Production v1.0.0]
LB -.->|No Traffic
Ready for Switch| Green[Green Environment
New Version v2.0.0]
Blue --> P1[Pod 1
version: blue]
Blue --> P2[Pod 2
version: blue]
Blue --> P3[Pod 3
version: blue]
Green --> P4[Pod 4
version: green]
Green --> P5[Pod 5
version: green]
Green --> P6[Pod 6
version: green]
style Blue fill:#4285f4,stroke:#333,stroke-width:2px,color:#fff
style Green fill:#34a853,stroke:#333,stroke-width:2px,color:#fff
style LB fill:#ea4335,stroke:#333,stroke-width:2px,color:#fff
Das Blue-Green Deployment-Konzept basiert auf zwei parallelen, aber unabhängigen Umgebungen: einer aktiven (in diesem Fall “Blue”) und einer vorbereiteten neuen Version (hier: “Green”). Der gesamte Live-Traffic wird über einen Kubernetes-Service gesteuert und auf die aktuell aktive Version geleitet. Die neue Version wird hier in der Green-Umgebung ausgerollt, getestet und kann nach erfolgreicher Validierung durch simples Umschalten des Service-Selectors live genommen werden.
Ausgangslage #
Im ersten Schritt wird ein Deployment namens myapp-blue erstellt. Diese Umgebung repräsentiert die
aktuell produktive Version Ihrer Anwendung.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
- name: myapp
image: myapp:1.0.0
ports:
- containerPort: 80
Das Deployment besteht aus drei Replikaten Ihrer Anwendungsversion 1.0.0, welche mit dem Label version: blue versehen sind. Dieses Label ist entscheidend, da es dem Kubernetes-Service später mitteilt, welche Pods angesprochen werden sollen.
Um myapp-blue zu deployen, wird die Datei blue-deployment.yml gespeichert und über
kubectl apply -f blue-deployment.yml
auf das Kubernetes Cluster angewandt.
Zugriff via Kubernetes-Service #
Um Traffic auf die Blue-Umgebung zu leiten, wird ein Kubernetes-Service definiert. Dieser Service fungiert als Load-Balancer für alle zugeordneten Pods mit dem entsprechenden Label. Wir speichern diese Kofniguration als service.yml
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
version: blue
ports:
- port: 80
targetPort: 80
Hier sehen Sie, dass der Service alle Pods auswählt, die sowohl das Label app: myapp als auch version: blue tragen. Damit wird der gesamte eingehende Traffic zur produktiven Blue-Version geleitet.
Vorbereiten der Green-Umgebung #
Die Green-Umgebung wird parallel zur bestehenden produktiven Umgebung ausgerollt. Sie enthält eine neuere Version Ihrer Anwendung, die zunächst intern getestet werden kann.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: green
template:
metadata:
labels:
app: myapp
version: green
spec:
containers:
- name: myapp
image: myapp:2.0.0
ports:
- containerPort: 80
Die Version 2.0.0 wird in separaten Pods betrieben. Diese Pods erhalten das Label version: green,
wodurch sie zunächst vom Service nicht berücksichtigt werden und somit keinen Live-Traffic empfangen.
Man kann beispielsweise über Port Forwarding oder einen intern erreichbarem Service darauf zugreifen um
die Funktionalität zu gewährleisten.
Die Konfiguration wird in der Datei green-deployment.yml gespeichert und mittels folgendem Befehl ausgerollt:
kubectl apply -f green-deployment.yml
Live-Gang der neuen Version #
Nach erfolgreichen Tests der Green-Umgebung (beispielsweise via temporärem Port-Forwarding oder internen Requests) wird die Umschaltung initiiert. Dies geschieht durch das Aktualisieren des Selectors im Service:
spec:
selector:
app: myapp
version: green
Anschließend wenden Sie die Änderung mit folgendem Befehl an:
kubectl apply -f service.yml
Ab diesem Zeitpunkt wird der komplette Live-Traffic zur neuen Green-Version geleitet, ohne dass es zu Ausfallzeiten kommt.
Rollback im Fehlerfall #
Sollten nach dem Live-Gang der Green-Version Probleme auftreten, ist ein sofortiger Rollback möglich. Dazu wird der Service-Selector wieder auf die Blue-Umgebung gesetzt:
kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp", "version":"blue"}}}'
Da beide Umgebungen parallel betrieben werden, ist der Rollback innerhalb von Sekunden erledigt.
Vorteile #
- Keine Downtime: Die Umschaltung erfolgt sofort und unterbrechungsfrei.
- Einfache Rollbacks: Die vorherige Version bleibt bestehen und ist jederzeit wieder aktivierbar.
- Getrennte Testumgebung: Die neue Version kann produktionsnah, aber ohne externe Erreichbarkeit validiert werden.
- Flexibel kombinierbar: Mit Ingress-Regeln, Feature-Flags oder Traffic-Splitting kann Blue-Green Deployment weiter optimiert werden.
Nachteile #
- Keine eindeutige Produktivumgebung: Bei jedem Release wird die aktive Umgebung zwischen Blue und Green gewechselt. Entweder macht man sich die Mühe die andere Umgebung auch zu updaten oder man muss sich vor dem Release bewusst werden, welches Deployment gerade produktiv ist
- Redundanter Betrieb: Man muss (mindestens zum Zeitpunkt des Schwenks) die doppelte Serverkapazität zur Verfügung stellen um beide Umgebungen zeitgleich zu betrieben.
Fazit #
Blue-Green Deployment mit Kubernetes ist eine erprobte Methode, um Releases sicher, kontrolliert und ohne Downtime durchzuführen. Durch die Trennung von Bereitstellung und Live-Schaltung erhöhen Sie die Ausfallsicherheit und Wartbarkeit Ihrer Infrastruktur erheblich. Die hier gezeigte Umsetzung lässt sich einfach in bestehende CI/CD-Pipelines integrieren und bildet eine solide Grundlage für modernes Deployment-Management.
Für weitergehende Automatisierung können Werkzeuge wie ArgoCD, Flux oder GitOps-basierte Prozesse verwendet werden. Diese erlauben beispielsweise auch das automatisierte Umschalten oder Rollback per Commit in einem Git-Repository.
Bei Fragen oder Anregungen kontaktieren Sie mich gerne über die unten angegebenen Kanäle.
