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: 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, was es am besten kann, und sie kommen sich nicht in die Quere.

Wir betreiben dieses Dual-GitOps-Setup über 50+ Managed-Kubernetes-Cluster seit 2022. Dieser Beitrag erklärt, warum die Aufteilung existiert, was FluxCD für Day 2 Operations in unserem Massstab unverzichtbar macht, und wie sich die beiden Tools ergänzen.

Unsere Architektur: FluxCD für Plattform, ArgoCD für 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 reconciled aus unserem internen Git Repository. Kunden sehen dieses Repo nie. Wenn wir ein Cilium-Upgrade pushen, erkennt FluxCD die Änderung und reconciled lautlos. Kein UI, kein manueller Sync, keine Benachrichtigung an den Kunden.

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.

Entwickler brauchen ein UI, um Sync-Status zu sehen, Diffs anzuschauen und Rollbacks auszulösen. ArgoCD's AppProject-Modell gibt jedem Team eine isolierte Self-Service-Ansicht. Das ist das richtige Tool für Application Delivery.

Warum FluxCD für Managed Services unverzichtbar ist

Das ist der Teil, den die meisten ArgoCD-vs-FluxCD-Vergleiche übersehen. Für einen Managed Services Provider, der 50+ Cluster mit Dutzenden Platform Services pro Cluster betreibt, hat FluxCD operative Vorteile, die unsere Arbeitsweise grundlegend prägen.

Native Helm Releases

FluxCD erstellt echte Helm Release Objekte im Cluster. 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 funktioniert anders. Es rendert Helm Charts und wendet die resultierenden Manifeste an, erstellt aber keine Helm Releases. Der Cluster hat keine Aufzeichnung über Chart-Versionen oder aktive Values im nativen Helm-Format. Troubleshooting bedeutet, über das ArgoCD-UI oder die API zu gehen, statt über Standard-helm-Befehle.

Für Day 2 Operations geht dieser Unterschied über Bequemlichkeit hinaus. Weil FluxCD echte Helm Releases verwaltet, können wir einen Service jederzeit von FluxCD entkoppeln und manuell übernehmen. Das ist bei Migrationen entscheidend: Wenn wir einen Service auf ein anderes Chart umziehen, die Deployment-Struktur ändern oder 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 seiner History intakt. Wir können es dann manuell mit helm upgrade weiterführen, auf einen anderen Management-Ansatz migrieren oder von einem anderen Tool übernehmen lassen. Es gibt keinen proprietären State, den man entwirren müsste.

Bei ArgoCD-verwalteten Ressourcen ist diese Art der Entkopplung schwieriger. Die Manifeste existieren im Cluster, aber es gibt kein Helm Release zum Übergeben. Man ist entweder in ArgoCD oder man erstellt das Deployment von Grund auf neu.

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 Monitoring, Network Policy Anpassungen. Das sind Edge Cases, die relevant werden, wenn man jeden Service nach demselben Standard über alle Cluster hinweg härtet und überwacht.

Wir tragen diese Verbesserungen an die Upstream-Chart-Maintainer zurück. Aber Contributions brauchen Zeit für Review, Merge und Release. Wir können nicht Wochen auf einen Upstream-Merge warten, wenn ein Kunden-Cluster jetzt einen Security Fix braucht.

FluxCD's HelmRelease-Ressource unterstützt Post-Renderer. Ein Post-Renderer nimmt die vollständig gerenderten Kubernetes-Manifeste eines Helm Charts und wendet Kustomize-Patches an, bevor sie den Cluster erreichen. So können wir Security Contexts injizieren, Pod Labels für unseren Monitoring-Stack hinzufügen, Host Aliases setzen oder jedes beliebige Feld in jeder Ressource patchen, die das Chart produziert.

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 konsistente Security- und Observability-Baseline über jeden Managed Service hinweg, unabhängig davon, was der Upstream-Helm-Chart heute unterstützt. Wenn unsere Upstream-Contribution gemerged wird, entfernen wir den Post-Renderer-Patch. Sauber und reversibel.

Multi-Cluster-Skalierung mit Kustomizations

Platform Services über 50+ Cluster zu verwalten bedeutet, mit einer Matrix von Konfigurationen umzugehen: verschiedene Cloud-Provider, verschiedene Kubernetes-Versionen, verschiedene Kundenanforderungen, gemeinsame Baselines.

