--- status: "accepted (Beispiel)" date: 2026-11-13 decision-makers: "fiktive Rollen: Plattformverantwortliche, Leitung Anwendungsentwicklung" consulted: "fiktive Rollen: Sicherheit, Betrieb" informed: "fiktive Rollen: Anwendungsteams" --- # GitOps-Werkzeug: Argo CD vs. Flux > **Beispiel-ADR, kein Kundenprojekt.** Dieses Dokument zeigt, wie SKAFFON Architekturentscheidungen im Format [MADR 4.0.0](https://adr.github.io/madr/) festhält. Kontext, Annahmen und Rollen sind **fiktiv**. Die technischen Aussagen zu den Werkzeugen stützen sich auf die verlinkte Projektdokumentation (Stand der Prüfung: 13. November 2026). Beide Werkzeuge sind für den Produktionseinsatz geeignet; die Entscheidung gilt nur unter den genannten Annahmen und ist keine allgemeine Empfehlung. ## Context and Problem Statement Angenommen wird ein Plattformteam, das mehrere Kubernetes-Cluster für mehrere Anwendungsteams betreibt. Konfiguration und Anwendungs-Deployments sollen deklarativ in Git liegen und von dort automatisch abgeglichen werden (GitOps). Die Anwendungsteams wollen den Abgleichsstand ihrer Anwendungen selbst einsehen, ohne Zugriff auf Cluster-Interna zu erhalten; Anmeldung soll über das zentrale Identitätssystem (OIDC) laufen; Änderungen und Eingriffe müssen nachvollziehbar sein. Welches GitOps-Werkzeug setzen wir als Standard auf der Plattform ein: Argo CD oder Flux? ## Decision Drivers * **Sichtbarkeit für Anwendungsteams:** Einsehbarer Zustand (synchron, abweichend, fehlerhaft) je Anwendung, ohne dass jedes Team Cluster-Zugriff braucht. * **Mandantenfähigkeit und Berechtigungen:** Klare Trennung zwischen Teams; Zugriffsmodell, das sich mit dem zentralen Identitätssystem verbinden lässt. * **Multi-Cluster-Betrieb:** Viele Cluster und viele Anwendungen mit wiederholbarer Definition. * **Betriebsaufwand:** Anzahl der Komponenten, Upgrade-Pfad, Fehlersuche. * **Sicherheit:** Umgang mit Zugangsdaten zu Clustern und Repositories; Rechte des Abgleichs. * **Ökosystem:** Unterstützung für Helm, Kustomize, OCI-Artefakte, Benachrichtigungen, Progressive Delivery. ## Considered Options * Argo CD * Flux ## Decision Outcome Gewählte Option: „Argo CD“, weil unter den angenommenen Randbedingungen (mehrere Anwendungsteams mit Bedarf an einer gemeinsamen Oberfläche zum Abgleichsstand, zentrale Anmeldung per OIDC, Multi-Cluster-Betrieb) die mitgelieferten Bestandteile (Web-Oberfläche, API-Server mit RBAC und SSO, ApplicationSets) den Aufbau einer eigenen Sichtbarkeits- und Zugriffsschicht ersparen. Die Entscheidung ist **an diese Annahmen gebunden**. Flux wäre die bessere Wahl, wenn Anwendungsteams keine Oberfläche benötigen, die Steuerung ausschließlich über Kubernetes-Ressourcen und die Kommandozeile erfolgen soll, die Mandantentrennung über Kubernetes-RBAC mit Impersonation im Vordergrund steht oder OCI-Artefakte der zentrale Verteilungsweg sind. ### Consequences * Good, because Anwendungsteams den Zustand ihrer Anwendungen über die Web-Oberfläche oder CLI einsehen können; Anmeldung ist laut Dokumentation per SSO-Integration (OIDC, OAuth2, LDAP, SAML 2.0 und weitere) möglich, und Berechtigungen werden über Multi-Tenancy- und RBAC-Richtlinien gesteuert. * Good, because Anwendungen als eigene Ressourcen beschrieben werden und über ApplicationSets (Generatoren) für viele Cluster und Umgebungen erzeugt werden können. * Good, because Abweichungen zwischen Soll-Zustand in Git und Ist-Zustand erkannt und sichtbar gemacht werden; Rollback auf frühere, in Git festgehaltene Stände möglich ist. * Bad, because Argo CD als zentrale Instanz eine hochprivilegierte Komponente ist: Zugangsdaten für Repositories und Ziel-Cluster werden laut Architekturdokumentation als Kubernetes-Secrets verwaltet. Der Schutz dieser Instanz (Zugriff, Netz, Upgrades, Absicherung des API-Servers) wird zur Pflichtaufgabe. * Bad, because der Betrieb aus mehreren Komponenten besteht (unter anderem API-Server, Repository-Server, Application-Controller), deren Sizing und Wartung zu betreiben sind. * Bad, because ein späterer Wechsel zu Flux die Neubeschreibung der Anwendungsdefinitionen erfordert; die Manifeste in Git (Helm, Kustomize, YAML) bleiben dabei erhalten. ### Confirmation * Review des Repository-Layouts und der Argo-CD-Konfiguration (Projekte, RBAC-Richtlinien, SSO-Anbindung) gegen diese Entscheidung. * Prüfung, dass Anwendungsteams ausschließlich auf ihre Projekte zugreifen können (Stichprobentest mit einem Konto je Team). * Test der Drift-Erkennung und des Rollbacks an einer Testanwendung. * Prüfung der Absicherung der zentralen Instanz (Netzzugang, Zugangsdaten-Verwaltung, Audit-Protokolle) im jährlichen Plattform-Review. ## Pros and Cons of the Options ### Argo CD [Argo CD](https://argo-cd.readthedocs.io/) ist laut Dokumentation ein deklaratives GitOps-Werkzeug für die kontinuierliche Bereitstellung auf Kubernetes. Es ist als Kubernetes-Controller implementiert, der laufende Anwendungen laufend mit dem Soll-Zustand aus Git vergleicht; abweichende Anwendungen gelten als `OutOfSync`. Vgl. [Überblick](https://argo-cd.readthedocs.io/en/stable/), [Architektur](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/), [ApplicationSet](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/), [RBAC](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/). * Good, because Web-Oberfläche, CLI und API-Server (gRPC/REST) zum Lieferumfang gehören. * Good, because SSO, Multi-Tenancy, RBAC, Audit-Trails für Anwendungsereignisse und API-Aufrufe sowie Prometheus-Metriken dokumentiert sind. * Good, because Kustomize, Helm, Jsonnet, einfache YAML-Verzeichnisse und eigene Konfigurationsplugins unterstützt werden, ebenso das Verfolgen von Branches, Tags oder fest gepinnten Commits ([Tracking-Strategien](https://argo-cd.readthedocs.io/en/stable/user-guide/tracking_strategies/)). * Good, because Sync-Hooks (PreSync, Sync, PostSync) komplexere Rollouts unterstützen. * Neutral, because Multi-Cluster-Betrieb über eine zentrale Instanz möglich ist; das bündelt Sichtbarkeit, aber auch Berechtigungen. * Bad, because die zentrale Instanz Zugangsdaten für viele Cluster hält (siehe Consequences). ### Flux [Flux](https://fluxcd.io/flux/) hält laut Dokumentation Kubernetes-Cluster mit Konfigurationsquellen (etwa Git-Repositories) synchron und automatisiert Aktualisierungen. Es ist aus den Komponenten des [GitOps Toolkit](https://fluxcd.io/flux/components/) aufgebaut: Source-, Kustomize-, Helm-, Notification- und Image-Automation-Controller, gesteuert über Kubernetes-Ressourcen wie `GitRepository`, `Kustomization` und `HelmRelease`. Die Dokumentation beschreibt Flux als CNCF-Projekt der Stufe „Graduated“. * Good, because der Aufbau aus eigenständigen Controllern mit Kubernetes-Ressourcen als einziger Schnittstelle sehr gut in bestehende Kubernetes-Werkzeuge und -Prozesse passt. * Good, because Mandantentrennung laut Dokumentation über Kubernetes-RBAC mit Impersonation erfolgt und mehrere Git-Repositories unterstützt werden ([Sicherheit](https://fluxcd.io/flux/security/)). * Good, because neben Git auch OCI-Artefakte und S3-kompatible Buckets als Quellen dienen können und automatisierte Aktualisierungen von Container-Images mit Rückschreiben nach Git vorgesehen sind. * Good, because Benachrichtigungen (zum Beispiel an Chat-Systeme) und eingehende Webhooks Teil des Toolkits sind; Flagger ergänzt Progressive Delivery. * Neutral, because für Oberflächen auf Projekte des Ökosystems verwiesen wird ([Flux UIs](https://fluxcd.io/ecosystem/)); eine Oberfläche gehört nicht zum Kern. * Bad, because für das angenommene Bedürfnis der Anwendungsteams nach einer gemeinsamen Sicht auf den Abgleichsstand zusätzliche Werkzeuge ausgewählt, betrieben und abgesichert werden müssten. ## More Information * Zu überprüfen, wenn sich die Annahmen ändern: Anwendungsteams benötigen keine Oberfläche mehr, die Zahl der Cluster oder die Anforderungen an Mandantentrennung steigen deutlich, oder OCI-Artefakte werden zum Standardweg der Bereitstellung. * Beide Werkzeuge sind laut Dokumentation und Projektumfeld etabliert; die Wahl ist eine Frage der Passung zum Betriebsmodell, nicht der grundsätzlichen Eignung. * Quellen (geprüft am 13. November 2026): [Argo CD-Dokumentation](https://argo-cd.readthedocs.io/en/stable/), [Flux-Dokumentation](https://fluxcd.io/flux/).