Argo CD vs Flux: Gleiches Git, andere Steuerung

Beim ersten Deployment wirken Argo CD und Flux beinahe austauschbar: Ein Kubernetes-Manifest wird eingecheckt, kurz darauf läuft die Anwendung. Interessant wird der Vergleich, wenn ein Chart scheitert, ein Operator Felder verändert, ein weiteres Team Zugriff braucht oder Produktion auf das gestrige Image zurückkehren muss.

Argo CD vs Flux ist eine Entscheidung darüber, wie dein Team Auslieferung steuert. Argo CD bietet eine anwendungsorientierte Oberfläche. Flux liefert Controller, die direkt in die Kubernetes-API passen. Beide eignen sich für anspruchsvolle Plattformen. Entscheidend sind die Betreiber, die Rolle von Helm und die gewünschte Berechtigungsarchitektur.

Argo CD oder Flux: die kurze Entscheidungshilfe

Argo CD passt gut, wenn Entwickler Anwendungen, Diffs und Synchronisationsaktionen an einem gemeinsamen Ort sehen sollen und ApplicationSets die Anwendungsdefinitionen für eine Flotte erzeugen sollen.

Flux passt gut, wenn die Plattform um Kubernetes-APIs, delegierte Service Accounts, SOPS und kombinierbare Quellen aufgebaut wird. Auch ein benötigter Helm-Release-Lebenszyklus spricht für einen genaueren Blick auf Flux.

Das sind Ausgangspunkte, keine Grenzen. Flux Operator ergänzt eine leistungsfähige Oberfläche. Argo CD lässt sich deklarativ betreiben, ohne jeden Entwickler durch seine UI zu schicken. Flux kann entfernte Cluster verwalten, Argo CD kann pro Cluster installiert werden.

Die folgenden Abschnitte erklären die Bedingungen hinter der Tabelle. Denn „wird unterstützt“ bedeutet nicht automatisch „ohne Integrationsarbeit nutzbar“.

Was GitOps eigentlich macht

Angenommen, Git beschreibt drei Replikate einer Anwendung. Jemand setzt im Cluster manuell fünf. Ein GitOps-Controller erkennt den Unterschied und handelt nach seiner Konfiguration: Abweichung melden oder den vorgesehenen Wert wiederherstellen.

Fünf Begriffe helfen beim Weiterlesen:

• Sollzustand: die versionierte Beschreibung dessen, was existieren soll.
• Reconciliation: wiederholter Abgleich von Soll und Ist mit einer anschließenden Aktion.
• Drift: eine Abweichung, die außerhalb der deklarierten Konfiguration entstanden ist.
• CRD: eine Erweiterung der Kubernetes-API. Damit lassen sich etwa Argo-Applications oder Flux-HelmReleases neben normalen Deployments speichern.
• Health: die Bewertung, ob Ressourcen definierte Bereitschaftskriterien erfüllen. Git zu entsprechen und erfolgreiche Nutzeranfragen zu bedienen sind unterschiedliche Eigenschaften.

CI baut und testet weiterhin die Anwendung. Die Pipeline veröffentlicht ein Image und aktualisiert eine Konfigurationsreferenz. Anschließend übernimmt der GitOps-Controller die Auslieferung. Terraform oder OpenTofu können den Cluster bereitstellen, während Argo CD oder Flux die Workloads darin verwalten. Die Grenze zwischen diesen Zuständigkeiten sollte ausdrücklich festgelegt werden. Die Einführung in GitOps mit Argo CD erklärt den Wechsel vom Push- zum Pull-Modell.

Ein entfernter Deployment-Job beseitigt keine Berechtigungen. Die Auslieferungsbefugnis wandert zum Controller und zu den Personen, die seine Eingaben ändern können. Reviews, Repository-Regeln und Controller-Zugangsdaten werden Teil der Deployment-Grenze.

Architektur: Anwendungsplattform oder Controller-Baukasten

Bei Argo CD sind drei zentrale Aufgaben erkennbar. Der repo-server lädt und rendert Konfiguration. Der application-controller vergleicht und synchronisiert Ressourcen. Der API-Server bedient Oberfläche, CLI und Integrationen. ApplicationSet und Benachrichtigungen ergänzen eigene Controller. Redis dient als Cache, Dex ist eine optionale Authentifizierungskomponente. Argo-CD-Architektur

