GitOps mit ArgoCD: Wann es funktioniert (und wann nicht)

Ich werde oft gefragt, ob ein Team ArgoCD einführen soll. Meine Antwort ist selten ein einfaches Ja oder Nein. Sie lautet meistens: "Zeig mir euer Repository-Layout und erkläre mir, wie ihr Secrets verwaltet." Danach ist die Antwort fast immer offensichtlich.

ArgoCD ist kein Deployment-Autopilot, den man in eine laufende Kubernetes-Infrastruktur einsteckt. Es ist ein Werkzeug, das Entscheidungen, die Organisationen längst hätten treffen sollen, sichtbar und schmerzhaft macht. Das ist eine seiner größten Stärken, und es ist der Grund, warum viele Einführungen scheitern.

Dieser Artikel nennt klar, was in der Praxis funktioniert und was nicht. Keine Graubereiche.

Was GitOps eigentlich bedeutet

GitOps ist nicht "Deployment per Git-Commit". Diese Vereinfachung ist das erste und folgenreichste Missverständnis, dem ich in Projekten begegne.

Die OpenGitOps-Initiative, die auf der Pionierarbeit von Weaveworks aufbaut, definiert vier Kernprinzipien: Der Systemzustand ist deklarativ beschrieben. Er ist versioniert und unveränderlich in einem Versionierungssystem gespeichert. Änderungen werden automatisch übernommen. Ein Software-Agent sorgt kontinuierlich für Konvergenz zwischen dem gespeicherten und dem tatsächlichen Zustand.^[1]

Das vierte Prinzip ist das entscheidende und wird am häufigsten übersehen. GitOps ist ein Pull-Modell. ArgoCD pollt das Repository und bringt den Cluster aktiv in den definierten Zustand, kontinuierlich und selbstheilend. Das ist fundamental verschieden von einem Push-basierten CI/CD-Deployment, auch wenn in beiden Fällen Git beteiligt ist.

Jez Humble und David Farley haben in "Continuous Delivery" das konzeptuelle Fundament gelegt: Reproduzierbare, vollständig automatisierte Deployments sind die Voraussetzung für alles andere.^[2] GitOps ist die logische Konsequenz dieser Idee für den Kubernetes-Betrieb. Wer das Prinzip versteht, nutzt ArgoCD richtig. Wer nur das Tool kennt, baut technische Schulden mit GitOps-Branding.

Wann ArgoCD wirklich funktioniert

ArgoCD ist für Kubernetes-native Workloads optimiert. Es liefert dort zuverlässig gute Ergebnisse, wenn die Rahmenbedingungen stimmen.

Mehrere Cluster, ein zentrales Git-Repository als Source of Truth. ArgoCD wurde für genau diesen Anwendungsfall gebaut. Die ApplicationSet-Ressource erlaubt es, eine einzige Konfiguration automatisiert über Dutzende von Clustern auszuspielen.^[4] Für Teams, die im Rahmen einer Kubernetes Beratung Deutschland auf Multi-Cluster-Architekturen setzen, ist das ein konkreter, messbarer operativer Vorteil gegenüber Pipeline-basierten Ansätzen.

Klare Trennung zwischen Platform- und Anwendungsteams. Wenn ein Platform-Team Infrastrukturkomponenten wie Ingress-Controller, cert-manager und Monitoring-Stack in einem dedizierten Repository hält und Anwendungsteams ihre Workloads in eigenen Repositories verwalten, funktioniert ArgoCD als Durchsetzungsschicht zwischen Intention und Zustand. Sam Newman beschreibt unabhängige Deployability als das Kernprinzip des Microservices-Ansatzes.^[3] GitOps macht diese Unabhängigkeit operational, aber nur, wenn die Repository-Struktur die Teamstruktur widerspiegelt.

