Argo CD vs. Flux: GitOps-Entscheidung für Platform-Teams

GitOps ist in Platform-Interviews längst kein Nice-to-have mehr. Aber Vorsicht: Ein einfaches „Wir nutzen Argo” wird als Antwort nicht reichen. Gefragt ist vielmehr: Warum passt dieses Tool zu eurer Organisation? Wer bedient es im Alltag? Und ganz wichtig: Welche Trade-offs nehmt ihr dafür in Kauf?

Sowohl Argo CD als auch Flux CD sind extrem reife Projekte — beide sind CNCF-Graduated, production-ready und laufen weltweit in tausenden Clustern. Die Frage ist also nicht, welches Tool „besser” ist. Der Unterschied liegt im Betriebsmodell, in der Developer UX und darin, wie gut sie Multi-Tenancy abbilden.

Argo CD — wenn UI und Fleet Management zählen

Argo CD hat sich in vielen Enterprises als Standard etabliert, und das hat einen guten Grund: die UI. Für viele App-Teams ist das Web-Interface der perfekte Einstieg. Sie sehen auf einen Blick den Sync-Status, die Diffs und die Health ihrer Apps, ohne jemals kubectl anfassen zu müssen.

Unter der Haube besteht Argo CD aus mehreren Komponenten: dem API-Server (UI und CLI), dem Repo-Server (rendert Manifeste aus Git, Helm oder Kustomize), dem Application-Controller (vergleicht Soll- und Ist-Zustand und synct), dazu Redis als Cache und optional Dex für SSO. Das ist mehr Betriebsfläche als bei Flux — aber jede Komponente skaliert einzeln, was bei großen Installationen hilft.

Multi-Tenancy läuft über AppProjects: Du definierst pro Team, aus welchen Repos deployed werden darf, in welche Ziel-Namespaces und welche Ressourcen-Typen erlaubt sind. Kombiniert mit SSO-Gruppen aus dem Identity Provider hast du ein sauberes Self-Service-Modell, ohne dass Teams Cluster-Admin brauchen.

Wenn du eine Flotte an Clustern verwaltest, sind ApplicationSets unschlagbar. Ein Cluster-Generator erzeugt aus einem Template automatisch eine Application pro registriertem Cluster:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    spec:
      source:
        repoURL: https://git.example.com/platform/base-services
        targetRevision: main
        path: "overlays/{{name}}"
      destination:
        server: "{{server}}"

Brauchst du Rollout-Reihenfolgen (Datenbank-Migration vor Backend), helfen Sync Waves über die Annotation argocd.argoproj.io/sync-wave. Wie das in einem Multi-Cluster-Setup konkret aussieht, haben wir in ApplicationSets für Multi-Cluster ausführlicher beschrieben.

Der Preis: mehr Komponenten, die überwacht werden wollen, und eine UI, die falsche Sicherheit vorgaukeln kann. Sobald Teams anfangen, in der Oberfläche manuell zu syncen oder Auto-Sync zu deaktivieren, ist Git plötzlich nicht mehr die alleinige Source of Truth — und genau dann driftet die Realität von dem ab, was im Repo steht.

Flux — wenn alles CRD und Git bleiben soll

Flux verfolgt einen anderen Ansatz: Es ist eine Sammlung spezialisierter Controller statt einer Plattform mit UI. Der Source-Controller zieht Git-Repos, Helm-Repositories oder OCI-Artefakte und stellt sie als Artefakt bereit. Kustomize-Controller und Helm-Controller wenden sie an. Dazu kommen Notification-Controller (Alerts nach Slack, Webhooks von Git-Providern) und die Image-Automation-Controller, die neue Image-Tags erkennen und direkt Commits ins Repo schreiben — ein Feature, das Argo CD nur über das separate Projekt Argo CD Image Updater abdeckt.

Abhängigkeiten modellierst du mit dependsOn zwischen Kustomizations: erst CRDs und Operatoren, dann die Workloads, die sie brauchen. Für Multi-Tenancy gibt es einen durchdachten Mechanismus: Flux-Objekte können mit serviceAccountName unter einer Team-Identität laufen, und mit der Controller-Option --no-cross-namespace-refs verhinderst du, dass Tenant A auf Sources von Tenant B zeigt. Das Setup dafür haben wir in Flux Bootstrap für Multi-Tenancy durchgespielt.

Der größte Unterschied bleibt: keine eingebaute First-Class-UI. Wer Status sehen will, nutzt flux get kustomizations, baut sich ein Grafana-Dashboard auf Basis der Controller-Metriken oder hängt ein Developer Portal davor. Für Platform-Teams, die ohnehin tief in der Materie stecken, ist das oft völlig in Ordnung — für vierzig App-Teams mit gemischter Kubernetes-Reife eher nicht.

Entscheiden ohne Dogma

Wenn du die Entscheidung treffen (oder im Interview erklären) musst, helfen dir diese Fragen:

• Wie viele Teams habt ihr, und wie viel Self-Service erwartet ihr?
• Brauchen die App-Teams zwingend ein visuelles Interface, oder steht da sowieso ein Portal wie Backstage davor?
• Habt ihr Multi-Cluster-Umgebungen, die nach ApplicationSets rufen?
• Wer übernimmt On-Call für den GitOps-Controller — und wie viele Komponenten will diese Person betreiben?

Hybrid-Setups gibt es durchaus: Management-Cluster mit Flux, Argo CD als Service für die Tenant-Cluster der App-Teams. Das ist legitim, solange es dokumentiert und begründet ist. Wirklich schlimm ist nur, wenn fünf verschiedene Deploy-Wege parallel laufen und es keinen erkennbaren Golden Path gibt.

Und beim Thema Secrets gilt für beide: Sie gehören niemals unverschlüsselt in Git. Ob ihr External Secrets Operator, Sealed Secrets oder SOPS nutzt, ist eure Entscheidung — die Trade-offs haben wir in External Secrets vs. Sealed Secrets verglichen. Flux hat hier einen kleinen Heimvorteil: SOPS-Entschlüsselung ist direkt im Kustomize-Controller eingebaut, bei Argo CD brauchst du dafür Plugins.

Wie du im Interview punktest

Bitte sag niemals „Argo ist besser als Flux”. Die richtige Antwort ist immer: Anforderung → Tool-Wahl → Trade-off.

Wenn du ein konkretes Szenario skizzierst („Wir haben 40 Teams mit extrem unterschiedlicher Reife, deshalb brauchen wir die UI und AppProjects von Argo, nehmen aber den Betrieb von fünf Komponenten in Kauf”), machst du deine Antwort glaubwürdig. Noch stärker wird sie, wenn du einen Failure Mode nennst: manuelle Syncs in der UI, die Drift erzeugen, oder ein Flux-Setup ohne Tenant-Isolation, bei dem jedes Team cluster-weit deployen konnte.

Du willst tiefer einsteigen? Dann schau dir die Lernpfade zu Argo CD und Flux an.