GitOps mit ArgoCD und Flux hat sich als Standardansatz für Continuous Delivery auf Kubernetes etabliert. So nutzen wir bei NWS für den Betrieb der NETWAYS Cloud beispielsweise ArgoCD. Beide Tools sind CNCF Graduated Projekte, verfolgen aber unterschiedliche Philosophien. Die Wahl zwischen ihnen prägt maßgeblich, wie dein Plattform-Team in Zukunft arbeitet. In diesem Artikel vergleichen wir Gemeinsamkeiten und Unterschiede und werfen einen Blick auf Verbreitung und Popularität. Außerdem gehen wir auf unterschiedliche Einsatzszenarien ein und beleuchten mit Gitless GitOps über OCI-Registries einen der spannendsten aktuellen Trends im Ökosystem.
Was ist GitOps überhaupt?
GitOps beschreibt ein Betriebsmodell, bei dem der gewünschte Zustand eines Systems deklarativ in einem Repository (klassischerweise Git) hinterlegt ist. Ein Controller im Kubernetes-Cluster gleicht diesen Soll-Zustand kontinuierlich mit dem Ist-Zustand ab und stellt Abweichungen automatisch wieder her. Dieser Vorgang wird auch Reconciliation genannt. Statt manueller kubectl apply-Befehle oder klassischer Push-Pipelines übernimmt Software innerhalb des Clusters das „Pull“-Prinzip. Das kann ein zentraler Sicherheits- und Auditvorteil gegenüber klassischen CI/CD-Ansätzen sein.
Die beiden bekanntesten Umsetzungen dieses Prinzips auf Kubernetes sind ArgoCD und Flux. Beide sind heute CNCF Graduated – die höchste Reifegradstufe der Cloud Native Computing Foundation.
Gemeinsamkeiten und Unterschiede von ArgoCD und Flux
Die Gemeinsamkeiten der beiden Projekte finden sich vor Allem in ihrem Status innerhalb der CNCF und in ihrer Projektorganisation. Beide sind seit 2022 CNCF Graduated Projekte und werden von einem breiten Spektrum an Endnutzern produktiv genutzt. Beide Projekte sind Kubernetes-nativ und arbeiten mit CustomResourceDefinitions (CRDs) und Controllern. Und beide Projekte sind unter der Apache 2.0-Lizenz lizensiert und vollständig Open Source.
Die Unterschiede finden sich in den Philosophien der beiden Projekte: ArgoCD ist eine zentralisierte, UI-getriebene Anwendung mit eigener Weboberfläche, Role Based Access Control (RBAC) und einem zentralen Server, über den sogenannte Applications als eigene CustomResources verwaltet werden. Das macht ArgoCD besonders für Entwicklerteams zugänglich, die visuelles Feedback und Self-Service schätzen.
Flux hingegen ist eine modulare Sammlung aus unabhängigen Controllern (das sogenannte „GitOps Toolkit“). Es gibt standardmäßig keine graphische Oberfläche, dafür eine engere Verzahnung mit der Kubernetes-API und geringere Ressourcennutzung. Das Projekt Flux Operator bietet mittlerweile unter Anderem eine umfangreiche UI für die Betrachtung von Flux-Deployments.
Aus diesen architektonischen Unterschieden ergeben sich natürlich auch praktische Konsequenzen:
- Skalierung: Bei sehr vielen Applikationen kann ArgoCD an seinem zentralen Repo-Server an Grenzen stoßen. Dieses Problem lässt sich durch Sharding allerdings gut tunen. Flux skaliert linearer: Jeder Controller aus dem GitOps Toolkit verantwortet lediglich seinen eigenen Ressourcentyp.
- Bedienkonzept: UI- und API-basiert (ArgoCD) versus CLI- und YAML-basiert (Flux). Die Grenzen verschwimmen hierbei allerdings mehr und mehr: So bietet ArgoCD die CLI
argocd, und für Flux gibt es mittlerweile ebenfalls eine nutzbare Weboberfläche. - Multi-Tenancy: ArgoCD bietet mit AppProjects ein Isolationskonzept mit eigenem RBAC, um Mandantentrennung umzusetzen. Flux verzichtet bewusst auf eine eigene Autorisierungsschicht und verlässt sich stattdessen auf Kubernetes RBAC. Mandantentrennung erfolgt über ServiceAccounts, Roles, und RoleBindings im Cluster selbst.
Verbreitung und Popularität von ArgoCD und Flux
ArgoCD hat gemäß den CNCF-eigenen Umfragedaten aktuell die größere Reichweite, während Flux vor Allem in Industrien und Umgebungen punkten kann, in denen Ressourcenschonung, Modularität und höhere Sicherheitsanforderungen zusammenkommen.
Auch bei GitHub-Kennzahlen liegt ArgoCD vorn: Es kommt auf deutlich mehr Sterne als Flux (grob in der Größenordnung 24.000+ gegenüber rund 8.000), was allerdings vor allem die Community-Sichtbarkeit und weniger zwangsläufig die tatsächliche Produktionsnutzung widerspiegelt.
Flux hat eine besondere Geschichte: als Ursprungsprojekt von Weaveworks prägte es den Begriff „GitOps“ überhaupt erst mit. Nach der Einstellung von Weaveworks Anfang 2024 übernahmen mehrere große Unternehmen die Unterstützung der Maintainer, sodass das Projekt trotz des Bruchs aktiv und CNCF-getragen blieb. Beide Projekte verzeichnen laut CNCF-Statistiken weiterhin wachsende Contributor-Zahlen und werden in großen, bekannten Produktionsumgebungen eingesetzt.
GitOps mit ArgoCD und Flux: Welches Tool passt wann?
Auch wenn ArgoCD und Flux letztendlich zum gleichen Resultat führen – einer durch GitOps deklarativ verwalteten Umgebung – hängt die passende Wahl vom jeweiligen Kontext ab. Wir haben uns deshalb ein paar gängige Szenarien angeschaut.
Kleine Teams und einfache Setups
Wer schnell in GitOps einsteigen und sofort visuelles Feedback haben möchte, ist mit ArgoCD häufig besser bedient. Die Web-UI senkt die Einstiegshürde erheblich, gerade für Teams ohne tiefe Kubernetes-Erfahrung. Das Deployment-Modell basierend auf einer einzigen CustomResource erlaubt eine schnelle Umsetzung von Proof-of-Concept-Projekten, und du erhältst schnell erste Resultate, die durch die Weboberfläche direkt sichtbar gemacht werden.
Plattform-Engineering und Multi-Cluster-Umgebungen
Bei sehr vielen Clustern (hunderte bis tausende), etwa im Edge- oder IoT-Kontext, spielt Flux seine Stärken aus. Geringer Ressourcenbedarf, keine eingehenden Netzwerkanforderungen und ein Modell, bei dem sich jeder Cluster selbst verwaltet, gehen mit einem dezentralisierten Ansatz Hand in Hand.
Unternehmen mit Compliance- und Auditanforderungen
Hier punktet ArgoCD durch zentrales, eigenes RBAC, SSO-Integration und einer einheitlichen Sicht über Clustergrenzen hinweg. Ein „Single Pane of Glass“, das von Entscheidern gerne gesehen ist und Audits erleichtern kann.
Gleichzeitig überzeugt Flux sicherheitsbewusste Teams gerade dadurch, dass es keinen zusätzlichen, für menschliche Operatoren gedachten Endpunkt einführt und GitOps-Rechte nahtlos in das bestehende Kubernetes-RBAC einbettet.
Kombination mit dem jeweiligen Ökosystem
Rund um die beiden GitOps-Platzhirsche haben sich jeweilige Ökosysteme etabliert, die häufig aufkommende zusätzliche Anforderungen abdecken: Argo Rollouts für Progressive Delivery, Argo Workflows für CI/CD-Pipelines und Argo Events für event-driven Automatisierung sind ebenfalls Teile des Argo-Projekts und ergänzen ArgoCD in vielerlei Hinsicht.
Rund um Flux bieten Flagger (Progressive Delivery), diverse Notification Controller und Terraform-Integrationen gute Erweiterungspunkte.
Beide Tools lassen sich auch kombinieren – etwa um Flux für das Bootstrapping von Cluster- und Infrastrukturkomponenten zu nutzen, während durch ArgoCD ausgerollte Anwendungen in der Web-UI für Entwicklerteams einsehbar und Probleme visualisiert werden. Das parallele Betreiben beider Tools auf denselben Ressourcen bleibt aber die Ausnahme und sollte gut durchdacht sein.
Gitless GitOps via OCI Artefakten: Der aktuelle Trend im Ökosystem
Ein besonders spannender Trend im GitOps-Umfeld ist sogenanntes Gitless GitOps. Der Name ist dabei etwas irreführend – Git bleibt meist weiterhin Teil des Entwicklungsprozesses, verschwindet aber aus dem eigentlichen Auslieferungspfad zum Cluster.
Was steckt dahinter?
Statt Manifeste direkt aus einem Git-Repository zu nutzen, beziehen GitOps-Tools sie aus einer OCI-Registry (Open Container Initiative), derselben Art von Registry, die auch für Container-Images verwendet wird. CI-Pipelines bauen und signieren die Manifeste als OCI-Artefakte und pushen sie in die Registry. Das GitOps-Tool im Cluster überwacht ausschließlich diese Registry und muss keinerlei Git-Zugangsdaten oder Netzwerkzugriff auf Git-Hosting-Systeme mehr besitzen.
Flux unterstützt OCI-Registries als Quelle bereits seit Längerem vollwertig über den Source-Controller mit einer dedizierten CustomResource (OCIRepository). Diese Umsetzung ermöglicht auch Signaturprüfung und Reconciliation direkt aus der Registry.
ArgoCD hat in v3.1 damit begonnen, OCI-Registries als Quelle für Application-CRs zu unterstützen, unter Anderem für Helmcharts und Kustomize-Artefakte. Der Funktionsumfang wird seitdem kontinuierlich ausgebaut und nähert sich den von Flux unterstützten Szenarien an.
Vor- und Nachteile von Gitless GitOps
Wie jeder Prozess bietet Gitless GitOps einige Vor- und Nachteile: Die Auslieferung der Artefakte ist normalerweise schneller, da OCI-Registries für den Umgang mit binären Artefakten optimiert sind. Auch die Unterstützung von Signaturen und Provenance (z.B. über Cosign/Sigstore) ist besser gegeben, was die Supply Chain Security stärkt und Auditoren glücklich macht. Durch den Wegfall von Git als Quelle der auszurollenden Artefakte wird zudem kein Zugang mehr zum eigentlichen Aufbewahrungsort des zugrundeliegenden Codes benötigt.
Als nachteilig auslegen könnten wir den Wegfall der granularen Git-Historie und klassischer Pull-Request-Prozesse im Auslieferungspfad – OCI-Artefakte der auszurollenden Anwendungen müssen zuerst gebaut, optional signiert, und in eine OCI-Registry hochgeladen werden. Hierfür wird außerdem zusätzliches Tooling benötigt, das in den meisten Entwicklerprozessen aber bereits Standard ist (z.B. Docker).
Für Teams mit hohen Security- und Skalierungsanforderungen, z.B. im Bereich Edge-Computing, ist Gitless GitOps über OCI-Artefakte schon heute ein relevanter Baustein der Architektur und kein reines Nischenthema mehr. Generell entwickelt sich das gesamte Ökosystem hin zu einer breiteren Nutzung von OCI-Artefakten, siehe bspw. die Einführung von OCI Volumes in Kubernetes v1.36.
Erweiterbarkeit, Integrationen und Support innerhalb der CNCF Landscape
Beide Projekte sind tief im CNCF-Ökosystem verankert, unterscheiden sich aber in Governance und Erweiterbarkeit:
- ArgoCD wird als Teil des größeren Argo-Projekts (inklusive Argo Workflows, Argo Rollouts, Argo Events) entwickelt und genießt starken kommerziellen Rückhalt, unter anderem durch Intuit, Red Hat und Akuity, gegründet von den ursprünglichen ArgoCD-Machern. Diese kommerzielle Tiefe zeigt sich auch in einem breiten Angebot an Managed-Service- und Enterprise-Support-Optionen.
- Flux wird direkt unter CNCF-Governance weiterentwickelt. Nach dem Aus von Weaveworks im Jahr 2024 übernahmen andere Unternehmen die Finanzierung zentraler Maintainer – ein Beleg dafür, wie belastbar das Open-Source-Modell auch ohne ein einzelnes tragendes Unternehmen sein kann.
Integrationsmöglichkeiten
Beide Tools lassen sich in die typische CNCF-Landschaft einbetten:
- Progressive Delivery über Argo Rollouts bzw. Flagger
- Policy-Engines wie OPA oder Kyverno für Admission Control
- Observability- und Notification-Anbindungen (Slack, Prometheus-Alerts, etc.)
- SSO/RBAC-Integrationen in bestehende Identity-Provider
- Kombination mit Helm, Kustomize und zunehmend auch Crossplane für Infrastructure-as-Code
Wenn du eine zusätzliche Governance-Schicht über beide Tools hinweg benötigst, etwa für zentrales Access-Management über viele Cluster, kannst du auf ergänzende Plattformen setzen, die sich wiederum sowohl auf ArgoCD als auch auf Flux aufsetzen lassen.
ArgoCD oder Flux – wie triffst du die richtige Entscheidung?
GitOps mit ArgoCD und Flux bietet in beiden Fällen ein ausgereiftes, produktionstaugliches Fundament. Die Entscheidung ist selten eine Frage von „besser“ oder „schlechter“, sondern von den Szenarien, in denen du es einsetzen möchtest:
- Wähle ArgoCD, wenn dir eine einheitliche UI, Self-Service für Entwicklerteams und ein breites Integrations-Ökosystem wichtig sind.
- Wähle Flux, wenn du viele, teils ressourcenbeschränkte Cluster verwaltest, GitOps-Rechte nahtlos in dein bestehendes Kubernetes-RBAC einbetten willst oder Wert auf ein besonders schlankes Setup legst.
Egal, wofür du dich entscheidest: Mit Gitless GitOps über OCI-Registries zeichnet sich schon jetzt ab, wohin sich GitOps-Architekturenen bewegen. Artefakt-Signierung, mehr Supply-Chain-Security und weniger direkter Git-Abhängigkeit im Auslieferungspfad werden mehr und mehr zum Thema.
0 Kommentare