Flux zerlegt den Ablauf in source-controller, kustomize-controller, helm-controller und notification-controller. Image-Controller und source-watcher kommen optional hinzu. Quellen erzeugen Artefakte, die andere Controller konsumieren. Jeder Schritt lässt sich über Kubernetes-Ressourcen und deren Conditions untersuchen. GitOps-Toolkit-Komponenten

Deshalb fühlt sich Argo CD häufig wie ein Produkt für Anwendungsbereitstellung an und Flux wie ein Baustein der Plattform. Im Störungsfall wird der Unterschied konkret: Beginnen Entwickler beim Anwendungsbaum und Diff oder bei Quellen und Reconciliation-Conditions? Ein Portal kann beide Modelle abstrahieren. Jemand muss es aber entwickeln und warten.

Die Grafik zeigt häufige Muster, keine vorgeschriebene Topologie. Eine zentrale Installation bündelt Zugangsdaten und Verfügbarkeitsanforderungen. Lokale Installationen verteilen Updates und brauchen eine gemeinsame Flottenbeobachtung. Entscheidend ist, welche Verantwortung dein Team zuverlässig übernehmen kann.

Dasselbe Deployment in YAML

Beide Beispiele verwenden dieselbe öffentliche Quelle: das Verzeichnis kustomize-guestbook auf dem Branch master im offiziellen Argo-Beispielrepository. Ziel ist jeweils der bereits vorhandene Namespace guestbook. So werden keine unterschiedlichen Aufgaben miteinander verglichen.

Vorausgesetzt werden ein entbehrlicher Testcluster, das jeweilige Werkzeug mit installierten CRDs, passende Berechtigungen und der vorhandene Namespace. Für die öffentliche Quelle ist kein Repository-Token nötig. Verwende ein Werkzeug je Testcluster oder beende dessen Ressourcenverantwortung, bevor du das andere ausprobierst.

kubectl create namespace guestbook

Die Argo-Application, Flux-Quelle und Flux-Kustomization stehen mit Einrichtungshinweisen zum Download bereit. Zugangsdaten sind nicht enthalten.

Argo CD: Quelle und Ziel in einer Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: master
    path: kustomize-guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Quelle, Ziel und Automatisierung stehen zusammen. Der lokale API-Endpunkt bezeichnet den Cluster der Installation. prune erlaubt das Entfernen verwalteter Ressourcen, die aus der Quelle gelöscht wurden. selfHeal erlaubt die Korrektur direkter Clusteränderungen. Beide Optionen sind hier bewusst aktiviert. Application-Spezifikation

project: default hält das Beispiel kurz, ist aber keine Mandantentrennungsstrategie. Eine gemeinsame Produktionsplattform braucht eingeschränkte AppProjects und angemessene Rechte im Zielcluster.

Flux: Quelle laden, anschließend ihren Inhalt abgleichen

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: guestbook
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/argoproj/argocd-example-apps.git
  ref:
    branch: master

Das GitRepository lädt ein Artefakt. Es deployt allein noch keine Anwendung. Mehrere Verbraucher können dieselbe Quelle verwenden. Flux-GitRepository-API

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: guestbook
  namespace: flux-system
spec:
  interval: 5m
  path: ./kustomize-guestbook
  targetNamespace: guestbook
  prune: true
  wait: true
  timeout: 3m
  sourceRef:
    kind: GitRepository
    name: guestbook

Die Flux-Kustomization ist ein Abgleichobjekt. Die Datei kustomization.yaml im Repository steuert dagegen den Kustomize-Build. Ähnliche Namen, unterschiedliche Aufgaben. wait und timeout ergänzen eine Bereitschaftsprüfung. targetNamespace erzeugt den Namespace nicht. Flux-Kustomization-API

Der Branch bleibt für das Lernbeispiel lesbar, kann sich aber ändern. Für einen wiederholbaren Vergleich muss die verwendete Revision festgehalten werden. Kontrollierte Releases sollten geprüfte Revisionen oder unveränderliche Artefakte verwenden. Die Beispiele zeigen die Deployment-API; sie installieren oder härten die Plattform nicht.

