TL;DR

Progressive Delivery rollt neue Versionen schrittweise aus statt alles auf einmal. Argo Rollouts steuern Canary-Deployments mit konfigurierbaren Traffic-Stufen und automatischem Rollback bei schlechten Metriken. Feature Flags entkoppeln Deployment von Release — Code wird deployed, aber erst per Flag für Nutzer freigeschaltet. Zusammen reduzieren beide Ansätze das Deployment-Risiko drastisch.

Progressive Delivery auf Kubernetes

Ein Standard-Deployment in Kubernetes kennt nur zwei Zustände: alte Version und neue Version. RollingUpdate macht den Übergang weicher, aber wenn die neue Version Fehler hat, trifft es trotzdem alle Pods. Progressive Delivery ändert das grundlegend.

Argo Rollouts installierst du so:

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

# Plugin für kubectl installieren
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

Canary Deployments mit Argo Rollouts

Ein Canary-Deployment schickt zuerst nur einen kleinen Prozentsatz des Traffics an die neue Version. Wenn die Metriken stimmen, wird der Anteil schrittweise erhöht. Bei Problemen: sofortiger Rollback.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 10
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: web-app
  strategy:
    canary:
      canaryService: web-app-canary
      stableService: web-app-stable
      trafficRouting:
        nginx:
          stableIngress: web-app-ingress
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 20
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: web-app-canary
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 80
        - pause: { duration: 5m }
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: registry.example.com/web-app:v2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

Die Steps definieren den Rollout-Plan: 5% Traffic, 5 Minuten warten, auf 20% erhöhen, wieder warten, dann Metriken analysieren. Erst wenn die Analyse positiv ist, geht es weiter auf 50% und schließlich 80%.

Metriken-basierte Auto-Promotion

Das Herzstück von Progressive Delivery ist die automatische Entscheidung: Weiter oder Rollback? Dafür definierst du ein AnalysisTemplate mit Prometheus-Queries.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
  namespace: production
spec:
  args:
    - name: service-name
  metrics:
    - name: success-rate
      interval: 60s
      count: 5
      successCondition: result[0] >= 0.95
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}",
              status=~"2.."
            }[2m])) /
            sum(rate(http_requests_total{
              service="{{args.service-name}}"
            }[2m]))
    - name: p99-latency
      interval: 60s
      count: 5
      successCondition: result[0] <= 500
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_ms_bucket{
                service="{{args.service-name}}"
              }[2m])) by (le)
            )

Zwei Metriken werden geprüft: Die Success-Rate muss über 95% liegen und die P99-Latenz unter 500ms. Jede Metrik wird fünfmal im Abstand von 60 Sekunden gemessen. Zwei Fehlschläge sind erlaubt, beim dritten rollt Argo automatisch zurück.

Den Status überwachst du live:

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

# Manuell promoten (falls pause ohne Duration)
kubectl argo rollouts promote web-app -n production

# Sofortiger Rollback
kubectl argo rollouts abort web-app -n production

Flagger als Alternative

Flagger von Weaveworks verfolgt denselben Ansatz, integriert sich aber direkt mit Service-Mesh-Lösungen wie Istio und Linkerd. Statt eines Rollout-Objekts annotierst du ein normales Deployment:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: web-app
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m

Feature Flags: Deployment von Release trennen

Canary-Deployments steuern, wie viel Traffic die neue Version bekommt. Feature Flags gehen einen Schritt weiter: Der Code ist deployed, aber neue Features sind per Flag deaktiviert. Erst wenn du das Flag aktivierst, sehen Nutzer das Feature.

Tools wie Unleash oder Flagsmith laufen als Self-Hosted-Lösung auf Kubernetes. Im Code prüfst du dann:

from UnleashClient import UnleashClient

client = UnleashClient(
    url="http://unleash.internal:4242/api",
    app_name="web-app"
)
client.initialize_client()

@app.route("/checkout")
def checkout():
    if client.is_enabled("new-checkout-flow",
                         context={"userId": current_user.id}):
        return render_new_checkout()
    return render_old_checkout()

Der Vorteil: Du kannst ein Feature für 1% der Nutzer aktivieren, Feedback sammeln und dann schrittweise hochfahren — unabhängig vom Deployment-Zyklus. Rollback bedeutet nur: Flag ausschalten, kein neues Deployment nötig.

FAQ

Was ist der Unterschied zwischen Canary und Blue-Green?

Blue-Green hält zwei vollständige Environments vor und schaltet den gesamten Traffic auf einmal um. Canary erhöht den Traffic schrittweise. Canary braucht weniger Ressourcen, Blue-Green ermöglicht schnelleres Rollback.

Brauche ich ein Service Mesh für Canary Deployments?

Nein. Argo Rollouts funktioniert mit Nginx Ingress Controller über Header-basiertes Routing. Ein Service Mesh wie Istio bietet feineres Traffic-Splitting, ist aber nicht zwingend nötig.

Wie lange sollte ein Canary-Rollout dauern?

Das hängt vom Traffic-Volumen ab. Du brauchst genug Requests, um statistisch signifikante Metriken zu bekommen. Bei 100 Requests pro Minute reichen 5-10 Minuten pro Stufe. Bei wenig Traffic eher 30 Minuten.

Kann ich Feature Flags und Canary kombinieren?

Ja, und das ist die stärkste Kombination. Canary steuert das Deployment der neuen Version, Feature Flags kontrollieren einzelne Features innerhalb dieser Version. So kannst du Code deployen und Features unabhängig voneinander freischalten.

Nächster Schritt: Starte mit Argo Rollouts und einem einfachen Canary-Deployment mit zwei Stufen (10% und 50%). Füge erst danach AnalysisTemplates hinzu, wenn deine Prometheus-Metriken stabil exportiert werden. Feature Flags kommen als letzter Baustein dazu.