Compliance und Audit-Anforderungen. Git-History ist ein natürliches, unveränderliches Audit-Log. Jede Zustandsänderung ist versioniert, nachvollziehbar und rückgängig zu machen. Für Organisationen in regulierten Branchen wie Finanzdienstleistungen, kritische Infrastruktur oder Gesundheitswesen ist das kein Nebeneffekt, sondern ein zentrales Argument. Kein anderes Deployment-Modell liefert diesen Audit-Trail ohne zusätzliche Werkzeuge.

Self-Service-Deployment mit reduzierter Angriffsoberfläche. Wenn Entwicklungsteams per Pull-Request deployen können, ohne direkten Cluster-Zugriff zu benötigen, schrumpft die Angriffsoberfläche erheblich. ArgoCD übernimmt den tatsächlichen Cluster-Zugriff mit einem Service-Account mit minimalen Berechtigungen. Das ist das Least-Privilege-Prinzip in der Produktionspraxis, nicht in der Theorie.

Wann es scheitert

Die folgende Liste beschreibt keine theoretischen Risiken. Es sind wiederkehrende Muster aus echten Projekten.

Kein deklarativer Ansatz in der Anwendungsschicht. Wenn Anwendungen Zustand über undokumentierte Datenbankmigrations-Skripte, manuelle kubectl-Patches oder imperativ verwaltete Konfiguration erzeugen, kann ArgoCD den tatsächlichen Systemzustand nicht vollständig über Git repräsentieren. Der Sync-Status wird zum Lügendetektor: "Synced" bedeutet dann, dass Kubernetes-Manifeste übereinstimmen, nicht dass die Anwendung korrekt läuft. Teams, die diesen Unterschied nicht kennen, verlieren das Vertrauen in den gesamten Prozess.

Organisatorische Unklarheit über Verantwortlichkeiten. GitOps erfordert präzise Antworten auf zwei Fragen: Wer darf in welches Repository schreiben? Welches Repository bestimmt den Deployment-Status einer Umgebung? In Organisationen mit gewachsenen Infrastrukturstrukturen und verschiedenen Deployment-Wegen für verschiedene Teams löst ArgoCD das organisatorische Problem nicht. Es macht es sichtbar und schmerzhaft. Das ist gut, aber ohne Reorganisation der Verantwortlichkeiten bleibt ArgoCD ein teures Symptom-Monitoring-Werkzeug.

Secrets-Management als Nachgedanke. ArgoCD synchronisiert alles, was in Git steht. Secrets gehören nicht in Git, auch nicht in verschlüsselter Form, es sei denn, man hat eine explizite, abgestimmte Strategie: Sealed Secrets, External Secrets Operator mit einem Cloud-Provider-Secret-Store oder HashiCorp Vault. Teams, die Secrets-Management bei der ArgoCD-Einführung als späteres Problem einstufen, enden in einem Hybridmodell. Manifeste laufen über ArgoCD, Secrets werden per CI-Pipeline oder manuell per kubectl eingespielt. Das ist kein GitOps. Es ist GitOps für alles außer dem Kritischsten.

Fehlverstandenes Drift-Management. ArgoCD erkennt Abweichungen zwischen dem Git-Zustand und dem Cluster-Zustand. Wenn Teams ArgoCD im Auto-Sync-Modus mit Self-Heal betreiben, ohne zu verstehen, was der Agent bei Drift zurücksetzt, entstehen schwer zu debuggende Situationen. Ein Kubernetes-Operator verändert legitim eine Ressource. ArgoCD überschreibt die Änderung. Die Anwendung bricht. Die Lösung ist kein genereller Verzicht auf Auto-Sync. Die Lösung ist ein explizites Modell darüber, welche Ressourcen von ArgoCD verwaltet werden und welche nicht, dokumentiert, testbar und abgestimmt.