Helm verändert den Betriebsablauf

„Beide unterstützen Helm“ verdeckt den wichtigsten Unterschied. Argo CD verwendet Helm zum Rendern von Manifesten und verwaltet anschließend die Kubernetes-Objekte selbst. Dabei entsteht nicht das Helm-Release eines helm install. helm list ist deshalb kein Verzeichnis Argo-verwalteter Anwendungen. Ein Helm-Release-Rollback ist auch nicht deren Wiederherstellungsverfahren. Unterstützte Helm-Hooks werden in Argo-Abläufe übersetzt; das ist keine vollständige Gleichheit der Lebenszyklen. Helm mit Argo CD

Der helm-controller von Flux verwaltet ein tatsächliches Helm-Release. Seine API unterstützt Tests, Values-Referenzen, Wiederholungsversuche und konfigurierbare Maßnahmen nach fehlgeschlagener Installation oder Aktualisierung. Bei Charts mit clusterabhängigem Rendering, Release-Hooks oder Helm-Tests müssen deshalb auch Controller-Rechte und Einstellungen geprüft werden. Flux-HelmRelease-Referenz

Flux 2.8 führte Helm v4 mit verändertem Server-Side-Apply- und Health-Verhalten ein. Vorhandene Releases behalten ihren gespeicherten Apply-Modus, bis er ausdrücklich umgestellt wird. Ein Flux-Update stellt also nicht automatisch jedes bestehende Release um. Mit Flux 2.9 änderten sich außerdem Vorgaben für Post-Render-Strategien. Diese Punkte gehören in die Upgrade-Prüfung. Flux 2.8, Flux 2.9

Für einfache, deterministische interne Charts kann die gemeinsame Diff- und Ressourcenansicht von Argo CD besonders praktisch sein. Teams, die bewusst mit Helm-Historie, Tests und Remediation arbeiten, sollten Flux gründlich ausprobieren. Nimm das schwierige Chart als Prüfstein, nicht nur das Beispiel, das überall funktioniert.

Synchronisation, Health, Abhängigkeiten und Drift

Argo CD trennt Synchronisationsregeln von Health. Automatische Synchronisation aktiviert nicht automatisch Pruning oder Self-Healing. Die Dokumentation weist außerdem darauf hin, dass bei aktiviertem Auto-Sync die Rollback-Operation der Application nicht ausgeführt werden kann. Ein geprüfter Git-Revert ist häufig die nachhaltigere Korrektur, weil er den Sollzustand verändert. Automatische Synchronisation

Flux gleicht in konfigurierten Intervallen ab. Webhook-Receiver können Quellenaktualisierungen beschleunigen; Suspend pausiert den jeweiligen Abgleich. Für Helm-verwaltete Ressourcen muss Helm Drift Detection bewusst konfiguriert werden. Eine Release-Prüfung bedeutet nicht automatisch, dass jede manuelle Feldänderung repariert wird. Flux-Helm-Leitfaden

Reihenfolge ist keine globale Transaktion

Argo CD bietet Phasen, Hooks und nummerierte Sync-Waves. Damit lassen sich Ressourcen innerhalb einer Synchronisation ordnen. Eine Annotation auf voneinander unabhängigen Applications erzeugt aber keinen universellen Abhängigkeitsgraphen für die Flotte. Sync-Phasen und Waves

Flux dependsOn beschreibt Abhängigkeiten zwischen Kustomizations beziehungsweise HelmReleases des jeweiligen Typs. Genauere Bereitschaftsregeln, unter anderem mit CEL, können diese Grenzen präzisieren. Zyklen sind zu vermeiden. „Die CRD existiert“ und „der Operator verarbeitet seine Custom Resources zuverlässig“ sind verschiedene Bedingungen. Kustomize-API-Referenz

Für Datenbankoperator, Datenbank und Anwendung muss jede Grenze definiert werden. Ein Kubernetes-Deployment im Zustand Available beweist weder die Umkehrbarkeit einer Datenbankmigration noch einen erfolgreichen Checkout. Keines der Werkzeuge macht aus einer verteilten Auslieferung eine Transaktion.

Die richtigen Felder beim richtigen Controller lassen

Ein HPA kann die Replikazahl verwalten, ein Webhook zusätzliche Felder einfügen. Argo CD bietet ignoreDifferences. Damit diese Regeln auch beim Anwenden berücksichtigt werden, kann zusätzlich RespectIgnoreDifferences=true nötig sein. Einen Unterschied auszublenden und das Apply-Verhalten zu verändern sind getrennte Entscheidungen. Diff-Anpassung, Sync-Optionen

Flux besitzt Feldregeln für die Drift-Behandlung von Kustomizations. Wähle Felder und Ressourcenselektoren eng und prüfe anschließend das tatsächliche Verhalten. Eine breite Ignore-Regel kann eine unerwünschte Änderung genauso verstecken wie ein legitimes Operator-Update. Selektive Drift-Korrektur

Git, OCI, Buckets und fertig gerenderte Manifeste

Argo CD verarbeitet Git-, Helm- und OCI-Quellen. Für OCI gelten Verpackungsregeln, darunter zulässige Medientypen und ein einzelner Artefakt-Layer. Ein Helm-OCI-Chart und ein allgemeines OCI-Manifestartefakt werden unterschiedlich konfiguriert. Das Repository-URL-Format sollte deshalb nicht ungeprüft übernommen werden. OCI mit Argo CD

Flux modelliert Git, OCI, Helm-Repositories und Object-Storage-Buckets als Quellen. OCIRepository kann Artefaktsignaturen prüfen. Dazu muss eine erwartete Identität beziehungsweise Vertrauensregel konfiguriert sein. Die Ablage in einer Registry allein authentifiziert keinen Herausgeber. Flux OCIRepository

Argo CD erlaubt eigene Rendering-Werkzeuge über Config Management Plugins. Flux hält die Ausführung beliebiger Renderer bewusst aus seinem Abgleichmodell heraus. Ungewöhnliche Formate können in CI gerendert und als fertiges Ergebnis veröffentlicht werden. Der optionale source-watcher und ArtifactGenerator ergänzen Zusammenstellung und Aufteilung von Quellen. Dadurch verschiebt sich, wo Abhängigkeiten, Codeausführung und Fehlersuche stattfinden. Flux FAQ

Fertig gerenderte Manifeste machen diese Grenze sichtbar: Templates durchlaufen einen kontrollierten Build, und dessen genaue Ausgabe wird zum geprüften Deployment-Eingang. Der Source Hydrator von Argo CD automatisiert eine Git-basierte Variante dieses Musters und ist als Beta-Funktion dokumentiert. Wichtig: Beim Rendern dürfen keine Klartext-Secrets eingefügt werden, denn die Ausgabe wird in Git eingecheckt. Secrets sollten erst im Zielcluster aufgelöst werden. Source Hydrator

Der Ansatz kann Reviews verständlicher machen, erzeugt aber ein weiteres Artefakt mit Aufbewahrungs-, Berechtigungs- und Herkunftsanforderungen. Auch ein signiertes Manifestpaket braucht einen vertrauenswürdigen Build und unveränderliche Image-Referenzen.

Oberfläche: die tatsächlich geplanten Installationen vergleichen

Die integrierte Oberfläche ist ein wesentlicher Vorteil von Argo CD, wenn Entwickler Anwendungsbaum, Istzustand, Diff und Synchronisationsaktionen gemeinsam benötigen. Sie schafft eine gemeinsame Sprache für Support. Gleichzeitig muss das Plattformteam eine weitere Oberfläche mit Identitäten und Zugriffsregeln betreiben.

Flux Core enthält keine UI. Flux Operator ergänzt jedoch eine separate Oberfläche mit Pipeline-Graphen, Workloads, Logs, OIDC-Anmeldung und Kubernetes RBAC. Sie gehört zum Operator-Ökosystem und nicht zur reinen Controller-Installation. Flux ohne diese Unterscheidung pauschal als CLI-only zu bezeichnen, ist überholt. Flux Operator Web UI

Prüfe den ganzen Arbeitsweg: Findet ein Entwickler den fehlgeschlagenen Rollout ohne cluster-admin? Sieht er die genaue Quellrevision? Versteht er die nächste erlaubte Aktion? SSO, Update-Verantwortung und Support-Dokumentation gehören ebenso zum Vergleich wie die Funktionen. Ein Screenshot ersetzt keinen Bedienungstest.

Mehrere Cluster: Zugangsdaten bündeln oder Controller verteilen?

Argo CD wird häufig als Hub-and-Spoke-System aufgebaut. ApplicationSets erzeugen Applications aus registrierten Clustern, Git-Verzeichnissen, Pull Requests und kombinierten Eingaben. Das reduziert wiederholte Konfiguration und hält die Anwendungsverwaltung an einem Ort. ApplicationSet-Einführung

Der Hub braucht trotzdem Kapazität. Repository-Rendering, Cluster-Watches, Warteschlangen, Caches und Controller-Sharding bestimmen den Betrieb. Ein Monorepo kann Arbeit vervielfachen, wenn viele Anwendungen dieselben Eingaben teilen. Nutze dokumentierte Stellschrauben und miss den tatsächlichen Änderungsradius. Argo CD: Hochverfügbarkeit und Skalierung

Flux läuft häufig je Cluster und verwendet beispielsweise clusters/eu-prod als dessen Konfigurationspfad. Eine einzelne zentrale Deployment-Identität für alle Ziele wird damit vermieden. Dafür entsteht eine Flotte von Installationen, die aktualisiert werden müssen. Auch entfernte Cluster sind möglich. ResourceSet im Flux Operator bietet zusätzliche Generierungsmuster, ist aber nicht dieselbe Core-API wie ApplicationSet.

Für beide Seiten gibt es Belege großer Installationen:

• In der Argo-CD-Nutzerumfrage 2025 verwalteten 42 % der Befragten mehr als 500 Anwendungen je Instanz. 25 % verbanden eine Instanz mit mehr als 20 Clustern. Das beschreibt die Befragten, nicht den gesamten Kubernetes-Markt. CNCF-Umfragezusammenfassung
• Der Morgan-Stanley-Fallbericht beschreibt mehr als 500 Cluster mit Flux, Service-Account-Impersonation, angepasste Intervalle und Parallelität, zentrale Beobachtbarkeit sowie den Wechsel von selbst betriebenem Git zu S3-Artefakten. Das ist ein Implementierungsbericht, kein direkter Vergleichstest. Flux-Fallstudie

Keiner dieser Belege sagt, welches Werkzeug in deiner Flotte weniger RAM braucht. Ein fairer Performancevergleich muss Anwendungs- und Ressourcenzahl, Quellgröße, Intervalle, Replikate, aktivierte Komponenten und Fehlersituationen konstant halten.

Mandantentrennung und Sicherheit: tatsächliche Befugnisse prüfen

Ein AppProject in Argo CD begrenzt Quellen, Ziele und Ressourcentypen. Argo RBAC regelt Nutzeraktionen. Die Zugangsdaten zum Zielcluster bestimmen, was der Controller tatsächlich tun kann. Das Default-Projekt ist großzügig und sollte auf einer gemeinsamen Plattform bewusst ersetzt oder eingeschränkt werden. Argo-CD-Projekte, Argo RBAC

Flux kann im Namen eines Service Accounts des jeweiligen Mandanten abgleichen. Zum Lockdown gehören eingeschränkte Namespace-Referenzen, ein Default-Service-Account und begrenzte Remote-Bases. Entscheidend ist die durchgesetzte Impersonation. Ein Namespace pro Team allein stellt diese Trennung nicht her. Flux-Multitenancy-Lockdown

Beide Projekte veröffentlichen Sicherheitshinweise und Advisories. Vergleiche installierte Versionen mit betroffenen Bereichen und korrigierten Releases. Eine Advisory-Summe ist keine Kompromittierungswahrscheinlichkeit: Repository-Grenzen, Komponenten, Offenlegung und Forschungsaufmerksamkeit unterscheiden sich. Die Hinweise sollen konkrete Prüfungen auslösen, keine Sicherheitstrophäe vergeben. Argo-CD-Sicherheitsleitfaden, Flux-Sicherheitsdokumentation

