Argo Rollouts vs Flagger: Progressive Delivery auf Kubernetes mit Canary Deployments und Blue/Green — welches Tool ist die bessere Wahl?

Argo Rollouts vs Flagger: Progressive Delivery auf Kubernetes im Vergleich 2026

Wer Deployments in Kubernetes absichern will, kommt an Progressive Delivery nicht mehr vorbei. Canary-Releases, Blue/Green-Wechsel und A/B-Tests ermöglichen es, neue Versionen schrittweise auszurollen — und bei Problemen sofort zurückzudrehen. Zwei Tools dominieren diesen Bereich: Argo Rollouts und Flagger. Beide lösen dasselbe Problem, tun das aber auf grundlegend verschiedene Weise.

Was ist Progressive Delivery?

Progressive Delivery ist eine Weiterentwicklung von Continuous Delivery: Statt eine neue Version sofort für alle Nutzer zu aktivieren, wird sie zunächst nur einem kleinen Prozentsatz des Traffics gezeigt. Metriken wie Fehlerrate, Latenz oder benutzerdefinierte SLOs entscheiden, ob das Rollout fortgesetzt oder abgebrochen wird. Das reduziert Ausfallrisiken drastisch.

Kubernetes selbst bietet nur rollende Updates an — Progressive Delivery-Strategien müssen von externen Tools implementiert werden.

Argo Rollouts: CRD-basiertes Rollout-Management

Argo Rollouts ersetzt das Standard-Kubernetes-Deployment-Objekt durch eine eigene CRD namens Rollout. Diese CRD unterstützt Canary, Blue/Green und experimentelle Strategien direkt im Spec.

Beispiel: Canary-Rollout

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 5m}
      - setWeight: 60
      - pause: {duration: 10m}
      - setWeight: 100
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: registry.example.com/my-app:v2.0

Der Rollout pausiert nach jedem Schritt und wartet auf eine manuelle Freigabe oder eine automatische Metrik-Analyse. Mit dem Analysis-Template können Prometheus-Metriken abgefragt werden:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.95
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc.cluster.local:9090
        query: |
          sum(rate(http_requests_total{status!~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))

Argo Rollouts bringt ein eigenes Dashboard mit (via kubectl argo rollouts dashboard) und lässt sich nahtlos in ArgoCD integrieren.

Flagger: Service-Mesh-native Progressive Delivery

Flagger verfolgt einen anderen Ansatz: Es modifiziert bestehende Kubernetes-Deployments nicht, sondern nutzt das vorhandene Deployment-Objekt und orchestriert den Traffic über ein Service Mesh oder einen Ingress Controller. Unterstützt werden Istio, Linkerd, Contour, Nginx Ingress, Traefik und weitere.

Canary-Analyse mit Flagger

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

Flagger erstellt automatisch primäre und Canary-Services sowie Traffic-Splits über das Service Mesh. Bei schlechten Metriken rollt es eigenständig zurück — ohne manuelle Eingriffe.

Direkter Vergleich: Argo Rollouts vs Flagger

Merkmal	Argo Rollouts	Flagger
Deployment-Modell	Eigene `Rollout`-CRD	Bestehende Deployments
Traffic-Split	Replica-basiert oder Service Mesh	Service Mesh / Ingress required
Strategien	Canary, Blue/Green, Experiment	Canary, Blue/Green, A/B-Testing
Metriken	Prometheus, Datadog, New Relic, CloudWatch	Prometheus, Datadog, AWS CloudWatch, Graphite
Webhooks	Pre/Post-Analysis, Pause	Pre/Post-Rollout, Confirm
Dashboard	Integriert (kubectl Plugin)	Über Grafana oder externe Tools
Service Mesh	Optional (bessere Traffic-Kontrolle)	Empfohlen (ohne SM nur Replica-Split)
GitOps	Native ArgoCD-Integration	Flux-freundlich
Reifegrad	CNCF incubating, weit verbreitet	CNCF sandbox, aktiv entwickelt

Strategien im Detail

Blue/Green mit Argo Rollouts

Blue/Green-Deployments laufen vollständig getrennt: Die neue Version (Green) läuft parallel zur aktuellen (Blue), Traffic wird erst nach expliziter Bestätigung umgeschaltet.

strategy:
  blueGreen:
    activeService: my-app-active
    previewService: my-app-preview
    autoPromotionEnabled: false
    scaleDownDelaySeconds: 30

A/B-Testing mit Flagger

Flagger ermöglicht Traffic-Split nach HTTP-Header oder Cookie — ideal für Feature-Flags:

analysis:
  iterations: 10
  match:
  - headers:
      x-canary:
        exact: "true"

Wann welches Tool wählen?

Argo Rollouts ist die bessere Wahl, wenn:

Du bereits ArgoCD einsetzt (native Integration)
Du ein einfaches Setup ohne Service Mesh bevorzugst (Replica-basierter Canary)
Du das Rollout-Dashboard und kubectl-Plugin schätzt
Du komplexe, mehrstufige Canary-Strategien mit manuellen Pausierungspunkten brauchst

Flagger eignet sich besser, wenn:

Du Istio oder Linkerd bereits betreibst (maximale Traffic-Kontrolle bis auf 1 %)
Du Flux CD als GitOps-Tool nutzt
Du vollautomatische Rollouts ohne manuelle Eingriffe möchtest
Du A/B-Testing auf Header- oder Cookie-Basis brauchst

Integration mit Observability

Beide Tools nutzen Prometheus als primäre Metrikquelle. Typische Canary-Metriken sind:

HTTP-Erfolgsrate (4xx/5xx vs. 2xx)
P95/P99 Request-Latenz
Fehlerraten pro Business-Prozess (z.B. Checkout-Abbrüche)

Für Produktionsbetrieb empfiehlt sich ein Alerting-Stack (Prometheus Alertmanager) kombiniert mit einem On-Call-System wie Grafana OnCall oder PagerDuty.

Fazit

Argo Rollouts und Flagger sind beide solide Werkzeuge für Progressive Delivery auf Kubernetes — aber mit unterschiedlicher Philosophie. Argo Rollouts ist eigenständiger und schlanker installierbar; Flagger ist tiefer in Service Meshes integriert und ermöglicht feingranularere Traffic-Kontrolle.

Für Teams, die bereits im Argo-Ökosystem arbeiten, ist die Wahl klar: Argo Rollouts. Für Istio- oder Linkerd-Nutzer, die vollautomatische Rollouts bevorzugen, ist Flagger die elegantere Lösung.