Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·CI/CD

Argo Rollouts

// Direkte Antwort

Wofür braucht man Argo Rollouts?

Argo Rollouts erweitert Kubernetes um Progressive-Delivery-Strategien wie Canary und Blue-Green. Über AnalysisTemplate lassen sich Promotion-Entscheidungen automatisieren — gegen Prometheus, Datadog oder Webhook. Bei Schwellwert-Verletzung erfolgt automatischer Rollback. Im Workshop bauen Sie ein vollständig konfiguriertes Canary-Rollout mit Prometheus-Analyse und Slack-Notification.

Argo Rollouts im Workshop
// Im DetailArgo Rollouts

Argo Rollouts ist ein Kubernetes-Controller, der das Standard-Deployment-Objekt durch eine eigene Rollout-Ressource für Progressive Delivery ersetzt — also für Canary- und Blue-Green-Releases mit automatisierter, metrikbasierter Freigabe. Während ein normales Kubernetes-Deployment im Wesentlichen nur Rolling-Update kann, definiert Argo Rollouts feingranulare Schritte: zunächst zehn Prozent Traffic auf die neue Version, dann eine Wartezeit oder automatische Analyse, dann schrittweise mehr — oder bei Problemen ein sofortiger Rollback.

Der entscheidende Mechanismus ist das AnalysisTemplate. Es definiert messbare Erfolgskriterien, die während des Rollouts automatisch geprüft werden — etwa Fehlerrate und Latenz aus Prometheus, Metriken aus Datadog oder das Ergebnis eines Webhooks. Werden die Schwellwerte verletzt, bricht Argo Rollouts die Promotion ab und rollt zurück, ohne dass ein Mensch eingreifen muss. Das verlagert die Release-Entscheidung von Bauchgefühl zu Daten.

Im Industrieumfeld ist diese automatisierte Sicherheitslinie besonders wertvoll, weil Wartungsfenster knapp und Eingriffe in laufende Produktionssysteme riskant sind. Ein Canary-Rollout, das anhand echter Metriken über Erfolg oder Abbruch entscheidet, reduziert das Risiko, eine fehlerhafte Version flächendeckend auszurollen. Slack- oder Teams-Benachrichtigungen halten das Team über jeden Promotion-Schritt informiert.

Stolpersteine: Argo Rollouts braucht ein Traffic-Management, das die schrittweise Verteilung umsetzen kann — meist ein Service Mesh wie Istio oder ein Ingress-Controller mit Canary-Unterstützung. Außerdem sind die Analyse-Kriterien nur so gut wie die zugrunde liegenden Metriken; ohne saubere Observability laufen automatische Promotion-Entscheidungen ins Leere.

// Beispiele aus der Praxis2 Szenarien
/01

Canary-Rollout mit Prometheus-Analyse

Eine neue Service-Version erhält zunächst zehn Prozent Traffic. Argo Rollouts prüft per AnalysisTemplate Fehlerrate und Latenz gegen Prometheus. Bleiben die Werte im Rahmen, steigt der Anteil schrittweise; bei Überschreitung erfolgt automatischer Rollback.

/02

Blue-Green mit manueller Freigabe vor Promotion

Für ein kritisches Backend wird die neue Version parallel zur alten gestartet und intern getestet. Erst nach manueller Freigabe schaltet Argo Rollouts den produktiven Traffic um — mit der Option, jederzeit zur alten Version zurückzuschalten.

// Häufige FragenFAQ
Brauche ich für Argo Rollouts ein Service Mesh?
Für reine Replica-basierte Canaries nicht zwingend, aber für präzises Traffic-Splitting nach Prozent ist ein Traffic-Provider nötig — etwa Istio, Linkerd, ein Ingress mit Canary-Support oder ein Gateway-API-Provider. Ohne diese Integration ist die Granularität der Verteilung begrenzt.
Wie funktioniert der automatische Rollback?
Während des Rollouts läuft das AnalysisTemplate und prüft definierte Metriken gegen Schwellwerte. Wird ein Schwellwert verletzt, markiert Argo Rollouts den Schritt als fehlgeschlagen und stellt automatisch die vorherige stabile Version wieder her, statt weiter Traffic auf die neue Version zu leiten.
Lässt sich Argo Rollouts mit ArgoCD kombinieren?
Ja, beide stammen aus dem Argo-Projekt und ergänzen sich. ArgoCD synchronisiert die Rollout-Ressource aus Git in den Cluster, Argo Rollouts steuert dann die eigentliche Progressive-Delivery-Strategie. Eine ArgoCD-Erweiterung visualisiert den Rollout-Status zudem direkt in der ArgoCD-UI.
Argo Rollouts vs. Standard-Deployment — wann lohnt der Wechsel?
Ein Standard-Deployment kann nur Rolling-Update ohne Erfolgsprüfung: Es ersetzt alte durch neue Pods und merkt einen Fehler erst, wenn er bereits flächendeckend ausgerollt ist. Argo Rollouts ergänzt Canary- und Blue-Green-Strategien mit AnalysisTemplates, die Metriken automatisch prüfen und bei Schwellwertverletzung selbsttätig zurückrollen. Der Wechsel lohnt sich, sobald Releases in kritische oder produktionsnahe Systeme gehen, bei denen ein fehlerhafter Vollausrollung teuer wäre.
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance