Kubernetes Deployment Strategien: Rolling Update, Blue-Green und Canary im Vergleich

Jedes Deployment in Production ist ein kalkuliertes Risiko. Die Wahl der richtigen Deployment-Strategie entscheidet darueber, ob ein Release reibungslos laeuft oder zum Ausfall fuehrt. Kubernetes bietet nativ Rolling Updates -- aber fuer Blue-Green, Canary und A/B Testing brauchen Sie zusaetzliche Werkzeuge.

Dieser Artikel vergleicht alle gaengigen Kubernetes Deployment Strategien mit vollstaendigen YAML-Beispielen, einer Entscheidungsmatrix und konkreten Rollback-Prozeduren.

TL;DR

Rolling Update ist der Kubernetes-Standard: einfach, ressourcenschonend, aber langsamer Rollback bei Fehlern.
Blue-Green ermoeglicht sofortiges Rollback durch Traffic-Switch zwischen zwei identischen Umgebungen -- benoetigt aber doppelte Ressourcen.
Canary leitet nur einen kleinen Teil des Traffics auf die neue Version -- ideal fuer risikoarme Releases.
A/B Testing routet Traffic basierend auf HTTP-Headern oder Cookies -- fuer Feature-Validierung mit echten Nutzern.
Argo Rollouts vereinfacht Canary und Blue-Green mit nativer Kubernetes-Integration und automatischer Analyse.

Uebersicht: Vier Strategien im Vergleich

Kriterium	Rolling Update	Blue-Green	Canary	A/B Testing
Risiko	Mittel	Niedrig	Sehr niedrig	Sehr niedrig
Rollback-Geschwindigkeit	30-60 Sekunden	Sofort (Sekunden)	Sofort (Sekunden)	Sofort (Sekunden)
Ressourcen-Overhead	Minimal (maxSurge)	100% (doppelt)	10-20%	10-20%
Komplexitaet	Niedrig	Mittel	Hoch	Hoch
Kubernetes-nativ	Ja	Manuell	Nein (Tooling noetig)	Nein (Tooling noetig)
Zero-Downtime	Ja	Ja	Ja	Ja
Traffic-Kontrolle	Nein	Alles oder nichts	Prozentual	Header-basiert
Ideal fuer	Standard-Releases	Kritische Services	Riskante Aenderungen	Feature-Validierung

Strategie 1: Rolling Update

Rolling Update ist die Standard-Deployment-Strategie in Kubernetes. Pods werden schrittweise ersetzt -- alte Pods werden heruntergefahren, waehrend neue hochkommen.

Funktionsweise

Kubernetes erstellt neue Pods mit der neuen Version (bis maxSurge)
Sobald ein neuer Pod Ready ist, wird ein alter Pod terminiert
Dieser Prozess wiederholt sich, bis alle Pods die neue Version haben

YAML-Beispiel

# rolling-update-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2          # Max 2 zusaetzliche Pods waehrend Update
      maxUnavailable: 1    # Max 1 Pod darf gleichzeitig fehlen
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
        version: v2.1.0
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
      terminationGracePeriodSeconds: 60
  minReadySeconds: 30        # Pod muss 30s Ready sein bevor naechster ersetzt wird
  revisionHistoryLimit: 10   # 10 alte ReplicaSets fuer Rollback behalten

Wichtige Parameter erklaert

maxSurge: 2 -- waehrend des Updates duerfen maximal 8 Pods laufen (6 + 2). Hoeher = schnelleres Update, mehr Ressourcen.
maxUnavailable: 1 -- mindestens 5 von 6 Pods muessen immer verfuegbar sein. 0 = kein Pod darf fehlen (sicherste Option).
minReadySeconds: 30 -- ein neuer Pod muss 30 Sekunden healthy sein, bevor der naechste alte Pod ersetzt wird. Verhindert, dass ein fehlerhafter Release alle Pods gleichzeitig ersetzt.
revisionHistoryLimit: 10 -- Kubernetes behaelt 10 alte ReplicaSets. Damit ist ein schneller Rollback moeglich.

