GitOps: ArgoCD + FluxCD, besser zusammen

"ArgoCD oder FluxCD?" ist eine der häufigsten Fragen, die wir von Kunden bekommen, die unsere Managed-Kubernetes-Plattform evaluieren. Unsere Antwort überrascht die meisten: Wir nutzen beides. Auf jedem Cluster.

Das ist keine Unentschlossenheit. Es ist eine bewusste Architekturentscheidung, die ein reales Problem löst: Wie trennt man sauber, was das Plattform-Team verwaltet, von dem, was Applikations-Teams verwalten, auf demselben Cluster, ohne sich gegenseitig in die Quere zu kommen?

Wir betreiben dieses Dual-GitOps-Setup über unsere gesamte Flotte seit 2022. Dieser Beitrag erklärt warum, wie es funktioniert, und warum der Versuch, alles mit einem Tool zu machen, Probleme schafft, die man erst sieht, wenn es zu spät ist.

Das Problem mit einem Tool

Die meisten Organisationen starten mit einem einzelnen GitOps-Tool. Es verwaltet alles: Plattform-Komponenten, Applikations-Deployments, Cluster-Addons, CRDs. Eine ArgoCD-Instanz, ein grosses Repo (oder ein paar Repos), und ein Team, das alles besitzt.

Das funktioniert, bis die Organisation wächst. Dann kommen die Fragen:

• Ihr Plattform-Team muss Cilium upgraden. Ihr Applikations-Team ist mitten im Deploy. Wessen Sync gewinnt?
• Ein Entwickler will sehen, warum sein Deployment hängt. Er öffnet das GitOps-UI und sieht 200 Applikationen, von denen die meisten Plattform-Interna sind, die er nicht anfassen sollte.
• Jemand synct versehentlich eine Plattform-Komponente über das Applikations-UI. Der Observability-Stack geht runter.
• Sie wollen team-scoped Zugriff auf das GitOps-Dashboard geben. Aber die Plattform- und Applikations-Komponenten werden vom selben Tool verwaltet, also wird RBAC schnell kompliziert.

Die Ursache: Plattform-Betrieb und Applikations-Delivery haben fundamental unterschiedliche Anforderungen, Zielgruppen und Änderungsrhythmen. Beides mit einem Tool bedienen zu wollen, erzwingt Kompromisse auf beiden Seiten.

Unsere Architektur: FluxCD für Plattform, ArgoCD für Kunden

Wir teilen die Verantwortlichkeiten sauber auf. Jedes Tool verwaltet eine andere Schicht des Clusters, aus einer anderen Git-Quelle, verantwortet von einem anderen Team.

FluxCD: die Plattform-Schicht

FluxCD verwaltet alles, wofür Natron verantwortlich ist. Das sind die Infrastruktur- und Platform Services, die den Cluster produktionsreif machen:

• Cilium CNI und Network Policies
• cert-manager und TLS-Automatisierung
• Der vollständige Observability-Stack (Prometheus, Grafana, Loki, Alertmanager)
• Velero Backups
• Kyverno Policy Engine
• External Secrets Operator
• Ingress Controller
• Blackbox Exporter

FluxCD reconciled aus unserem internen Git Repository. Kunden sehen dieses Repo nie. Sie müssen es nicht. Wenn wir ein Cilium-Upgrade oder ein Alertmanager-Config-Update pushen, erkennt FluxCD die Änderung und reconciled lautlos. Kein UI, kein manueller Sync, keine Benachrichtigung an den Kunden.

Das ist Absicht. FluxCD ist für Infrastruktur-Automatisierung gebaut. Es ist CLI-nativ, event-driven und braucht kein Web-Interface. Platform Engineers arbeiten über Git und kubectl, nicht über Dashboards. FluxCD passt perfekt zu diesem Modell.

ArgoCD: die Applikations-Schicht

ArgoCD verwaltet alles, was der Kunde deployt. Seine Microservices, APIs, Web-Applikationen, Workers, CronJobs. Jedes Team bekommt ein scoped ArgoCD-Projekt mit RBAC und sieht nur seine eigenen Applikationen.

ArgoCD ist hier das richtige Tool, weil:

