ArgoCD vs. Flux: Auswahl eines GitOps-Controllers für openEduSuite
GitOps ist zum Standard-Betriebsmodell für Kubernetes-Plattformen geworden: Der gewünschte Zustand eines Clusters lebt in Git, und ein Controller gleicht den Cluster an diesen Zustand an. Zwei CNCF-graduierte Projekte dominieren diesen Bereich — ArgoCD und Flux CD. Beide sind produktionsreif, beide sind weit verbreitet, und beide können eine souveräne Bildungsplattform betreiben. Sie unterscheiden sich in Struktur, Ergonomie und Betriebsphilosophie. Dieser Artikel vergleicht sie neutral, damit ein Team bewusst und nicht aus Gewohnheit wählt.
Was beide Tools leisten
Im Kern führen ArgoCD und Flux dieselbe Schleife aus:
- Ein Git-Repository (oder ein OCI-Artefakt) auf Änderungen überwachen.
- Die deklarierten Manifeste rendern (Helm, Kustomize oder reines YAML).
- Sie auf einen Kubernetes-Cluster anwenden.
- Drift zwischen gewünschtem und tatsächlichem Zustand erkennen und melden.
Beide unterstützen Helm-Charts, Kustomize-Overlays, reine Manifeste, OCI-Quellen, Webhooks und Polling. Die Unterschiede liegen in Struktur und Betrieb, nicht darin, ob ein Dienst deployed werden kann.
Architektur und mentales Modell
| Aspekt | ArgoCD | Flux CD |
|---|---|---|
| Kernabstraktion | Application-Ressource pro deployter Anwendung |
Zusammensetzbare Kustomization / HelmRelease plus eine Source |
| Komponenten | API-Server, Repo-Server, Application-Controller, Redis, optionales SSO (Dex) | source-controller, kustomize-controller, helm-controller, notification-controller, optionale Image-Controller |
| Benutzeroberfläche | Eingebaute Web-UI und CLI | Nur CLI; optionale Drittanbieter-UIs |
| Multi-Cluster | Hub-and-Spoke: eine Steuerungsebene verwaltet viele Cluster | Ein Controller-Set pro Cluster; Aggregation über externe Werkzeuge |
| Footprint | Schwerer, zentralisiert | Leichter, modular — nur installieren, was benötigt wird |
ArgoCD behandelt eine Anwendung als Verwaltungseinheit und zeigt Gesundheit, Sync-Status und einen Ressourcenbaum in der UI. Flux behandelt Quellen und Reconciler als zusammensetzbare, native Kubernetes-Ressourcen. Teams, die in "Anwendungen" denken, bevorzugen oft ArgoCD; Teams, die in "Kubernetes-Ressourcen" denken, oft Flux.
Reconciliation und Drift-Behandlung
| Funktion | ArgoCD | Flux |
|---|---|---|
| Automatischer Sync | Ja (automated mit Prune und Self-Heal) |
Ja, in einem Reconcile-Intervall |
| Pruning / Garbage Collection | Ja | Ja |
| Drift-Erkennung | Ja, mit Gesundheitsstatus | Ja, mit optionaler Auto-Korrektur |
| Diff-Strategie | Client-seitiger Diff im Repo-Server | Server-side Apply standardmäßig |
| Konfliktbehandlung | Patch / Three-Way-Merge | Feld-Eigentümerschaft über Server-side Apply |
Flux' Einsatz von Server-side Apply ist ein echter Vorteil, wenn mehrere Controller oder Personen dieselben Ressourcen bearbeiten: Feld-Eigentümerschaft wird explizit verfolgt statt stillschweigend überschrieben. ArgoCDs client-seitiger Diff liefert lesbare Vorschauen in der UI, die viele Betreiber für Reviews schätzen.
Paketierung und Templating
Beide Tools decken die gängigen Fälle gut ab:
- Helm: nativ in beiden, inklusive OCI-Registries.
- Kustomize: nativ in beiden.
- Reines YAML: nativ in beiden.
- Jsonnet: nativ in ArgoCD; in Flux über Kustomize verfügbar.
- Eigene Plugins / Transformatoren: von beiden unterstützt, mit unterschiedlichen Erweiterungsmechanismen.
Ein praktischer Unterschied: Flux' Helm-Controller unterstützt valuesFrom, sodass Helm-Werte aus Secrets oder ConfigMaps bezogen werden können. ArgoCD erreicht Ähnliches über Plugins oder externe Secret-Operatoren, was zusätzliche Schritte bedeutet.
Secrets-Verwaltung
Secrets dürfen niemals im Klartext committed werden. Die beiden Tools gehen unterschiedlich vor:
- Flux entschlüsselt SOPS-verschlüsselte Dateien nativ im kustomize-controller und unterstützt age sowie PGP. Das hält die Secret-Behandlung innerhalb der Reconciliation-Schleife ohne zusätzliche Komponenten.
- ArgoCD setzt üblicherweise auf Plugins wie das ArgoCD Vault Plugin oder auf externe Operatoren wie External Secrets Operator und Sealed Secrets. Das funktioniert, fügt aber Komponenten und Konfiguration hinzu.
Beide integrieren sich sauber mit External Secrets Operator und Sealed Secrets. Der Unterschied liegt in der operativen Komplexität: Der SOPS-Pfad bei Flux ist kürzer, das Plugin-Ökosystem von ArgoCD breiter.
Image-Automatisierung
Ein häufiger GitOps-Workflow aktualisiert ein Manifest automatisch, wenn ein neues Container-Image veröffentlicht wird.
- Flux bringt image-reflector- und image-automation-Controller mit, die neue Tags erkennen und die Änderung zurück nach Git committen. Das ist erstklassig und gut dokumentiert.
- ArgoCD bietet ArgoCD Image Updater als separates Projekt. Es funktioniert, ist aber weniger integriert und folgt einem eigenen Release-Zyklus.
Für Teams, die Image-Promotion vollständig innerhalb von GitOps wollen, bietet Flux derzeit das reibungslosere Erlebnis.
Multi-Tenancy und RBAC
| Aspekt | ArgoCD | Flux |
|---|---|---|
| RBAC-Modell | Eingebautes RBAC mit Projekten, Rollen und Policies | Kubernetes-natives RBAC (ServiceAccounts, RoleBindings) |
| SSO | Eingebaut über Dex (OIDC, SAML, LDAP und mehr) | Delegiert an den Identity Provider des Clusters |
| Tenant-Isolation | AppProjects mit Quell- und Zielbeschränkungen | Namespace-scoped Controller; starke Isolation by design |
| Multi-Tenant-Cluster | Gut bei sorgfältiger Projektkonfiguration | Ausgezeichnet — für geteilte Cluster entworfen |
ArgoCDs eingebautes SSO und RBAC-UI reduzieren den Einrichtungsaufwand für Organisationen, die eine Steuerungsebene mit Login wollen. Flux nutzt Kubernetess eigene Mechanismen, was portabler ist und eine zentrale Identity-Komponente vermeidet, aber mehr initiale Verdrahtung erfordert.
Benachrichtigungen und Events
Beide Tools können externe Systeme über Reconciliation-Ergebnisse informieren:
- ArgoCD Notifications ist ein separater Controller mit template-basierten Triggern.
- Flux notification-controller ist Teil des Standard-Toolkits und unterstützt Slack, Teams, Discord, Rocket.Chat, Webhooks sowie Commit-Status bei Git-Providern.
Beide decken die gängigen Ziele ab. Der Controller von Flux ist gleichmäßiger in den Lebenszyklus des Toolkits integriert.
Progressive Delivery
Canary- und Blue-Green-Deployments mit metrikbasiertem Promotion werden von Begleitprojekten umgesetzt:
- Argo Rollouts ist ausgereift und weit verbreitet, mit Analysis-Templates, die Promotion an Metriken koppeln.
- Flagger integriert sich in Flux und unterstützt ähnliche Strategien über mehrere Ingress- und Service-Mesh-Provider.
Argo Rollouts hat derzeit das größere Ökosystem und die größere Community. Flagger ist solide und passt natürlich in eine Flux-Pipeline. Beide können Progressive Delivery liefern; die Wahl folgt oft dem bereits eingesetzten GitOps-Controller.
Beobachtbarkeit und Benutzererlebnis
Hier fühlen sich die beiden Tools am unterschiedlichsten an:
- ArgoCD bietet eine reiche Web-UI: Anwendungsbaum, Live-Diff, Sync-Historie, Ressourcengraph und Audit-Log. Für Betreiber und Stakeholder, die visuelles Feedback bevorzugen, ist das ein großer Vorteil.
- Flux hat keine eingebaute UI. Beobachtbarkeit kommt über CLI, Kubernetes-Events und CRD-Status, mit optionalen Drittanbieter-Dashboards.
ArgoCDs UI senkt die Einstiegshürde für Teams, die Kubernetes neu sind. Flux belohnt Teams, die mit kubectl und CRD-Status vertraut sind.
Leistung und Ressourcenverbrauch
- ArgoCD kann viele Cluster von einer Steuerungsebene aus verwalten, aber die zentralen Komponenten (Redis, Repo-Server, API-Server) verbrauchen mehr Ressourcen und erfordern Sharding-Konfiguration im großen Maßstab.
- Flux betreibt ein kleines Controller-Set pro Cluster und installiert nur die benötigten Komponenten. Der Footprint ist im Allgemeinen leichter, und die Skalierung erfolgt horizontal durch zusätzliche Replikas.
Bei Single-Cluster- oder Wenig-Cluster-Deployments ist der Unterschied gering. Bei großen Flotten kann das Pro-Cluster-Modell von Flux einfacher zu durchdenken sein, während ArgoCDs Hub-and-Spoke-Modell den Betrieb zentralisiert.
Sicherheitslage
- ArgoCD stellt einen zentralen API-Server bereit, der mit Ingress, Authentifizierung und TLS abgesichert werden muss. Der Controller hält typischerweise breite Cluster-Rechte, die aber pro Projekt eingeschränkt werden können.
- Flux ist pull-basiert ohne zentralen, exponierten Server. Jeder Controller läuft mit einem begrenzten Service-Account, und Multi-Tenant-Isolation ist ein Entwurfsziel erster Klasse. Supply-Chain-Funktionen umfassen signierte Commits und cosign-Verifikation für OCI-Quellen.
Ein pull-basiertes Modell reduziert die exponierte Angriffsfläche. Ein zentralisiertes Modell konzentriert die Kontrolle und kann Audits vereinfachen. Beide können mit entsprechender Härtung sicher betrieben werden.
Lernkurve und Betrieb
- ArgoCD ist schneller zu übernehmen: Die UI führt Nutzer durch das Hinzufügen von Repositories, das Erstellen von Anwendungen und das Auslösen von Syncs.
- Flux ist deklarativer und Kubernetes-nativ: Alles ist eine CRD, und die tägliche Arbeit geschieht über YAML und die CLI. Die anfängliche Lernkurve ist steiler, aber das Ergebnis ist vollständig reproduzierbare Konfiguration.
Auch Upgrades unterscheiden sich: ArgoCD aktualisiert eine zentrale Plattform, Flux aktualisiert einzelne Controller, was inkrementell erfolgen kann.
Wann welches wählen
ArgoCD ist eine starke Wahl, wenn:
- Eine visuelle Steuerungsebene für Betreiber oder Stakeholder wichtig ist.
- Eingebautes SSO und RBAC out of the box funktionieren sollen.
- Progressive Delivery mit Argo Rollouts geplant ist.
- Zentralisierte Verwaltung vieler Cluster gewünscht ist.
- Das Team weniger Kubernetes-nativ ist.
Flux ist eine starke Wahl, wenn:
- Ein rein deklarativer, Kubernetes-nativer Workflow bevorzugt wird.
- Native SOPS-Unterstützung und Image-Automatisierung wichtig sind.
- Multi-Tenant-Cluster mit strenger Isolation benötigt werden.
- Ein leichterer, modularer Footprint gewünscht ist.
- Server-side Apply und saubere Konfliktbehandlung wichtig sind.
- Ein pull-basiertes Modell ohne zentralen Server bevorzugt wird.
Beide zusammen nutzen
Die beiden Tools schließen sich nicht gegenseitig aus. Häufige hybride Muster sind:
- Flux für Cluster-Bootstrap und Secret-Verwaltung, ArgoCD für Anwendungsauslieferung mit seiner UI.
- Flux-Image-Automatisierung speist Manifeste, die ArgoCD deployt.
- ArgoCD für eine Umgebung, Flux für eine andere, während einer Migration.
Viele Organisationen betreiben beide während einer Transition und entscheiden sich mit der Zeit auf Basis operativer Erfahrung für eines.
Fazit
Es gibt keinen universellen Sieger. ArgoCD optimiert für Sichtbarkeit und Zugänglichkeit; Flux optimiert für Zusammensetzbarkeit und Kubernetes-native Reinheit. Beide sind CNCF-graduiert, beide sind produktionsbewährt, und beide können eine souveräne Bildungsplattform unterstützen. Die richtige Wahl hängt von Teamfähigkeiten, Sicherheitsanforderungen und davon ab, wie viel der Auslieferungspipeline innerhalb von Kubernetes selbst leben soll.
Call to Action
- Isoliert evaluieren: Einen Test-Cluster mit jedem Controller provisionieren und eine repräsentative Teilmenge von Diensten deployen, bevor man sich festlegt.
- Nach eigenen Kriterien vergleichen: Reconciliation-Geschwindigkeit, Drift-Behandlung, Secret-Workflows und Betreibererlebnis variieren je nach Umgebung.
- Erfahrungen teilen: Den openEduSuite-Community-Kanal
#opendesk-ce-public:matrix.openedusuite.orgnutzen, um GitOps-Ansätze mit anderen Deployern zu diskutieren. - Beitragen: Verbesserungen an Dokumentation, Charts und Deployment-Mustern sind von allen Mitwirkenden willkommen.
GitOps ist eine Praxis, kein Produkt: Der Controller ist ein Werkzeug, und die Disziplin versionkontrollierten, abgeglichenen Zustands ist das Ziel.