Rolling Update ausfuehren und ueberwachen

# Deployment aktualisieren
kubectl set image deployment/web-app web-app=registry.example.com/web-app:2.1.0 -n production

# Oder via apply (empfohlen)
kubectl apply -f rolling-update-deployment.yaml

# Rollout-Status live verfolgen
kubectl rollout status deployment/web-app -n production

# Rollout-History anzeigen
kubectl rollout history deployment/web-app -n production

# Rollback auf vorherige Version
kubectl rollout undo deployment/web-app -n production

# Rollback auf spezifische Revision
kubectl rollout undo deployment/web-app -n production --to-revision=3

Vor- und Nachteile

Vorteile:

Kubernetes-nativ, keine zusaetzlichen Tools
Ressourcenschonend
Zero-Downtime bei korrekter Konfiguration

Nachteile:

Waehrend des Updates laufen alte und neue Version gleichzeitig
Rollback dauert 30-60 Sekunden (alle Pods muessen zurueckrollen)
Keine Traffic-Steuerung moeglich

Strategie 2: Blue-Green Deployment

Bei Blue-Green laufen zwei identische Umgebungen parallel. "Blue" ist die aktuelle Production-Version, "Green" die neue. Nach erfolgreichem Test wird der Traffic von Blue auf Green umgeschaltet.

Funktionsweise

Blue Deployment laeuft in Production mit aktivem Service
Green Deployment wird mit neuer Version deployed (ohne Traffic)
Green wird getestet (Smoke Tests, Health Checks)
Service-Selector wird von Blue auf Green umgestellt
Bei Problemen: Selector zurueck auf Blue (sofortiger Rollback)

YAML-Beispiel

# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-blue
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-app
      version: blue
  template:
    metadata:
      labels:
        app: web-app
        version: blue
        release: v2.0.0
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.0.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-green
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-app
      version: green
  template:
    metadata:
      labels:
        app: web-app
        version: green
        release: v2.1.0
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
# service.yaml -- Traffic-Switch ueber Selector
apiVersion: v1
kind: Service
metadata:
  name: web-app
  namespace: production
spec:
  selector:
    app: web-app
    version: blue    # <-- Aendern zu "green" fuer Switch
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Blue-Green Switch durchfuehren

# 1. Green Deployment erstellen
kubectl apply -f green-deployment.yaml

# 2. Warten bis alle Green-Pods Ready sind
kubectl rollout status deployment/web-app-green -n production

# 3. Smoke Tests gegen Green (intern)
kubectl run smoke-test --rm -it --restart=Never --image=curlimages/curl \
  -- curl -s http://web-app-green.production.svc.cluster.local/healthz

# 4. Traffic auf Green umschalten
kubectl patch service web-app -n production \
  -p '{"spec":{"selector":{"version":"green"}}}'

# 5. Verifizieren
kubectl describe service web-app -n production | grep Selector

# 6. Bei Problemen: sofortiger Rollback auf Blue
kubectl patch service web-app -n production \
  -p '{"spec":{"selector":{"version":"blue"}}}'

# 7. Nach stabilem Green: Blue herunterskalieren
kubectl scale deployment web-app-blue -n production --replicas=0

Vor- und Nachteile

Vorteile:

Sofortiger Rollback (unter 1 Sekunde)
Neue Version kann vor dem Switch getestet werden
Kein Mixed-State (entweder komplett alte oder neue Version)

Nachteile:

Doppelter Ressourcenverbrauch waehrend der Uebergangsphase
Datenbankmigrationen muessen rueckwaertskompatibel sein
Manueller Prozess ohne zusaetzliches Tooling

Mehr zu Blue-Green Deployments finden Sie in unserem Artikel Kubernetes Blue-Green Deployment.

Strategie 3: Canary Deployment