Flux 2.10 ergänzt SPIFFE-basierte Controller-mTLS- und Object-Identity-Funktionen. Dazu müssen Identitäten und Vertrauensbeziehungen eingerichtet sein. Allein die Installation der Version erzeugt keine SPIFFE-Vertrauensdomäne. Flux-2.10-Ankündigung

Der aussagekräftige Sicherheitsvergleich folgt dem Weg von einer erlaubten Git-Änderung zu einer erlaubten Clusteraktion. Zeichne diesen Weg, bevor du Funktionen zählst.

Secrets und Zugriff ohne Schlüssel auf GKE

Der kustomize-controller von Flux integriert SOPS-Entschlüsselung mit age und unterstützten Schlüsselverwaltungen. In Git bleibt Chiffretext. Entschlüsselungsidentität, erzeugtes Kubernetes-Secret und Workload-Zugriff brauchen trotzdem eigene Regeln. Git-Verschlüsselung schützt ein Secret nicht vor einem berechtigten Entschlüsselungscontroller. Flux-SOPS-Leitfaden

Argo CD wird häufig mit External Secrets Operator oder Sealed Secrets kombiniert. Secret-Injektion während des Renderns über Plugins ist eine andere Architektur und erzeugt andere Risiken in Manifesten und Caches. Die Projektdokumentation bevorzugt Secret-Verwaltung im Zielcluster. Secrets mit Argo CD

Für Google Cloud dokumentiert Flux Authentifizierung zu Artifact Registry, Cloud Storage, Cloud KMS und entfernten GKE-Clustern. Object Identity erlaubt unterschiedliche Identitäten je Flux-Ressource. Cloud-IAM-Bindings und Controller-Einstellungen müssen dazu passen. Das ist ein konkreter Vorteil, wenn die Plattform kurzlebige Google-Zugangsdaten je Mandant fordert. Flux und Google Cloud, Object Identity einrichten

Der Argo-CD-Leitfaden für private Repositories beschreibt Azure Workload Identity und einen JSON-Schlüssel für Google Cloud Source Repositories. Daraus folgt nicht, dass Argo CD auf GKE grundsätzlich keinen Zugriff ohne statische Schlüssel verwenden kann. Repository, Registry, Zielcluster und Secret-Operator sind unterschiedliche Integrationswege. Verlange für jeden Dienst einen dokumentierten und wartbaren Weg, statt aus einem einzelnen Dokumentationsabschnitt die gesamte Unterstützung abzuleiten. Private Repositories in Argo CD

Der Leitfaden zu Workload Identity Federation erklärt für beide Designs die relevante Lebensdauer und Vertrauensgrenze von Zugangsdaten.

Image-Updates, Promotion und Canaries sind unterschiedliche Aufgaben

Image-Automatisierung wählt eine neue Image-Referenz. Die optionalen Flux-Controller ImageRepository, ImagePolicy und ImageUpdateAutomation verbinden Registry-Erkennung mit einer Git-Änderung. Argo CD Image Updater ist ein separates Projekt. In beiden Fällen muss feststehen, welches Repository und welchen Branch der automatische Schreiber verändern darf. Flux-Image-Controller, Argo CD Image Updater

Promotion entscheidet, dass ein bereits geprüftes Artefakt in die nächste Umgebung gelangen darf. Dafür braucht es Nachweise und Regeln: Wer genehmigt? Welche Tests müssen bestehen? Welcher Digest wird übernommen? Was stoppt eine fehlgeschlagene Freigabe? Ein Semver-Bereich zur Chart-Erkennung ersetzt diesen Ablauf nicht. Kargo und GitOps Promoter ergänzen Argo-orientierte Prozesse. Flux-Plattformen verwenden häufig Git-Pull-Requests oder kontrollierte OCI-Referenzen. Kargo, GitOps Promoter

Progressive Delivery verteilt Traffic und bewertet den Rollout. Argo Rollouts und Flagger sind zusätzliche Controller. Ihre Funktionen dürfen nicht automatisch der Basisinstallation von Argo CD oder Flux zugeschrieben werden. Auch Metriken und Abbruchkriterien brauchen Verantwortliche. Argo Rollouts, Flagger