• Entwickler brauchen ein UI. Sie wollen Sync-Status sehen, Diffs vor dem Sync anschauen, Rollbacks auslösen. Das Web-Interface von ArgoCD macht das zum Self-Service.
• Teams brauchen Isolation. ArgoCD's AppProject-Modell gibt jedem Team eine scoped Ansicht. Team A kann die Applikationen von Team B weder sehen noch syncen.
• Umgebungs-Promotion braucht Sichtbarkeit. Von Dev zu Staging zu Production zu wechseln ist ein Workflow, der von einem visuellen Diff und manuellen Approval Gates profitiert.

Die Git Repositories des Kunden sind die Source of Truth für ihre Applikationen. Sie besitzen diese Repos, ihre CI-Pipelines pushen dorthin, und ArgoCD synct daraus.

Warum diese Trennung wichtig ist

Das geschichtete Modell erzeugt eine klare Grenze:

Diese Grenze ist nicht nur organisatorisch. Sie ist technisch:

Unterschiedliche Änderungsrhythmen. Plattform-Komponenten ändern sich wöchentlich oder monatlich (Security Patches, Version Upgrades). Applikationen ändern sich täglich oder stündlich. Sie in einer Reconciliation-Schleife zu mischen bedeutet, dass Plattform-Änderungen Applikations-Deploys blockieren können und umgekehrt.

Unterschiedliche Blast Radii. Eine fehlerhafte Plattform-Änderung (kaputte Cilium-Config) betrifft jeden Workload auf dem Cluster. Eine fehlerhafte Applikations-Änderung betrifft ein Team. Diese brauchen unterschiedliche Rollback-Strategien, unterschiedliche Test-Ansätze und unterschiedliche Approval Gates.

Unterschiedliche Zugriffsmodelle. Plattform-Änderungen gehen durch Natrons internes Review. Applikations-Änderungen gehen durch den PR-Prozess des Kunden. Unterschiedliche Repos, unterschiedliche Reviewer, unterschiedliche Merge-Policies. Ein Tool kann beides nicht durchsetzen, ohne übermässig komplex zu werden.

Unterschiedliche Fehlermodi. Wenn FluxCD ausfällt, stoppen Plattform-Komponenten die Reconciliation, aber Applikationen laufen weiter. Wenn ArgoCD ausfällt, stoppen Applikationen das Syncen, aber die Plattform bleibt gesund. Kein Ausfall betrifft beide Schichten.

Wie es in der Praxis funktioniert

Szenario 1: Natron upgradet Prometheus. Wir aktualisieren die HelmRelease-Version in unserem Plattform-Repo. FluxCD erkennt die Änderung innerhalb von 60 Sekunden. Es führt helm upgrade mit der neuen Chart-Version aus. Prometheus startet neu ohne Kunden-Impact. Der Kunde sieht keine Benachrichtigung, muss nichts genehmigen und weiss nicht einmal, dass es passiert ist. Seine Grafana-Dashboards funktionieren weiter.

Szenario 2: Der Kunde deployt eine neue Version seiner API. Der Entwickler merged einen PR, der den Image-Tag in seinem Deployment-Manifest aktualisiert. ArgoCD erkennt die Änderung und zeigt sie im UI als "OutOfSync". Der Entwickler klickt "Sync" (oder Auto-Sync ist aktiviert), und ArgoCD rollt die neue Version aus. Wenn Health Checks fehlschlagen, sieht der Entwickler es sofort im ArgoCD-Dashboard und kann mit einem Klick rollbacken.

Szenario 3: Natron deployt Kyverno Policies, der Kunde deployt einen neuen Service. Beides passiert gleichzeitig. FluxCD reconciled die neuen Kyverno Policies. ArgoCD synct den neuen Service. Der neue Service unterliegt sofort den neuen Policies. Wenn der Service eine Policy verletzt, wird die Admission verweigert und der Entwickler sieht den Fehler im Sync-Status von ArgoCD. Die Feedback-Schleife ist sofort.

Warum nicht nur ArgoCD für alles?

Diese Frage bekommen wir oft. ArgoCD ist beliebt, hat ein tolles UI und kann technisch gesehen Plattform-Komponenten verwalten. Wir haben das 2021 versucht. Hier ist, was schiefgelaufen ist:

RBAC-Explosion. Um Kunden Zugriff auf ihre Applikationen zu geben, ohne Plattform-Interna preiszugeben, mussten wir komplexe AppProject-Konfigurationen mit Resource Whitelists, Namespace-Einschränkungen und Source-Repo-Filtern erstellen. Jede neue Plattform-Komponente brauchte RBAC-Updates. Es war fragil.