Monorepos ohne Strategie. Ein einzelnes Git-Repository für viele Anwendungen und mehrere Cluster ist technisch möglich. Operativ ist es ein Wartungsalbtraum. Jeder Commit löst potenziell Syncs für alle Anwendungen aus. Pull-Request-Reviews werden unhandlich. Branch-Strategien explodieren in Komplexität. Die Empfehlung ist eindeutig: ein Repository pro Team oder pro Bounded Context, Aggregation über ArgoCD ApplicationSets.^[4]

Klare Empfehlungen für den Einstieg

Wer heute im Kontext einer Kubernetes Beratung Deutschland ArgoCD einführt, sollte diese Reihenfolge einhalten.

Platform-Repository zuerst, Geschäftsanwendungen später. Der erste ArgoCD-Use-Case sollte der Monitoring-Stack, der Ingress-Controller und cert-manager sein, nicht die Geschäftsanwendung. Das gibt dem Team Zeit, ArgoCD-Konzepte wie App-of-Apps-Muster, Health Checks, Sync-Waves und Resource-Hooks in einem kontrollierten Umfeld zu verstehen, bevor das Deployment der umsatzrelevanten Anwendung auf dem Spiel steht.

Sync-Policies explizit und bewusst definieren. Auto-Sync mit Pruning und Self-Heal ist mächtig. Es ist auch gefährlich für Teams, die Drift-Szenarien noch nicht durchgespielt haben. Empfehlung für den Start: manueller Sync mit Alerts bei Drift. Automatisierung kommt, wenn das Team versteht, was sie automatisiert.

Secrets-Management vor der ArgoCD-Einführung abschließen. External Secrets Operator mit HashiCorp Vault oder einem Cloud-Provider-Secret-Store ist die empfohlene Produktionslösung. Sealed Secrets sind akzeptabel für kleinere Teams ohne Vault-Infrastruktur. Keine Lösung ist keine Option.

Repository-Struktur folgt Team-Topologie, nicht Technologie. Ein Repository für "alle Helm-Charts" ist eine technische Sichtweise. Ein Repository für "Team Payments" ist eine organisatorische Sichtweise. Letztere skaliert mit der Organisation, Erstere wird zum Flaschenhals.^[3]

Manifest-Validierung in den Pull-Request-Prozess integrieren. Kubeconform, Conftest mit OPA-Policies und Helm-Template-Validierung verhindern, dass ArgoCD valide, aber falsch konfigurierte Manifeste in den Cluster synchronisiert. ArgoCD ist kein Linter. Es führt aus, was Git sagt.

Fazit

ArgoCD ist eine ausgereifte Lösung für Teams, die Kubernetes-Deployments deklarativ, auditsicher und operativ kontrolliert gestalten wollen. Es ist kein Werkzeug, das man einer laufenden Infrastruktur hinzufügt und erwartet, dass es Ordnung schafft. Die Entscheidung für GitOps mit ArgoCD ist eine Architekturentscheidung mit direkten Konsequenzen für Team-Topologie, Repository-Struktur, Secrets-Management und Compliance-Anforderungen.

Wer diese Grundlagen legt, bevor ArgoCD den ersten Sync ausführt, wird eine stabile Deployment-Plattform aufbauen, die die kognitive Last auf Operations-Teams dauerhaft reduziert.^[2] Wer sie ignoriert, hat bestehende Probleme nur mit einer Git-URL versehen.

Quellen

[1] OpenGitOps Working Group: GitOps Principles v1.0.0, Cloud Native Computing Foundation (CNCF), 2021. https://opengitops.dev

[2] Jez Humble, David Farley: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley Professional, 2010.

[3] Sam Newman: Building Microservices: Designing Fine-Grained Systems, 2. Auflage, O'Reilly Media, 2021.

[4] Argo CD Project: ApplicationSet Controller, Argo CD Documentation, 2024. https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/

[5] Alexis Richardson: GitOps: Operations by Pull Request, Weaveworks Blog, 2017. https://www.weave.works/blog/gitops-operations-by-pull-request