Ein robuster Ablauf übernimmt denselben unveränderlichen Image-Digest von Staging nach Produktion. Ein erneuter Build aus demselben Quellcode kann ein anderes Artefakt erzeugen. Rückfallpläne müssen Konfiguration und Daten berücksichtigen: Ein älteres Image macht nicht jede Schemaänderung rückgängig.

Benachrichtigungen, Beobachtbarkeit und KI-Zugriff

Der Notifications-Controller von Argo CD und das Provider/Alert-Modell von Flux bringen Deployment-Ereignisse in bestehende Teamabläufe. Konfiguriere verwertbare Fehlersignale mit Quellrevisionen, statt den Chat mit jeder erfolgreichen Reconciliation zu füllen. Argo-CD-Benachrichtigungen, Flux notification-controller

Beobachte Quellzugriffsfehler, fehlgeschlagene und langsame Abgleiche, Warteschlangen und die Zeit seit der letzten erfolgreich angewendeten Sollrevision. Ein gesunder Controller-Pod beweist keine aktuelle Flotte. Flux stellt dafür Controller-Metriken bereit. Flux-Metrikreferenz

Flux Operator bietet außerdem einen MCP-Server. Dieser ist nicht grundsätzlich schreibgeschützt: --read-only ist laut Dokumentation standardmäßig false. Erst der aktivierte Modus deaktiviert schreibende Werkzeuge. Secret-Maskierung und ein Modellversprechen ersetzen keine begrenzten Kubernetes-Rechte. MCP-Konfiguration

Wenn ein Assistent Logs lesen und Änderungen anfordern kann, ist er ein weiterer Deployment-Client. Trenne Beobachtung von Mutation und prüfe die Vertrauensgrenzen von KI-Agenten, bevor Produktionszugangsdaten angebunden werden.

Releases, Projektgesundheit und Upgrade-Aufwand

Beide gehören zum CNCF-Graduated-Ökosystem: Flux graduierte im November 2022, das Argo-Projekt im Dezember 2022. Das signalisiert Projektreife, zertifiziert aber nicht die eigene Installation. Flux-Graduierung, Argo-Graduierung

Flux wurde nach der Schließung von Weaveworks mit Unterstützung aus seinem Ökosystem weiterentwickelt. Der frühere Anbieter, Flux v1 und eine ältere Oberfläche dürfen nicht mit dem heutigen Projektstatus verwechselt werden. Flux-Ökosystembericht

Sterne und Contributor-Zahlen helfen bei der Orientierung. Ein einzelnes Repository und ein über mehrere Repositories verteilter Baukasten ergeben aber keine belastbare Aktivitätsrangliste. Für eine Beschaffung zählen Release-Rhythmus, unterstützte Versionen, Reaktion auf Advisories und tatsächlich erhältlicher Support.

Argo-CD-Upgrades verlangen eine Verhaltensprüfung. Die Hinweise zu 3.6 beschreiben Server-Side Diff als neues Standardverhalten bei ServerSideApply=true, mit explizitem Opt-out und zusätzlichen API-Server-Anfragen. Frühere Major-Upgrades änderten auch RBAC- und Resource-Tracking-Vorgaben. Upgrade 3.5–3.6, Migration 2.14–3.0

Auch Flux-Upgrades bringen Verhaltensänderungen und veraltete APIs. Prüfe Feature-Gates, Helm-Vorgaben und die Kubernetes-Supportmatrix. flux migrate hilft bei API-Migrationen, testet aber weder Charts noch Rechte oder Wiederherstellung. Vor dem flottenweiten Update gehört der Upgrade-Abschnitt des jeweiligen Releases gelesen. Flux-Upgrade-Verfahren

Verwaltete Angebote: AWS, Azure, GitLab und Google Cloud

Cloud-Integration kann die praktische Entscheidung vorwegnehmen. Ein vollständig betriebener Dienst und eine Erweiterung, die Komponenten im eigenen Cluster verwaltet, haben unterschiedliche Verantwortungsgrenzen.

