GitOps: ArgoCD und FluxCD, besser zusammen

"ArgoCD oder FluxCD?" gehört zu den häufigsten Fragen, die uns Kunden stellen, die unsere Managed-Kubernetes-Plattform prüfen. Unsere Antwort: Wir nutzen beides. Auf jedem Cluster.

Das ist eine bewusste Architekturentscheidung. FluxCD verwaltet die Plattform-Schicht. ArgoCD bietet Kunden ein Self-Service-UI für ihre Workloads. Jedes Tool macht das, worin es am besten ist, und sie kommen sich dabei nicht in die Quere.

Wir betreiben dieses Dual-GitOps-Setup auf über 50 Managed-Kubernetes-Clustern seit 2022. Dieser Beitrag erklärt, warum es diese Aufteilung gibt, was FluxCD für den Day-2-Betrieb in unserem Massstab unverzichtbar macht und wie sich die beiden Tools ergänzen.

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

FluxCD: die Plattform-Schicht

FluxCD verwaltet alles, wofür Natron verantwortlich ist: Cilium CNI, cert-manager, den Observability-Stack (Prometheus, Grafana, Loki, Alertmanager), Velero-Backups, Kyverno, External Secrets Operator, Ingress Controller und mehr.

FluxCD gleicht aus unserem internen Git-Repository ab. Kunden bekommen dieses Repo nie zu Gesicht. Wenn wir ein Cilium-Upgrade pushen, erkennt FluxCD die Änderung und zieht sie still nach. Kein UI, kein manueller Sync, keine Kundenbenachrichtigung.

ArgoCD: die Anwendungs-Schicht

ArgoCD verwaltet alles, was der Kunde deployt. Seine Microservices, APIs, Web-Anwendungen, Worker, CronJobs. Jedes Team bekommt ein eingegrenztes ArgoCD-Projekt mit RBAC und sieht ausschliesslich seine eigenen Anwendungen.

Entwickler brauchen ein UI, in dem sie den Sync-Status sehen, Diffs vergleichen und Rollbacks auslösen können. Das AppProject-Modell von ArgoCD gibt jedem Team eine isolierte Self-Service-Sicht. Genau das ist das richtige Werkzeug für Application Delivery.

Warum FluxCD für Managed Services unverzichtbar ist

Diesen Punkt übergehen die meisten ArgoCD-vs-FluxCD-Vergleiche. Für einen Managed-Services-Provider, der über 50 Cluster mit Dutzenden Plattform-Diensten je Cluster betreibt, hat FluxCD operative Vorteile, die unsere Arbeitsweise grundlegend prägen.

Native Helm Releases

FluxCD legt im Cluster echte Helm-Release-Objekte an. Wenn Sie helm list ausführen, sehen Sie jedes Release, das FluxCD verwaltet. Mit helm get values <release> sehen Sie die aktive Konfiguration. Standard-Helm-Tooling funktioniert, weil FluxCD natives Helm spricht.

ArgoCD geht einen anderen Weg. Es rendert Helm Charts und applyt die resultierenden Manifeste, legt aber keine Helm Releases an. Im Cluster gibt es keinen Eintrag zu Chart-Versionen oder aktiven Values im nativen Helm-Format. Troubleshooting läuft dann über das ArgoCD-UI oder die API, statt über die gewohnten helm-Befehle.

Im Day-2-Betrieb geht dieser Unterschied über Bequemlichkeit hinaus. Weil FluxCD echte Helm Releases verwaltet, können wir einen Service jederzeit aus FluxCD herauslösen und manuell weiterführen. Das ist bei Migrationen entscheidend: Wenn wir einen Service auf ein anderes Chart umstellen, die Deployment-Struktur umbauen oder ihn an das Tooling des Kunden übergeben müssen, suspendieren wir das FluxCD-HelmRelease, und das native Helm Release bleibt im Cluster, voll funktionsfähig, mit erhaltener Historie. Anschliessend können wir es manuell mit helm upgrade weiterführen, auf einen anderen Verwaltungsansatz heben oder durch ein anderes Tool übernehmen lassen. Es gibt keinen proprietären Zustand, den man erst entwirren müsste.

Bei ArgoCD-verwalteten Ressourcen ist eine solche Entkopplung schwieriger. Die Manifeste liegen zwar im Cluster, aber es gibt kein Helm Release, das sich übergeben liesse. Entweder bleiben Sie in ArgoCD oder Sie bauen das Deployment komplett neu auf.

Post-Renderer: Fixes ausliefern, ohne auf Upstream zu warten

Viele Helm Charts, die wir deployen, unterstützen nicht jede Konfigurationsoption, die wir brauchen. Security Contexts, Host Aliases, zusätzliche Pod Labels, Pod Annotations für unser Monitoring, Anpassungen an Network Policies. Genau diese Randfälle werden wichtig, sobald Sie jeden Service über alle Cluster hinweg nach demselben Standard härten und überwachen.

Wir tragen diese Verbesserungen den Maintainern der Upstream-Charts zurück. Beiträge brauchen aber Zeit für Review, Merge und Release. Wir können nicht Wochen auf einen Upstream-Merge warten, wenn ein Kunden-Cluster heute einen Security-Fix benötigt.

Die HelmRelease-Ressource von FluxCD unterstützt Post-Renderer. Ein Post-Renderer nimmt die fertig gerenderten Kubernetes-Manifeste eines Helm Charts und wendet darauf Kustomize-Patches an, bevor sie im Cluster ankommen. Damit fügen wir Security Contexts, Pod Labels für unseren Monitoring-Stack oder Host Aliases ein und patchen jedes beliebige Feld in jeder Ressource, die das Chart erzeugt.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: example-service
spec:
  chart:
    spec:
      chart: example
      version: "2.x"
  postRenderers:
    - kustomize:
        patches:
          - target:
              kind: Deployment
            patch: |
              - op: add
                path: /spec/template/spec/securityContext
                value:
                  runAsNonRoot: true
                  fsGroup: 65534
          - target:
              kind: Deployment
            patch: |
              - op: add
                path: /spec/template/metadata/labels/monitoring
                value: "enabled"

So halten wir eine einheitliche Security- und Observability-Baseline über jeden Managed Service, unabhängig davon, was das Upstream-Chart heute hergibt. Sobald unser Upstream-Beitrag gemerged ist, fällt der Post-Renderer-Patch wieder weg. Sauber und reversibel.

Skalierung über viele Cluster mit Kustomizations

Plattform-Dienste auf über 50 Clustern zu verwalten heisst, mit einer Matrix aus Konfigurationen umzugehen: verschiedene Cloud-Anbieter, verschiedene Kubernetes-Versionen, unterschiedliche Kundenanforderungen, gemeinsame Baselines.

Die Kustomization-Ressource von FluxCD passt genau auf diese Situation. Wir strukturieren unser Plattform-Repo mit einer Basis-Schicht aus Service-Definitionen und einer Overlay-Schicht je Cluster, die spezifische Werte einpatcht. Mit Strategic Merge Patches und JSON Patches von Kustomize lässt sich ausdrücken: "Dieser Cluster ist wie die Baseline, ausser an diesen drei Stellen", ohne dass ganze HelmRelease-Definitionen dupliziert werden müssten.

Kombiniert mit dem Dependency Ordering von FluxCD (Kustomization A hängt von Kustomization B ab) lassen sich auch komplexe Rollout-Reihenfolgen abbilden: CRDs vor Operators, Operators vor ihren Custom Resources, Network Policies vor Workloads.

ArgoCD bringt mit ApplicationSets ebenfalls ein Multi-Cluster-Targeting mit, das Patching- und Merging-Modell ist aber weniger granular. Wenn Sie ein bestimmtes Feld in einem bestimmten HelmRelease auf einem bestimmten Cluster überschreiben müssen, lösen Kustomize-Overlays in FluxCD genau das nativ. Das ist der Unterschied zwischen "überall dasselbe deployen" und "eine konsistente Baseline mit kontrollierten Variationen deployen", und genau Letzteres verlangen Managed Services.

Day-2-Operations in der Praxis

Szenario: Ein Helm-Chart-Upgrade bricht ein CRD. FluxCD erkennt das fehlgeschlagene helm upgrade, markiert das HelmRelease als fehlerhaft und lässt die vorherige Revision weiterlaufen. Der Platform Engineer sieht den Fehler in kubectl get helmrelease -A, prüft helm history <release> und identifiziert die Breaking Change. Der Fix geht nach Git, FluxCD gleicht ab. Falls die Lage manuelle Eingriffe erfordert, suspendieren wir das HelmRelease und arbeiten mit dem nativen Helm Release direkt über die gewohnten Werkzeuge weiter.

