Flux und Argo CD sind die beiden wichtigsten GitOps-Controller für Kubernetes. Beide sind graduierte CNCF-Projekte, beide sind produktionsreif, und beide setzen dieselben vier GitOps-Prinzipien um: deklarativ, versioniert, automatisch gezogen und kontinuierlich abgeglichen. Der Unterschied liegt im Design, und was passt, hängt mehr von deinem Team ab als von Funktionen. Diese Anleitung vergleicht sie, damit du wählen oder entscheiden kannst, beide zu betreiben.

Zwei Design-Philosophien

Argo CD ist anwendungszentriert und wird als ein integriertes System ausgeliefert: ein API-Server, ein Repo-Server, der Manifeste rendert, ein Application Controller und eine Web-Oberfläche. Du definierst eine Application, die einen Git-Pfad auf einen Cluster und Namespace abbildet, und Argo CD erledigt den Rest.

Flux ist ein Werkzeugkasten aus kleinen Controllern mit je einer Aufgabe (Source, Kustomize, Helm, Notification und optionale Image-Automatisierung), die über Custom Resources kommunizieren. Sources und Deployments sind getrennte Objekte, sodass ein GitRepository mehrere Kustomizations speisen kann. Es gibt keine eingebaute UI, und CLI und kubectl sind die Hauptschnittstelle.

Eine nützliche Faustregel: Argo CD passt zu Teams, die sehen und klicken wollen, Flux passt zu Teams, die komponieren und skripten wollen.

Gegenüberstellung

Bereich	Argo CD	Flux
Architektur	Integrierte Komponenten	Unabhängige, kombinierbare Controller
Web-UI	Eingebaut, mit Live-Ressourcenbaum und Ein-Klick-Rollback	Keine eingebaut; CLI, Grafana oder Community-Dashboards
Installation	kubectl apply eines einzelnen Manifests	flux bootstrap, das auch Fluxs Manifeste in Git committet
Selbstverwaltung	Kann sich selbst verwalten, von dir eingerichtet	Bootstrap verwaltet sich standardmäßig selbst aus Git
Sync-Steuerung	Standardmäßig manueller Sync; Automatisierung (Auto-Sync, Prune, Self-Heal) ist Opt-in	Standardmäßig automatisch; Produktion über Git, Tags oder suspend absichern
Multi-Cluster	Erstklassig: eine Instanz registriert und verwaltet viele Cluster	Standardmäßig eine Flux-Installation pro Cluster; Remote-Cluster per kubeconfig möglich
Helm	Rendert Charts als Templates und wendet die Manifeste an	helm-controller führt den echten Helm-Lebenszyklus aus, mit Tests und automatischem Rollback
OCI-Artefakte	Als Sources unterstützt	Erstklassige Sources für Manifeste und Helm-Charts
Image-Updates	Separates Add-on-Projekt	Eingebaute optionale Controller, die Tags in Git committen
Secrets	Externe Plugins oder Operatoren (Vault, External Secrets, SOPS über Plugins)	SOPS-Entschlüsselung im kustomize-controller eingebaut, plus andere Ansätze
Mandantenfähigkeit	Projekte und RBAC-Policies in Argo CD	Namespaces und Service-Account-Impersonation, durchgesetzt von Kubernetes RBAC
SSO	Eingebaut (OIDC, SAML über Dex oder direkt)	Nicht nötig; Zugriff ist Kubernetes RBAC
Benachrichtigungen	Notifications-Engine mit Templates	notification-controller mit Alerts, Providern und Receivern

Wann Argo CD passt

• Entwickler wollen Sync-Status, den Ressourcengraph und Logs ohne kubectl sehen.
• Eine zentrale Instanz soll viele Cluster verwalten, mit schnellem Onboarding neuer Nutzer.
• Du verlässt dich stark auf SSO und ein Self-Service-Portal für Produktteams.
• Dein Team bevorzugt einen expliziten manuellen Sync-Schritt für einige Umgebungen.

Wann Flux passt

• Du willst automatisierte Image-Updates, die in Git committet werden.
• Secrets sollen verschlüsselt in Git liegen, mit minimalem Zusatzwerkzeug.
• Du nutzt Helm stark und willst echte Release-Lebenszyklus-Behandlung, einschließlich automatischem Rollback.
• Du baust eine interne Plattform und bevorzugst kombinierbare Controller und Kubernetes-natives RBAC für Mandanten.
• Du willst, dass jeder Cluster in sich geschlossen ist, mit Zugangsdaten, die ihn nie verlassen.

Skalierung

Beide skalieren auf große Bestände. Argo CD bietet Sharding des Application Controllers und Redis-Clustering für sehr große einzelne Instanzen. Fluxs Controller skalieren unabhängig, und jeder Cluster betreibt seine eigenen, was einen zentralen Engpass vermeidet. Veröffentlichte Zahlen variieren je nach Workload, benchmarke also dein eigenes Setup, statt einer Schlagzeilenzahl zu vertrauen.

Du kannst beide betreiben

Sie sind keine Feinde. Eine gängige Aufteilung ist Argo CD für die Anwendungsauslieferung, wo Entwickler von der UI profitieren, und Flux für Cluster-Add-ons, Infrastruktur und Secrets. Lass die beiden nur nie dieselben Ressourcen verwalten, sonst kämpfen sie darum.

Entscheiden

1. Brauchen Entwickler am ersten Tag eine UI? Beginne mit Argo CD.
2. Brauchst du Image-Automatisierung, eingebaute Secret-Entschlüsselung oder strikte Autonomie pro Cluster? Beginne mit Flux.
3. Immer noch unsicher? Probiere jedes einen Nachmittag lang auf einem Wegwerf-kind-Cluster aus, mit den Anleitungen zur ersten Anwendung in dieser Bibliothek.

Die Migration zwischen beiden ist möglich, weil beide reines YAML, Helm und Kustomize aus Git lesen, aber plane sie bewusst: Sie ist mehr als Dateien umzubenennen. Für die Referenzdetails siehe die Flux-Dokumentation und die Argo-CD-Dokumentation.