Quellen: Amazon EKS Argo CD, Azure Flux, Azure Argo CD, GitLab GitOps, OpenShift GitOps, Google Config Sync.

Kommerzielle Angebote stammen unter anderem von Akuity, Codefresh/Octopus und ControlPlane. Prüfe beim konkreten Angebot Support, Mandantenmodell, Aufbewahrung, Identität und Preis. Upstream-Eigenschaften lassen sich nicht pauschal übertragen. Auch Open Source kostet Arbeitszeit, Compute und Störungsbehandlung. Kostenlose Software bedeutet nicht gleiche Gesamtkosten.

Entscheidung in der Praxis: ein brauchbarer Prüfplan

Beginne mit einer schwierigen, repräsentativen Anwendung und den tatsächlich vorgesehenen Rechten. Ergänze einen gewöhnlichen Workload, einen Operator mit Abhängigkeiten und das Helm-Chart, das Unterschiede im Lebenszyklus sichtbar machen dürfte.

Dokumentiere Messwerte mit Versionen und Einstellungen. Der RAM-Verbrauch einer leeren Installation ergibt keine Produktionsprognose. Vergleiche die vollständige benötigte Installation: UI, HA-Replikate, Image-Controller, Secrets und Monitoring eingeschlossen.

Drei sinnvolle Architekturversuche

Eine Anwendungsplattform für Entwickler: Argo CD mit ApplicationSets, eingeschränktem AppProject pro Team, externer Secret-Auflösung und Freigabeprozess. Der Vorteil ist eine zusammenhängende Anwendungssicht. Der Aufwand liegt im Hub, seinen Rechten und Integrationen.

Eine Kubernetes-native GKE-Flotte: Flux pro Cluster, Google-Identität je Objekt, gegebenenfalls SOPS mit Cloud KMS und signierte OCI-Artefakte passend zur Lieferkette. Flux Operator ergänzt die benötigte Oberfläche. Zu betreiben bleiben Flottenupdates, Artefaktbereitstellung und verständliche Supportwege.

Ein Hybrid mit getrennter Verantwortung: Flux verwaltet Cluster-Infrastruktur, Argo CD die Team-Anwendungen. Eigentum muss bis zu Ressourcen und Feldern definiert sein. Beide dürfen nicht ständig dasselbe Objekt korrigieren. Der zusätzliche Betriebsstack ist nur gerechtfertigt, wenn die Trennung ein reales organisatorisches Problem löst.

Klein anfangen und die Grenzen des Tutorials kennen

Nutze die offiziellen Einstiege für Argo CD oder Flux in einem entbehrlichen Cluster. Wähle ein Release statt eines beweglichen Installationsmanifests. Flux Bootstrap kann Controller installieren und ihre Konfiguration in Git ablegen. Die dabei verwendeten Zugangsdaten sollten nur die erforderlichen Rechte erhalten.

Wende anschließend das passende Guestbook-Beispiel an und prüfe den Zustand:

# Argo-CD-Testcluster
kubectl -n argocd get application guestbook

# Flux-Testcluster
flux get sources git -n flux-system
flux get kustomizations -n flux-system

Für weiterführende Übungen eignen sich das offizielle Flux-Multitenancy-Beispiel, das Kustomize/Helm-Beispiel sowie die ApplicationSet- und Upgrade-Dokumentation von Argo CD. Kurse und Zertifikate können Lernen strukturieren. Ob die Architektur funktioniert, zeigen erfolgreiche Deployments und nachweisbar abgelehnte Zugriffe in der eigenen Umgebung.

Das Steuerungsmodell wählen, das das Team betreiben kann

Argo CD ist ein guter Ausgangspunkt für eine Anwendungsplattform mit integrierter Oberfläche und generierten Flottendefinitionen. Flux eignet sich besonders als Ausgangspunkt für eine controllerorientierte Plattform mit Helm-Releases, delegierten Kubernetes-Identitäten und kombinierbaren Quellen.

Triff die Entscheidung nach einem fehlgeschlagenen Deployment, einer abgelehnten Mandantenaktion und einer Wiederherstellung. Dort zeigt sich, ob aus einer überzeugenden Funktion ein verlässlicher Betriebsablauf wird.