Argo Rollouts 2026: Progressive Delivery als Standard im GitOps-Stack

📷 "599 - Network connect timeout error" by GirlieMac is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Progressive Delivery ist 2026 kein Nice-to-have mehr, sondern die logische Ergänzung zu GitOps: Wer seinen Kubernetes-Cluster ohnehin deklarativ aus Git heraus betreibt, will Releases nicht mit einem blinden Rolling Update ausrollen, sondern schrittweise, messbar und jederzeit umkehrbar. Argo Rollouts, der Progressive-Delivery-Operator der Argo-Projektfamilie, ist dafür längst der Standard – und das Projekt hat im August 2026 mit v1.10.0 ein neues Haupt-Release bekommen. Dieser Artikel zeigt, was Argo Rollouts kann, wie es in einen Argo-CD-Workflow passt und warum es sich von Alternativen wie Flagger unterscheidet.

Warum Progressive Delivery: Das Deployment reicht nicht mehr

Das klassische Kubernetes-Deployment kennt nur den Rolling Update: neue Pods hoch, alte runter, ohne Pause und ohne Kontrolle über den Traffic-Anteil der neuen Version. Laut Google SRE sind rund 70 Prozent der Ausfälle auf Änderungen an Live-Systemen zurückzuführen – genau deshalb empfehlen die SRE-Prinzipien, Änderungen schrittweise auszurollen, Probleme früh zu erkennen und sicher zurückrollen zu können. Eine Canary-Strategie setzt genau das um: Ein kleiner Teil des Traffics geht zuerst an die neue Version, erst wenn Metriken grün sind, wird der Anteil erhöht. In einer GitOps-Welt, in der Argo CD oder Flux den Soll-Zustand aus Git oder OCI-Registries in den Cluster rekonziliert, ist Progressive Delivery inzwischen die erwartete Standardfunktion – die Frage ist nicht mehr, ob man sie braucht, sondern womit man sie umsetzt.

Was Argo Rollouts anders macht

Argo Rollouts ersetzt das Deployment durch eine eigene Custom Resource, das Rollout. Es unterstützt Canary- und Blue-Green-Strategien und ergänzt das Ganze um Analyse-Schritte: Ein AnalysisTemplate definiert Metrikabfragen, anhand derer der Controller automatisch entscheidet, ob der Rollout fortgesetzt oder abgebrochen wird. Ein kompaktes Beispiel für eine Canary-Strategie:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:1.0.0
          ports:
            - containerPort: 8080
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 5m }

Die Pod-Template-Sektion bleibt identisch zum Deployment – geändert werden nur apiVersion, kind und der strategy-Block. Die Schritte legen fest, welcher Anteil des Traffics wann an die neue Version geht und wo pausiert wird. Ohne Service Mesh verschiebt Argo Rollouts den Traffic über die Pod-Anzahl (bei fünf Replicas und 20 Prozent Gewicht läuft eine Canary-Replica); mit Istio, NGINX Ingress, ALB, Traefik oder Gateway API ist auch echtes Traffic-Splitting möglich.

Automatisierte Entscheidungen per Analyse

Der wichtigste Unterschied zum schlichten Canary ist die Analyse. Über AnalysisTemplate lässt sich beispielsweise die Erfolgsquote von HTTP-Requests überwachen:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
spec:
  metrics:
    - name: success-rate
      interval: 2m
      successCondition: result[0] >= 0.95
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring.svc:9090
          query: |
            sum(rate(http_requests_total{app="myapp",status=~"2.*"}[5m]))
            / sum(rate(http_requests_total{app="myapp"}[5m]))

Unterschreitet die Erfolgsquote den Schwellwert, bricht der Controller den Rollout ab und skaliert den Canary auf null – ohne menschlichen Eingriff. Als Metrik-Quellen unterstützt Argo Rollouts unter anderem Prometheus, Datadog, New Relic, CloudWatch und InfluxDB sowie Kubernetes-Jobs und Web-Hooks. Wer lieber manuell kontrolliert, nutzt unbestimmte Pausen (pause: {}) und promotet per kubectl argo rollouts promote.

V1.10.0 und die Lage 2026

Am 5. August 2026 ist Argo Rollouts v1.10.0 erschienen und damit das aktuelle Haupt-Release; zuvor hatte v1.9.1 als Minor-Release die Sicherheitslücke CVE-2026-35469 geschlossen. Ein Detail, das in der Community für Aufmerksamkeit sorgte: Seit v1.10 sind die Custom Resource Definitions so groß, dass die Installation kubectl apply --server-side erfordert. Auf der ArgoCon diskutiert wird zudem eine RolloutPlugin-CRD, die Progressive Delivery künftig über Deployments hinaus auch auf StatefulSets und DaemonSets ausweiten soll.

Im Vergleich mit Flagger zeigt sich der grundlegende Design-Unterschied der beiden CNCF-Operatoren: Flagger (Flux-Familie, Mitte Juli 2026 in v1.44.0) umhüllt das bestehende Deployment und klont es in eine -primary-Kopie – es ist für einen kopflosen, metrikgetriebenen Betrieb konzipiert, ohne UI und ohne menschliche Bestätigung im Promotion-Pfad. Argo Rollouts geht den umgekehrten Weg: Das Rollout ersetzt das Manifest, arbeitet nativ mit Argo CD (das Rollouts seit Version 2.0 mit eigenen Health Checks kennt), bietet Dashboard und kubectl-Plugin und ist auf Menschen-in-der-Schleife ausgelegt. Beide Ansätze sind produktionsreif – die Wahl hängt davon ab, ob eine Plattform ihre Rollouts selbst steuern will (Flagger) oder ob Teams die Kontrolle über die Schrittleiter behalten sollen (Rollouts).

Fazit

Argo Rollouts ist aus dem GitOps-Stack 2026 nicht mehr wegzudenken: Canary- und Blue-Green-Strategien, automatische Analyse und Abbrüche sowie die enge Integration mit Argo CD machen es zum Werkzeug der Wahl, wenn Releases messbar und sicher ausgerollt werden sollen. Wer bereits auf Argo CD setzt, bekommt mit dem Rollout-Controller eine progressive Delivery direkt aus demselben Ökosystem – inklusive Dashboard, Health Checks und Audit Trail über Git. Mit v1.10.0 ist das Projekt technisch aktuell; spannend bleibt die geplante Ausweitung auf weitere Workload-Typen. Wer heute damit beginnt, sollte allerdings wissen, dass die Installation seit v1.10 Server-Side-Apply voraussetzt – ein kleiner Preis für ein Release-System, das die 70-Prozent-Ausfallstatistik nicht zur eigenen Erfahrung machen muss.