Beim Canary Deployment wird die neue Version zunaechst nur fuer einen kleinen Teil des Traffics aktiviert (z.B. 5-10%). Nur wenn die Metriken der Canary-Version stabil sind, wird der Traffic schrittweise erhoeht.

Einfaches Canary mit Kubernetes-Bordmitteln

# canary-deployment.yaml
# Stable: 9 Replicas = 90% Traffic
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-stable
  namespace: production
spec:
  replicas: 9
  selector:
    matchLabels:
      app: web-app
      track: stable
  template:
    metadata:
      labels:
        app: web-app
        track: stable
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
---
# Canary: 1 Replica = 10% Traffic
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-canary
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-app
      track: canary
  template:
    metadata:
      labels:
        app: web-app
        track: canary
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
---
# Service selektiert beide (app: web-app)
apiVersion: v1
kind: Service
metadata:
  name: web-app
  namespace: production
spec:
  selector:
    app: web-app    # Matcht stable UND canary
  ports:
    - port: 80
      targetPort: 8080

Fortgeschritten: Canary mit Argo Rollouts

Argo Rollouts bietet eine deutlich elegantere Loesung mit automatischer Analyse und schrittweisem Traffic-Splitting.

# argo-rollout-canary.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 10
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: web-app
  strategy:
    canary:
      canaryService: web-app-canary
      stableService: web-app-stable
      trafficRouting:
        nginx:
          stableIngress: web-app-ingress
      steps:
        # Phase 1: 5% Traffic fuer 5 Minuten
        - setWeight: 5
        - pause:
            duration: 5m
        # Automatische Analyse nach Phase 1
        - analysis:
            templates:
              - templateName: success-rate-check
            args:
              - name: service-name
                value: web-app-canary
        # Phase 2: 25% Traffic fuer 10 Minuten
        - setWeight: 25
        - pause:
            duration: 10m
        # Zweite Analyse
        - analysis:
            templates:
              - templateName: success-rate-check
            args:
              - name: service-name
                value: web-app-canary
        # Phase 3: 50% Traffic fuer 10 Minuten
        - setWeight: 50
        - pause:
            duration: 10m
        # Phase 4: 100% -- vollstaendiger Rollout
        - setWeight: 100
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
# AnalysisTemplate fuer automatische Canary-Analyse
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
  namespace: production
spec:
  args:
    - name: service-name
  metrics:
    - name: success-rate
      interval: 60s
      count: 5
      successCondition: result[0] >= 0.99
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{service="{{args.service-name}}",code=~"2.."}[2m]))
            /
            sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))
    - name: p99-latency
      interval: 60s
      count: 5
      successCondition: result[0] <= 0.5
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{service="{{args.service-name}}"}[2m])) by (le)
            )

Canary mit Argo Rollouts verwalten

# Argo Rollouts installieren
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# Kubectl Plugin installieren
brew install argoproj/tap/kubectl-argo-rollouts  # macOS
# oder: curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64

# Rollout-Status anzeigen
kubectl argo rollouts get rollout web-app -n production --watch

# Canary manuell promoten (naechster Step)
kubectl argo rollouts promote web-app -n production

# Canary abbrechen und zurueckrollen
kubectl argo rollouts abort web-app -n production

# Dashboard starten (lokal)
kubectl argo rollouts dashboard -n production

Fuer eine detaillierte Anleitung zu Canary Deployments lesen Sie unseren Artikel Kubernetes Canary Deployment.

Strategie 4: A/B Testing

A/B Testing routet Traffic basierend auf HTTP-Headern, Cookies oder anderen Request-Eigenschaften. So koennen Sie neue Features gezielt fuer bestimmte Nutzergruppen aktivieren.

A/B Testing mit Ingress Annotations

# ab-testing-ingress.yaml
# Hauptversion -- Standard-Route
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-main
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/canary: "false"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app-stable
                port:
                  number: 80
---
# A/B Version -- nur fuer Requests mit spezifischem Header
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ab
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Feature-Version"
    nginx.ingress.kubernetes.io/canary-by-header-value: "beta"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app-beta
                port:
                  number: 80

