TL;DR

• Blue-Green Deployment betreibt zwei identische Umgebungen parallel: Blue (aktuell live) und Green (neue Version). Der Traffic wird per Kubernetes Service umgeschaltet — das ergibt Zero-Downtime-Releases.
• Rollback in Sekunden: Ein kubectl patch auf dem Service-Service reicht, um den Traffic zurück auf Blue zu schalten. Kein Re-Deploy, kein Warten auf Container-Start.
• Ideal für regulierte Branchen (Banken, Versicherungen, Health) und KMUs, die schnelle Release-Zyklen ohne Ausfallzeiten brauchen.
• Grenzen kennen: Blue-Green verdoppelt die Ressourcen (2x Replicas) und braucht eine Datenbank-Migrationsstrategie — hier hilft der Vergleich mit Canary und Rolling Update bei der Entscheidung.

Kubernetes Blue-Green Deployment: Komplette Anleitung mit YAML

Blue-Green Deployment ist die sicherste Deployment-Strategie in Kubernetes: Zwei identische Umgebungen, ein Service, und der Traffic-Wechsel passiert durch eine einzige Label-Änderung. Dieser Guide zeigt die komplette Implementierung — von den zwei Deployments über den Service bis zum Traffic-Switch und Rollback.

Warum Blue-Green? Das Problem mit klassischen Rollouts

Ein klassisches kubectl rollout restart startet Container nacheinander neu (Rolling Update). Das Problem: Wenn die neue Version einen Fehler hat, sind bereits Nutzer auf der kaputten Version. Der Rollback dauert Minuten und der Fehler ist sichtbar.

Blue-Green löst das grundlegend: Die neue Version (Green) wird komplett parallel gestartet und getestet, bevor auch nur ein Nutzer sie sieht. Der Wechsel passiert atomar über den Service-Selector.

Die komplette YAML-Implementierung

Schritt 1: Das Blue-Deployment (aktuell in Produktion)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
  labels:
    app: my-app
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
        - name: my-app
          image: registry.example.com/my-app:1.2.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Schritt 2: Der Service — das Herzstück des Traffic-Switch

Der Service leitet den Traffic an die Pods mit dem Label version: blue. Genau hier passiert der Wechsel:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue  # ← Hier wird umgeschaltet: blue → green
  ports:
    - port: 80
      targetPort: 8080

Key-Insight: Der Service-Selector ist die einzige Stelle, die beim Blue-Green-Wechsel geändert wird. Alles andere bleibt unverändert.

Schritt 3: Das Green-Deployment (neue Version)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
  labels:
    app: my-app
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
        - name: my-app
          image: registry.example.com/my-app:1.3.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Der Traffic-Switch in der Praxis

1. Green deployen und verifizieren

kubectl apply -f green-deployment.yaml

# Warten bis alle Green-Pods ready sind
kubectl rollout status deployment/my-app-green

# Green direkt testen (ohne Produktions-Traffic!)
kubectl port-forward deployment/my-app-green 8080:8080
curl http://localhost:8080/healthz

Die Green-Umgebung läuft jetzt parallel zur Blue-Umgebung — aber der Service zeigt noch auf Blue. Du kannst Green ausgiebig testen, Smoke-Tests laufen lassen und die Datenbank-Migration prüfen, bevor ein Nutzer betroffen ist.

2. Traffic umschalten (der eigentliche Release)

kubectl patch service my-app --type=merge -p '{"spec":{"selector":{"app":"my-app","version":"green"}}}'

Das ist der komplette Release. In weniger als einer Sekunde gehen alle Requests an die neue Version.

3. Rollback — falls doch etwas schiefgeht

kubectl patch service my-app --type=merge -p '{"spec":{"selector":{"app":"my-app","version":"blue"}}}'

Rollback in Sekunden — ohne Re-Deploy, ohne Warten. Das ist der größte Vorteil gegenüber Rolling Updates, wo ein Rollback einen kompletten Re-Deploy der alten Version bedeutet.

Datenbank-Migration: Die größte Herausforderung