FluxCD's Kustomization-Ressource bildet dieses Problem direkt ab. Wir strukturieren unser Plattform-Repo mit einer Basis-Schicht von Service-Definitionen und per-Cluster-Overlays, die spezifische Werte patchen. Kustomize's Strategic Merge Patches und JSON Patches erlauben es, "dieser Cluster ist wie die Baseline, ausser bei diesen drei Unterschieden" auszudrücken, ohne ganze HelmRelease-Definitionen zu duplizieren.

Kombiniert mit FluxCD's Dependency Ordering (Kustomization A hängt von Kustomization B ab) können wir komplexe Rollout-Sequenzen ausdrücken: CRDs vor Operators, Operators vor ihren Custom Resources, Network Policies vor Workloads.

ArgoCD hat ApplicationSets für Multi-Cluster-Targeting, aber das Patching- und Merging-Modell ist nicht so granular. Wenn Sie ein spezifisches Feld in einem spezifischen HelmRelease auf einem spezifischen Cluster überschreiben müssen, behandelt Kustomize-Overlays in FluxCD das nativ. Das ist der Unterschied zwischen "überall dasselbe deployen" und "eine konsistente Baseline mit kontrollierten Variationen deployen", und genau das erfordern 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 fehlgeschlagen und lässt die vorherige Revision laufen. 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 und FluxCD reconciled. Wenn die Situation manuelle Intervention erfordert, suspendieren wir das HelmRelease und arbeiten direkt mit dem nativen Helm Release über Standard-Tooling.

Szenario: Upstream-Chart hat keinen benötigten Security Context. Wir fügen einen Post-Renderer-Patch zum HelmRelease hinzu, 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. Wir öffnen einen PR beim Upstream mit der eigentlichen Chart-Änderung. Wenn er gemerged und released wird, bumpen wir die Chart-Version und entfernen den Post-Renderer.

Szenario: Neues Cluster-Onboarding. Wir erstellen ein Cluster-Overlay-Verzeichnis, referenzieren die gemeinsamen Basis-Kustomizations, fügen Cluster-spezifische Patches hinzu (Cloud-Provider-Config, Node Selectors, Resource Limits) und pushen. FluxCD bootstrappt den gesamten Plattform-Stack in der richtigen Abhängigkeitsreihenfolge. Ein neuer Cluster geht von leer zu produktionsbereit durch einen einzigen Git-Commit.

Warum die Aufteilung und nicht nur ein Tool?

FluxCD verwaltet ArgoCD. ArgoCD ist eine Plattform-Komponente. Mit FluxCD, das es verwaltet, sind ArgoCD-Upgrades ein Versions-Bump in einem HelmRelease, keine selbstreferenzielle Reconciliation. Das allein hat die Aufteilung gerechtfertigt.

Unterschiedliche Zielgruppen. Platform Engineers arbeiten über Git und kubectl. Applikations-Entwickler wollen ein UI mit Sync-Status und Rollback-Buttons. Ein Tool kann nicht beide Workflows bedienen, ohne übermässig komplex zu werden.

Unterschiedliche Blast Radii. Eine fehlerhafte Plattform-Änderung betrifft jeden Workload. Eine fehlerhafte Applikations-Änderung betrifft ein Team. Unterschiedliche Tools bedeuten unabhängige Fehlerdomänen: Wenn ArgoCD ausfällt, bleibt die Plattform gesund. Wenn FluxCD ausfällt, laufen Applikationen weiter.

Unterschiedliche Änderungsrhythmen. Plattform-Komponenten ändern sich wöchentlich oder monatlich. Applikationen ändern sich täglich oder stündlich. Separate Reconciliation-Schleifen bedeuten, dass keine die andere blockiert.

Wie wir das aufsetzen

Auf jedem Managed Cluster funktioniert das Bootstrap so:

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, inklusive Versionen, Konfiguration und RBAC.
3. ArgoCD verbindet sich mit Kunden-Repos. Wir erstellen scoped AppProjects pro Team. Die CI/CD-Pipeline des Kunden pusht Manifeste in ihr Repo, und ArgoCD synct daraus.

Die zwei Tools verwalten nie dieselben Ressourcen. FluxCD besitzt Plattform-Namespaces (flux-system, monitoring, cert-manager, kyverno). 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 das Tenant Onboarding handhaben.

Wenn Sie ü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.