# ab-testing-cookie.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ab-cookie
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "beta-user"
    # Cookie "beta-user=always" -> Route zu Beta
    # Cookie "beta-user=never" -> Route zu Stable
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app-beta
                port:
                  number: 80

A/B Testing testen

# Standard-Version (kein Header)
curl -s https://app.example.com/api/version
# Output: {"version": "2.0.0"}

# Beta-Version (mit Header)
curl -s -H "X-Feature-Version: beta" https://app.example.com/api/version
# Output: {"version": "2.1.0-beta"}

# Beta-Version (mit Cookie)
curl -s -b "beta-user=always" https://app.example.com/api/version
# Output: {"version": "2.1.0-beta"}

Entscheidungsmatrix: Welche Strategie wann?

Verwenden Sie Rolling Update wenn:

Es ein Standard-Release ohne hohes Risiko ist
Die Anwendung kurze Startup-Zeiten hat
Keine exakte Traffic-Kontrolle noetig ist
Ressourcen begrenzt sind

Verwenden Sie Blue-Green wenn:

Ein sofortiger Rollback kritisch ist
Die neue Version vor dem Live-Traffic getestet werden soll
Es sich um einen kritischen Service mit null Fehlertoleranz handelt
Genug Ressourcen fuer doppelte Kapazitaet vorhanden sind

Verwenden Sie Canary wenn:

Das Release-Risiko hoch ist (grosse Aenderungen, neue Abhaengigkeiten)
Sie die Auswirkung auf echtem Traffic messen wollen
Automatische Analyse (Metriken-basiert) gewuenscht ist
Ein schrittweiser Rollout die Sicherheit erhoeht

Verwenden Sie A/B Testing wenn:

Sie Features gezielt fuer Nutzergruppen testen wollen
Geschaeftliche Entscheidungen auf echten Nutzerdaten basieren sollen
Interne Beta-Tester die neue Version vor allen anderen sehen sollen

Rollback-Prozeduren im Detail

Jede Strategie braucht einen klaren Rollback-Plan:

# === Rolling Update Rollback ===
# Vorherige Version wiederherstellen
kubectl rollout undo deployment/web-app -n production
# Auf spezifische Revision
kubectl rollout history deployment/web-app -n production
kubectl rollout undo deployment/web-app --to-revision=5 -n production

# === Blue-Green Rollback ===
# Service-Selector zurueck auf Blue
kubectl patch service web-app -n production \
  -p '{"spec":{"selector":{"version":"blue"}}}'

# === Canary Rollback (Argo Rollouts) ===
kubectl argo rollouts abort web-app -n production
# Oder manuell: Canary-Deployment loeschen
kubectl delete deployment web-app-canary -n production

# === GitOps Rollback (ArgoCD) ===
# Git Revert erstellen und pushen
git revert HEAD
git push origin main
# ArgoCD synchronisiert automatisch

Fuer ausfuehrliche Rollback-Strategien empfehlen wir unseren Artikel Kubernetes Rollback-Strategien.

Best Practices fuer alle Strategien

Readiness Probes sind Pflicht -- ohne sie leitet Kubernetes Traffic an Pods, die noch nicht bereit sind
minReadySeconds setzen -- verhindert zu schnelles Rollout
revisionHistoryLimit erhoehen -- Standard ist 10, fuer kritische Services auf 20 setzen
Deployment-Metriken ueberwachen -- Error Rate, Latenz, CPU/Memory waehrend jedes Rollouts
Rollback immer testen -- ein Rollback, der nie getestet wurde, funktioniert im Ernstfall nicht
Database Migrations entkoppeln -- Schema-Aenderungen muessen unabhaengig vom Deployment funktionieren
Feature Flags nutzen -- Code deployen und Features separat aktivieren

Zum Thema Feature Flags lesen Sie unseren ausfuehrlichen Artikel Kubernetes Feature Flags.

