Warum Sie Flux für pull-basiertes GitOps meiden sollten. Push-basiertes GitOps mit einer CICD-Pipeline ist die bessere Option – die beste Wahl bleibt jedoch ArgoCD.
ArgoCD ist die bessere Wahl für pull-basiertes GitOps
Wer tief in Kubernetes eintaucht, erkennt früher oder später den Wert von GitOps. Und schon stellt sich die Frage nach der Best Practice: ArgoCD oder FluxCD v2? Gibt es weitere Optionen? Wenn Ihnen das bekannt vorkommt, sind Sie hier richtig.
In diesem Artikel erkläre ich, warum Sie Flux meiden sollten und warum ArgoCD die beste Wahl ist, wenn Sie pull-basiertes GitOps umsetzen wollen. Eine weitere Option, die einen Blick wert ist: push-basiertes GitOps mit einer CICD-Pipeline.
Was wollten wir mit GitOps eigentlich erreichen?
Zunächst einmal ist GitOps eine gute Antwort auf ein Problem, das eine frühere Lösung erst geschaffen hat: Infrastructure as Code (IaC) ermöglicht reproduzierbare Deployments, und eine Single Source of Truth hält große Teams synchron – bei minimalem Kommunikationsaufwand. Die Krux: Diese Vorteile von IaC funktionieren nur, solange der Live-Zustand Ihrer Infrastruktur dem in Git definierten Soll-Zustand entspricht. GitOps löst genau dieses neue Problem der Konfigurationsdrift – die Realität wird kontinuierlich mit Git abgeglichen.
Setzen Sie GitOps gegen Konfigurationsdrift ein, fällt es zudem leichter, dem Least-Privilege-Prinzip zu folgen und die rollenbasierte Zugriffskontrolle (RBAC) zu vereinfachen. Statt Personen einen Read-only-kubectl-Zugriff zu erteilen, genügt ein Read-only-Zugriff auf das Git-Repository. Direkter kubectl-Zugriff lässt sich auf ein Minimum reduzieren, indem RBAC stattdessen für GitOps-Service-Accounts und Git-Repositories greift.
Außerdem erbt GitOps die Sicherheitskontrollen von Git. Wer Peer-reviewte Merges vorschreibt, erzwingt damit auch Peer-reviewte Deployments. Die Git-History wird zum Audit-Trail: Wer hat was geändert, wann ist die Änderung passiert und wer hat sie freigegeben?
Warum ich für pull-basiertes GitOps ArgoCD statt FluxCD empfehle
Die kurze Antwort: ArgoCD ist deutlich ausgereifter und bietet im Vergleich zu Flux v2 die klar bessere User Experience.
Erstens: Wenn Sie mit Argo eine fehlerhafte Konfiguration pushen, melden Sie sich per SSO an einer GUI an, sehen sofort, dass und wo ein Fehler aufgetreten ist, und bekommen obendrein eine aussagekräftige Fehlermeldung. Bei Flux ist es dagegen schon eine Herausforderung, einen Fehler überhaupt zu erkennen. Damit die Fehlermeldung erscheint, müssen Sie den richtigen Befehl mit dem richtigen CLI-Tool gegen das richtige Objekt im richtigen Namespace absetzen. Manche Fehler tauchen über kubectl auf, andere nur über fluxctl.
Zweitens: Nur ArgoCD beherrscht echtes pull-basiertes GitOps und liefert damit die oben genannten Vorteile. Mit Argo lösen Sie Probleme ohne kubectl-Zugriff. Sie pushen eine Änderung nach Git, Argo gleicht das Live-Cluster fortlaufend mit Git ab und gibt Feedback in der GUI.
Mit Flux geht das nicht ohne kubectl-Zugriff. Nehmen wir an, Sie haben die Zeit investiert, perfekte Logging-Pipelines mit Alerts aufzusetzen, damit Fehler überhaupt sichtbar werden. Flux nutzt keine KISS-konforme Endlos-Reconciliation-Schleife wie Argo, sondern eine fragile, eventbasierte Reconciliation-Schleife, die häufig in einem fehlerhaften Zustand hängen bleibt (besonders oft mit Helm).
In einem früheren Job habe ich Hunderte von Leuten in GitOps mit Flux geschult. Bei jeder dieser Schulungen blieb Flux bei mindestens 5 von 20 Teilnehmenden "stuck". Die Reconciliation stoppt, bis der fehlerhafte Zustand behoben ist. Änderungen am Git-Repository werden vorübergehend ignoriert – manuelles Eingreifen wird zur Pflicht.
Beheben lässt sich das nur über mehrere fluxctl-Befehle. Hinzu kommt: fluxctl hängt von kubectl ab, und weil der Zustand aktiv korrigiert werden muss, reicht ein RO-Zugriff nicht. Ein typisches Beispiel sind "install retries exhausted"-Fehler. Selbst wenn Sie das Problem in Git längst behoben haben, bringt das nichts, weil Flux nach "erschöpften" Retries einfach aufgegeben hat. Es braucht mehrere fluxctl-Befehle, um ein Redeploy zu erzwingen. Sie können die Default-Konfiguration zwar auf retries = -1 (unendlich) setzen, doch das löst das Problem nicht – es führt nur dazu, dass Flux seltener stuck ist. Flux versucht, Deployment-Logik nur dann auszuführen, wenn es Änderungen erkennt. In Edge Cases scheitert die Reconciliation, weil eine Helm-bezogene Änderung nicht erkannt wurde.
Gibt es Edge Cases, in denen Flux besser ist als Argo?
ArgoCD verzichtet bewusst auf einige selten genutzte, erweiterte Funktionen von Helm. Stattdessen liegt der Fokus auf felsenfester Stabilität für die häufigsten Anwendungsfälle. Wenn Sie ein sehr fortgeschrittenes Helm-Chart mit Features wie Helm-Hooks einsetzen, unterstützt ArgoCD das möglicherweise nicht. Flux deckt den Funktionsumfang von Helm umfassender ab.
Welche weiteren Optionen gibt es?
In Teams, die über die Umsetzung von GitOps entscheiden, sehe ich häufig folgendes Muster:
ArgoCD vs. FluxCD vs. eine Überrepräsentation weiterer Tools, die dem Operator-Pattern folgen. Ich vermute, dass genau diese Tools in den Suchmaschinen-Treffern zu "GitOps" prominent auftauchen.
Eine Alternative, die leicht übersehen wird: eine generische CICD-Pipeline auf IaC- und Skript-Logik in einem Git-Repository ansetzen. Ich nenne diesen Ansatz push-basiertes GitOps. Ich bin ein Fan davon, weil sich imperative und deklarative Deployment-Logik problemlos kombinieren lassen – ideal für Themen wie Updates mit Breaking Changes. Solche Fälle sind mit einer rein pull-basierten, deklarativen GitOps-Lösung kaum zu lösen.
Fazit
Wer GitOps zum ersten Mal einführt, sollte Flux von der Shortlist streichen. ArgoCD oder eine CICD-Pipeline sind die deutlich besseren Optionen, um GitOps umzusetzen.