Szenario: Ein Upstream-Chart bringt einen nötigen Security Context nicht mit. Wir ergänzen einen Post-Renderer-Patch im HelmRelease, pushen nach Git, FluxCD wendet ihn innerhalb von 60 Sekunden an. Der Patch ist versionskontrolliert, reviewbar und auf genau die Felder beschränkt, die wir ändern müssen. Parallel öffnen wir beim Upstream einen PR mit der eigentlichen Chart-Änderung. Sobald er gemerged und freigegeben ist, ziehen wir die Chart-Version nach und entfernen den Post-Renderer.

Szenario: Onboarding eines neuen Clusters. Wir legen ein Cluster-Overlay-Verzeichnis an, referenzieren die gemeinsamen Basis-Kustomizations, ergänzen Cluster-spezifische Patches (Cloud-Provider-Konfiguration, Node Selectors, Resource Limits) und pushen. FluxCD bringt den ganzen Plattform-Stack in der richtigen Abhängigkeitsreihenfolge hoch. Ein neuer Cluster geht so über einen einzigen Git-Commit von leer auf produktionsbereit.

Warum die Aufteilung und nicht ein einziges Tool?

FluxCD verwaltet ArgoCD. ArgoCD ist eine Plattform-Komponente. Indem FluxCD sie verwaltet, werden ArgoCD-Upgrades zu einem Versions-Bump in einem HelmRelease und nicht zu einem selbstreferenziellen Abgleich. Allein das hat die Aufteilung gerechtfertigt.

Unterschiedliche Zielgruppen. Platform Engineers arbeiten über Git und kubectl. Anwendungsentwickler wollen ein UI mit Sync-Status und Rollback-Knöpfen. Ein Tool kann beide Workflows nicht bedienen, ohne überladen zu werden.

Unterschiedliche Auswirkungen bei Fehlern. Eine fehlerhafte Plattform-Änderung trifft jeden Workload. Eine fehlerhafte Anwendungs-Änderung trifft ein Team. Zwei Tools bedeuten unabhängige Fehlerdomänen: Wenn ArgoCD ausfällt, bleibt die Plattform gesund. Wenn FluxCD ausfällt, laufen die Anwendungen weiter.

Unterschiedliche Änderungsfrequenzen. Plattform-Komponenten ändern sich wöchentlich oder monatlich. Anwendungen ändern sich täglich oder stündlich. Getrennte Reconciliation-Schleifen sorgen dafür, dass keine die andere blockiert.

Wie wir das aufsetzen

Auf jedem Managed Cluster läuft das Bootstrap so:

1. FluxCD wird zuerst installiert. Es zieht sich aus unserem internen Plattform-Git-Repo. Alle Plattform-Dienste sind als FluxCD-Kustomizations und HelmReleases definiert.
2. ArgoCD ist einer dieser Plattform-Dienste. FluxCD installiert und verwaltet ArgoCD inklusive Versionen, Konfiguration und RBAC.
3. ArgoCD bindet die Kunden-Repos an. Pro Team legen wir ein eingegrenztes AppProject an. Die CI/CD-Pipeline des Kunden pusht Manifeste in dessen Repo, ArgoCD synchronisiert von dort.

Beide Tools verwalten nie dieselben Ressourcen. FluxCD gehören die Plattform-Namespaces (flux-system, monitoring, cert-manager, kyverno). ArgoCD gehören die Kunden-Anwendungs-Namespaces. Kyverno-Policies setzen diese Grenze durch.

Mehr erfahren

Diese GitOps-Architektur ist Teil unserer breiteren Managed-Kubernetes-Plattform. Für Multi-Tenant-Setups sehen Sie hier, wie wir das Tenant-Onboarding lösen.

Wenn Sie an einer GitOps-Strategie für eine wachsende Plattform arbeiten, vereinbaren Sie einen Termin. Wir gehen Ihr aktuelles Setup durch und schauen, wo die Grenzen liegen sollten.