Fazit

Es gibt keine universell beste Deployment-Strategie. Rolling Updates sind der solide Standard fuer die Mehrheit der Deployments. Blue-Green eignet sich fuer kritische Services, bei denen sofortiger Rollback unverzichtbar ist. Canary ist die sicherste Option fuer riskante Aenderungen. A/B Testing ist ein maechtiges Werkzeug fuer Feature-Validierung.

In der Praxis kombinieren die meisten Teams diese Strategien: Rolling Updates fuer Standard-Releases, Canary fuer grosse Feature-Releases und Blue-Green fuer infrastrukturkritische Aenderungen. Tools wie Argo Rollouts machen fortgeschrittene Kubernetes Deployment Strategien zugaenglich, ohne dass Sie ein eigenes Tooling bauen muessen.

Kubernetes Deployment: Rolling, Blue-Green, Canary

Kubernetes Deployment Strategien: Rolling Update, Blue-Green und Canary im Vergleich

TL;DR

Uebersicht: Vier Strategien im Vergleich

Strategie 1: Rolling Update

Funktionsweise

YAML-Beispiel

Wichtige Parameter erklaert

Rolling Update ausfuehren und ueberwachen

Vor- und Nachteile

Strategie 2: Blue-Green Deployment

Funktionsweise

YAML-Beispiel

Blue-Green Switch durchfuehren

Vor- und Nachteile

Strategie 3: Canary Deployment

Einfaches Canary mit Kubernetes-Bordmitteln

Fortgeschritten: Canary mit Argo Rollouts

Canary mit Argo Rollouts verwalten

Strategie 4: A/B Testing

A/B Testing mit Ingress Annotations

A/B Testing testen

Entscheidungsmatrix: Welche Strategie wann?

Verwenden Sie Rolling Update wenn:

Verwenden Sie Blue-Green wenn:

Verwenden Sie Canary wenn:

Verwenden Sie A/B Testing wenn:

Rollback-Prozeduren im Detail

Best Practices fuer alle Strategien

Fazit

Verwandte Artikel

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

Kubernetes Rollback: Blue-Green und Canary erklärt

Progressive Delivery: Canary und Feature Flags

Rolling Updates: Kubernetes-Deployments ohne Ausfall

ArgoCD ApplicationSets: Multi-App Deployment Patterns

Java Spring Boot auf Kubernetes containerisieren

Kubernetes Deployment Strategien: Rolling Update, Blue-Green und Canary im Vergleich

TL;DR

Uebersicht: Vier Strategien im Vergleich

Strategie 1: Rolling Update

Funktionsweise

YAML-Beispiel

Wichtige Parameter erklaert

Rolling Update ausfuehren und ueberwachen

Vor- und Nachteile

Strategie 2: Blue-Green Deployment

Funktionsweise

YAML-Beispiel

Blue-Green Switch durchfuehren

Vor- und Nachteile

Strategie 3: Canary Deployment

Einfaches Canary mit Kubernetes-Bordmitteln

Fortgeschritten: Canary mit Argo Rollouts

Canary mit Argo Rollouts verwalten

Strategie 4: A/B Testing

A/B Testing mit Ingress Annotations

A/B Testing mit Cookie-basiertem Routing

A/B Testing testen

Entscheidungsmatrix: Welche Strategie wann?

Verwenden Sie Rolling Update wenn:

Verwenden Sie Blue-Green wenn:

Verwenden Sie Canary wenn:

Verwenden Sie A/B Testing wenn:

Rollback-Prozeduren im Detail

Best Practices fuer alle Strategien

Fazit

Verwandte Artikel

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

Kubernetes Rollback: Blue-Green und Canary erklärt

Progressive Delivery: Canary und Feature Flags

Rolling Updates: Kubernetes-Deployments ohne Ausfall

ArgoCD ApplicationSets: Multi-App Deployment Patterns

Java Spring Boot auf Kubernetes containerisieren