Blue-Green ist bei stateless Anwendungen einfach. Bei stateful Anwendungen (Datenbanken, Message Queues) gibt es ein kritisches Problem: Beide Umgebungen teilen sich meist dieselbe Datenbank.

Drei bewährte Strategien:

Praktische Regel: Bei Schema-Änderungen immer Expand/Contract nutzen — dann ist das Blue-Green-Deployment der App unabhängig vom DB-Status.

Blue-Green vs. Canary vs. Rolling Update

Empfehlung: Blue-Green für kritische Releases (Major-Upgrades, Breaking Changes), Canary für häufige kleine Deployments mit Feature-Flags, Rolling Update als Basis-Default.

Automatisierung mit CI/CD (GitLab CI Beispiel)

deploy-green:
  stage: deploy
  script:
    - kubectl apply -f green-deployment.yaml
    - kubectl rollout status deployment/my-app-green --timeout=300s
    - # Smoke-Tests gegen Green
    - curl -f http://green.internal:8080/healthz

switch-traffic:
  stage: release
  script:
    - kubectl patch service my-app --type=merge -p '{"spec":{"selector":{"version":"green"}}}'
  when: manual  # Menschlicher Gate vor dem Switch

Checkliste für ein sicheres Blue-Green-Deployment

• Green-Deployment hat eigene Labels (version: green)
• Readiness-Probes sind für beide Umgebungen konfiguriert
• Smoke-Tests laufen automatisch gegen Green vor dem Switch
• Datenbank-Migration folgt Expand/Contract
• Monitoring (Prometheus/Grafana) überwacht beide Umgebungen
• Rollback-Dokumentation liegt im Runbook
• Ressourcen-Kapazität für 2x Replicas ist eingeplant
• Nach 24-48h stabiler Green: Blue löschen (kubectl delete deployment my-app-blue)

Häufige Fehler und Lösungen

Fehler 1: Service-Selector wird nicht aktualisiert

Symptom: Traffic geht weiter an Blue. Ursache: Tippfehler im Label oder Patch nicht angewendet. Lösung: kubectl get svc my-app -o yaml prüfen und kubectl describe endpoints my-app — dort siehst du sofort, welche Pods der Service erreicht.

Fehler 2: Readiness-Probe schlägt bei Green fehl

Symptom: Green-Pods starten nie, rollout status hängt. Lösung: kubectl logs deployment/my-app-green --tail=50 und die Probe testen: kubectl port-forward deployment/my-app-green 8080:8080 && curl localhost:8080/healthz.

Fehler 3: Blue wird zu früh gelöscht

Symptom: Rollback nicht mehr möglich. Lösung: Blue erst nach 24-48h stabiler Produktion löschen — niemals am Release-Tag.

FAQ

Was kostet Blue-Green in Kubernetes?

Die doppelten Replicas bedeuten 2x Compute-Kosten während des Release-Fensters. Bei 3 Pods × 2 Umgebungen = 6 Pods statt 3. Für ein 1-2 Stunden Fenster ist das meist vernachlässigbar (wenige Euro bei managed Kubernetes).

Ist Blue-Green bei StatefulSets möglich?

Ja, aber deutlich komplexer. Für Datenbanken auf Kubernetes (StatefulSets) ist die Expand/Contract-Strategie oder ein Managed-DB-Service (z.B. AWS RDS, Azure Database) die bessere Wahl.

Blue-Green oder Canary — was ist besser?

Für schnelles, sicheres Rollback ist Blue-Green besser. Für graduelles Rollout mit Live-Feedback (Feature-Flags, A/B-Tests) ist Canary besser. Die meisten Teams nutzen beides: Canary für kleine Releases, Blue-Green für Major-Upgrades.

Nächste Schritte

Ein Blue-Green-Deployment gehört in jede Deployment-Strategie-Rotation. Passende weiterführende Artikel: Kubernetes Canary Deployment, Kubernetes Service Discovery & DNS und der Kubernetes Zertifizierungs-Guide für den CKA/CKAD-Stoff.