ArgoCD vs. Flux CD.
Zentral oder verteilt.

Worin unterscheiden sich ArgoCD und Flux im Kern?

ArgoCD steuert zentral, Flux steuert verteilt. ArgoCD bündelt GitOps in einer Plattform mit API-Server, Web-UI und eigenem Rechtemodell, und eine Installation verwaltet von dort aus viele Cluster. Flux zerlegt dieselbe Aufgabe in einzelne Controller, die in jedem Cluster laufen und sich ihren Stand selbst aus Git holen.

Am deutlichsten wird das, wenn man dieselbe Aufgabe in beiden Tools aufschreibt. Das Beispiel rollt eine MES-Anwendung aus Git auf die Cluster mehrerer Werke aus. ArgoCD braucht dafür ein einziges ApplicationSet: Der Cluster-Generator erzeugt daraus pro registriertem Cluster eine Application mit dem passenden Overlay, und jede erscheint als eigene Kachel in der UI. Flux braucht pro Cluster zwei Ressourcen, ein GitRepository als Quelle und eine Kustomization, die den Pfad abgleicht. Jedes Werk deklariert seinen Stand selbst.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: mes-rollout
spec:
  generators:
    - clusters: {}        # alle registrierten Cluster
  template:
    metadata:
      name: 'mes-{{name}}'
    spec:
      project: production
      source:
        repoURL: https://git.example.com/platform/mes.git
        targetRevision: main
        path: overlays/{{name}}
      destination:
        server: '{{server}}'
        namespace: mes
      syncPolicy:
        automated:
          prune: true
          selfHeal: true   # Drift wird korrigiert

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: mes
  namespace: flux-system
spec:
  interval: 1m
  url: https://git.example.com/platform/mes.git
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: mes-werk-muenchen
  namespace: flux-system
spec:
  interval: 10m           # Reconciliation-Takt
  sourceRef:
    kind: GitRepository
    name: mes
  path: ./overlays/werk-muenchen
  prune: true
  wait: true

Aus diesem Unterschied folgt fast alles Weitere. Eine zentrale Instanz sieht alle Cluster auf einen Blick, braucht dafür aber Zugang zu jedem von ihnen. Verteilte Controller kommen ohne diesen Zugang aus und arbeiten weiter, wenn die Verbindung zur Zentrale abreißt. Für ein Werk mit eigener Netzzone ist das kein Detail, Abschnitt 05 geht darauf ein.

Wann ist ArgoCD, wann Flux die richtige Wahl?

ArgoCD, wenn viele Cluster in einer Oberfläche zusammenlaufen und mehrere Rollen Deployments verfolgen sollen. Flux, wenn ein kleiner, controller-nativer Footprint wichtiger ist als eine gemeinsame Übersicht. Viel falsch machen kann man nicht, beide Tools sind CNCF-graduiert, aktiv gepflegt und in der Industrie produktiv im Einsatz.

Hilfreicher als jede Feature-Liste ist die Frage, wer mit dem Tool arbeitet. Ein Plattform-Team, das ohnehin in Git und kubectl lebt, gewinnt mit Flux Einfachheit. Sobald Ops, QA oder die Qualitätssicherung Deployments nachvollziehen sollen, ohne Zugang zum Cluster zu bekommen, wird die ArgoCD-UI vom Komfort zum organisatorischen Argument. Die drei Profile fassen das zusammen.

AI

Kann man später wechseln oder beide Tools parallel betreiben?

Ja, beides, und mit weniger Aufwand als befürchtet. GitOps trennt die Beschreibung der Anwendung, also Kustomize-Overlays und Helm-Charts, von der Tool-Konfiguration. Bei einem Wechsel bleiben die Manifeste deshalb unverändert in Git liegen, umgezogen wird nur die dünne Steuerschicht darüber.

AI

In Erstgesprächen kommt diese Frage oft noch vor der eigentlichen Tool-Frage: Was, wenn wir uns jetzt falsch entscheiden und in drei Jahren festsitzen? Die ehrliche Antwort lautet, dass Applications Repository für Repository zu Kustomizations werden oder umgekehrt, ohne Big Bang. Teuer wird es nur bei den tool-eigenen Funktionen. ApplicationSets und Sync-Waves haben in Flux kein direktes Gegenstück, dort übernehmen mehrere Kustomizations mit dependsOn die Reihenfolge. Flagger-Canaries müssen zu Argo Rollouts umgebaut werden, und SOPS-Secrets brauchen in ArgoCD eine Zusatzlösung. Wer solche Funktionen intensiv nutzt, plant den Wechsel als eigenes Projekt mit Pilot-Anwendung und nicht als Aufgabe nebenher.

Auch der Parallelbetrieb ist ein etabliertes Muster, dauerhaft oder für die Übergangszeit. Flux gleicht die Plattform-Infrastruktur ab, also Ingress, Cert-Manager und Monitoring, ArgoCD liefert die Anwendungen mit UI für die Fachteams aus. Eine Regel gilt dabei ohne Ausnahme: Nie dürfen beide Tools dieselben Ressourcen verwalten, sonst korrigieren sich zwei Reconciler gegenseitig. In der Praxis trennt man per Namespace oder Repository und schaltet beim ablösenden Tool prune erst ein, wenn die Übergabe abgeschlossen ist.