▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "circuit board macro" by Steve A Johnson is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

ArgoCD vs. Flux 2026: Die richtige GitOps-Strategie für Kubernetes-Teams

30. Juli 2026 · 4 min · Martin Jochum #GitOps#ArgoCD#Flux#Kubernetes#DevOps#Continuous Delivery

GitOps hat sich in Kubernetes-Umgebungen längst als Standard etabliert. Laut der aktuellen CNCF-Umfrage setzen rund 60 % aller Kubernetes-Cluster auf ArgoCD für Application Delivery – und das neben Flux als zweitem CNCF-Graduierten im GitOps-Bereich. Doch die beiden Werkzeuge unterscheiden sich fundamental in ihrer Architektur und Philosophie, und die Wahl hat weitreichende Konsequenzen für den täglichen Betrieb. Dieser Artikel vergleicht die Ansätze beider Plattformen anhand der wichtigsten Entscheidungskriterien und hilft Teams, die richtige Strategie zu wählen.

Architektur: Applikation vs. Toolkit

Der entscheidende Unterschied liegt im Architekturansatz. ArgoCD ist eine eigenständige Anwendung: Ein API-Server, ein Repository-Server und ein Application-Controller arbeiten zusammen und bieten eine integrierte Web-Oberfläche, eine eigene RBAC und eine zentrale Steuerungsebene. Das UI zeigt auf einen Blick den Ressourcenbaum, Health- und Sync-Status sowie Diffs zwischen Soll- und Ist-Zustand. Für Teams, in denen nicht alle Mitglieder mit kubectl vertraut sind, ist dies ein großer operativer Gewinn – Entwickler können selbstständig deployen, ohne Kubernetes-Details lernen zu müssen.

Flux hingegen ist ein Toolkit aus modularen, spezialisierten Controllern – einem Source-Controller, einem Kustomize-Controller, einem Helm-Controller und weiteren – die jeweils genau eine Aufgabe übernehmen. Es gibt kein zentrales Dashboard; Flux ist darauf ausgelegt, mit dem bestehenden Observability-Stack (Prometheus, Grafana) zu interagieren. Die Steuerung erfolgt über die CLI und YAML-Manifeste. Flux 2.8, erschienen im Februar 2026, hat die Developer Experience weiter verbessert und fordert ArgoCD gerade in diesem Bereich zunehmend heraus.

Diese architektonische Entscheidung hat praktische Konsequenzen: ArgoCD eignet sich besonders für Teams mit gemischten Kenntnisniveaus, die visuelles Feedback und Self-Service-Fähigkeiten schätzen. Flux liegt Teams, die einen schlanken, Git-zentrierten Workflow bevorzugen und die Kubernetes-native Ästhetik schätzen. In der Praxis betreiben einige Organisationen beide Tools parallel – über Plattformen wie Portainer lässt sich eine einheitliche Governance-Schicht darüberlegen.

Multi-Cluster-Management und Mandantenfähigkeit

Beide Tools haben 2026 ausgereifte Mechanismen für Multi-Cluster-Szenarien. ArgoCD setzt auf ein zentrales Steuerungsmodell: Eine Instanz verwaltet viele Cluster über ApplicationSets, die templatisiert für jede Cluster-Kombination Applications erzeugen. Die Web-Oberfläche bietet einen zentralen Überblick über sämtliche Cluster. ArgoCD 3.0, Ende 2025 veröffentlicht, hat die ApplicationSets für Multi-Cluster-Management nochmals verbessert.

Flux folgt einem dezentralen Ansatz: Jeder Cluster hat seine eigene Flux-Installation. Für die Flottenverwaltung kommt das Pattern Cluster API (CAPI) + Flux zum Einsatz: CAPI übernimmt den Lebenszyklus der Cluster, Flux die Konfiguration. Die Verzeichnisstruktur folgt einer klaren Hierarchie aus base/, environments/ und clusters/ mit Kustomize-Overlays – ein Pattern, das sich bei Flotten ab 50 Clustern bewährt hat.

Für die Mandantenfähigkeit (Multi-Tenancy) stellt Flux einen nativen Mechanismus bereit: Jedes Team erhält einen eigenen Service-Account, dessen Namespace mit targetNamespace erzwungen wird. Kyverno-Policies verhindern zusätzlich, dass Tenants ihren Namespace verlassen. ArgoCD löst Multi-Tenancy über Projects mit RBAC und SSO-Integration (OIDC, OAuth2, LDAP, SAML) – ebenfalls ein ausgereifter Ansatz, der sich in Enterprise-Umgebungen bewährt hat.

Progressive Delivery: Rollouts und Canary-Deployments

Keines der beiden Tools liefert Progressive Delivery direkt mit – beide setzen auf Ergänzungskomponenten. ArgoCD nutzt Argo Rollouts, das den Deployment-Controller durch einen Rollout-Resource ersetzt. Damit sind Blue/Green- und Canary-Deployments mit Traffic-Steuerung und Metrik-basierten Rollbacks möglich. Die Konfiguration erfolgt über eine eigene CRD, die das Deployment vollständig ablöst.

Flux integriert Flagger, das bestehende Deployments mit einem Canary-Wrapper umschließt. Die Konfiguration erfolgt deklarativ: Schwellwerte für Fehlerraten (etwa ≥ 99 % Success-Rate) und Antwortzeiten (z. B. P99 unter 500 ms) bestimmen, ob ein neues Release automatisch zurückgerollt wird. Flagger führt dabei standardmäßig Lasttests während des Rollouts durch – ein entscheidender Vorteil für Teams, die Canary-Deployments ohne manuelle Kontrolle betreiben wollen.

Fazit

Die Wahl zwischen ArgoCD und Flux ist 2026 keine Frage von richtig oder falsch, sondern eine Frage der Teamkultur und der operativen Anforderungen. ArgoCD punktet mit Sichtbarkeit, Self-Service und einer zentralen Steuerungsebene – ideal für Teams, die Developer Experience und visuelles Monitoring priorisieren. Flux überzeugt durch Modularität, Leichtgewichtigkeit und die Kubernetes-native Architektur – perfekt für SRE-orientierte Teams, die Automatisierung und dezentrale Kontrolle bevorzugen.

Beide Projekte sind CNCF-graduiert, unterstützen OCI-Artifacts, Multi-Source-Applications und erweiterte Sync-Windows. Wer sich nicht zwischen beiden entscheiden möchte, kann auf Plattformen wie Portainer setzen, die eine konsistente Governance-Schicht über beide Werkzeuge legen – ohne sich auf einen GitOps-Engine festzulegen. Der wichtigste Rat: klein anfangen, einen nicht-kritischen Service mit dem gewählten Tool umstellen, Erfahrungen sammeln und dann skalieren.

Quellen