Versehentliche Plattform-Syncs. Ein Entwickler mit "Sync All"-Berechtigungen löste einen Sync auf einer Plattform-Applikation aus, die absichtlich out of sync war (wir testeten ein Canary Upgrade). Der Observability-Stack wurde auf die vorherige Version zurückgerollt, mitten in einer Untersuchung.

Upgrade-Kopplung. ArgoCD selbst ist eine Plattform-Komponente. Wenn wir ArgoCD upgraden mussten, verwaltete es sich selbst. Selbstreferenzielle Reconciliation ist möglich, aber fügt unnötiges Risiko hinzu. Mit FluxCD, das ArgoCD verwaltet, ist der Upgrade-Pfad sauber: FluxCD upgradet ArgoCD, ArgoCD verwaltet weiterhin Applikationen.

UI-Rauschen. 150+ ArgoCD-Applikationen, von denen 80% Plattform-Interna sind, die der Kunde nie sehen sollte. Filtern und Scoping halfen, aber die kognitive Last war real.

Warum nicht nur FluxCD für alles?

Auch eine faire Frage. FluxCD kann Applikations-Deployments über Kustomizations und HelmReleases verwalten. Wir haben es erwogen.

Kein Web-UI. Entwickler, die gewohnt sind, "Deploy" zu klicken oder einen Sync-Diff im Browser anzuschauen, können das mit FluxCD nicht. Für Platform Engineers ist CLI-only in Ordnung. Für Applikations-Entwickler über mehrere Teams hinweg ist es eine Hürde.

Kein eingebautes RBAC-Dashboard. FluxCD's Multi-Tenancy ist namespace-basiert, was für Isolation funktioniert. Aber es gibt Teams keine Self-Service-Ansicht ihrer Deployments. Man müsste ein Custom UI bauen oder Weave GitOps nutzen, was im Grunde eine UI-Schicht zurückbringt.

Der Applikations-Lifecycle ist anders. Entwickler wollen Deployment-History sehen, Revisionen vergleichen, manuelle Syncs für Hotfixes auslösen und Logs von fehlgeschlagenen Syncs ansehen. ArgoCD hat das out of the box. Das auf FluxCD aufzubauen wäre, ArgoCD neu zu erfinden.

Der Vergleich

Die Tools sind in unserer Architektur keine Konkurrenten. Sie bedienen unterschiedliche Zielgruppen mit unterschiedlichen Bedürfnissen. FluxCD ist der stille Operator. ArgoCD ist das entwicklerorientierte Dashboard.

Wie wir das aufsetzen

Auf jedem Managed Cluster sieht das Bootstrap so aus:

1. FluxCD wird zuerst installiert. Es bootstrappt aus unserem internen Plattform-Git-Repo. Alle Platform Services sind als FluxCD Kustomizations und HelmReleases definiert.
2. ArgoCD ist einer dieser Platform Services. FluxCD installiert und verwaltet ArgoCD. Das heisst, ArgoCD-Versionen, Konfigurationen und RBAC sind versionskontrolliert in unserem Plattform-Repo.
3. ArgoCD verbindet sich mit Kunden-Repos. Wir erstellen AppProjects, die auf die Namespaces und Repos jedes Teams beschränkt sind. Die CI/CD-Pipeline des Kunden pusht Manifeste in ihr Repo, und ArgoCD synct sie.

Wenn ArgoCD ein Upgrade braucht, aktualisieren wir das HelmRelease im Plattform-Repo, und FluxCD übernimmt. Wenn FluxCD ein Upgrade braucht, aktualisieren wir die FluxCD-Manifeste (FluxCD kann seine eigenen Komponenten selbst verwalten).

Die zwei Tools verwalten nie dieselben Ressourcen. FluxCD besitzt flux-system, monitoring, cert-manager, kyverno und ähnliche Namespaces. ArgoCD besitzt Kunden-Applikations-Namespaces. Kyverno Policies erzwingen diese Grenze.

Mehr erfahren

Diese GitOps-Architektur ist Teil unserer breiteren Managed-Kubernetes-Plattform. Für Multi-Tenant-Setups sehen Sie, wie wir ArgoCD und Helm für das Tenant Onboarding nutzen.

Wenn Sie auf die oben beschriebenen Probleme stossen, oder über Ihre GitOps-Strategie für eine wachsende Plattform nachdenken, vereinbaren Sie einen Termin. Wir gehen Ihr aktuelles Setup durch und schauen, wo die Grenzen sein sollten.