GitOps mit Argo CD oder eine Control Plane? Was Teams ohne Platform-Team wirklich brauchen

Ein SaaS-Team, vier Entwickler, zwei Cluster auf Scaleway, kein Platform-Team. Im Sprint-Review fällt der Satz: „Lasst uns GitOps machen, mit Argo CD.“ Drei Wochen später gibt es ein zweites Repository mit 140 YAML-Dateien, eine offene Diskussion über Sealed Secrets oder SOPS – und niemanden, der sagen kann, wer Argo CD selbst aktualisiert. Das Projekt bringt alle drei Monate eine neue Minor-Version heraus, Patches gibt es nur für die letzten drei.

GitOps ist ein Betriebsmodell, in dem der gewünschte Zustand eines Systems deklarativ und versioniert in Git liegt und ein Agent im Cluster ihn selbstständig abholt und laufend herstellt. Die Frage hier ist nicht, ob das gut ist – es ist gut –, sondern ob es zu einem Team passt, in dem sich niemand hauptberuflich um die Plattform kümmert.

Was ist GitOps, und was macht Argo CD dabei?

Die Initiative OpenGitOps fasst GitOps in vier Prinzipien:

• Deklarativ: Der Zielzustand ist beschrieben, nicht als Folge von Befehlen.
• Versioniert und unveränderlich: Jede Fassung bleibt mit vollständiger Historie erhalten.
• Automatisch abgeholt: Ein Agent zieht den Zustand aus der Quelle – niemand schiebt ihn per kubectl apply in den Cluster.
• Laufend abgeglichen: Der Agent vergleicht Soll und Ist und stellt das Soll wieder her.

Argo CD und Flux sind die bekanntesten dieser Agenten. Argo CD prüft das Repository standardmäßig alle 120 Sekunden plus bis zu 60 Sekunden Zufall. Der automatische Sync ist optional, und auch mit ihm bleiben das Löschen überflüssiger Objekte (prune) und das Zurücksetzen von Handänderungen (selfHeal) aus, bis man sie einschaltet.

Was GitOps gut kann

• Review per Pull Request: Jede Änderung am Cluster ist ein Diff, den jemand freigibt.
• Historie: Das Git-Log ist das Änderungsprotokoll, ein Revert der Rollback.
• Drift-Korrektur: Mit Self-Heal verschwindet eine Handänderung im Cluster nach wenigen Sekunden wieder.
• Viele Cluster: Ein Repository, zwanzig Cluster, dieselben Regeln – dafür wurde das Modell gebaut.
• Wiederaufbau: Ein neuer Cluster wird aus dem Repository befüllt, nicht aus dem Gedächtnis.

Für eine Organisation mit Platform-Team ist das ein starkes Paket. Die Rechnung sieht anders aus, wenn dieselben vier Leute auch die Features bauen.

Was kostet GitOps ein Team ohne Platform-Team?

• Repository-Struktur: Ordner pro Umgebung, Kustomize-Overlays oder Helm-Values, App-of-Apps – eine Architekturentscheidung, die sich später nur mühsam ändern lässt.
• Secrets in Git: Klartext geht nicht, also Sealed Secrets, SOPS oder der External Secrets Operator. Argo CD selbst empfiehlt, Secrets im Zielcluster zu befüllen statt beim Rendern der Manifeste.
• Neue Images: Jedes Release wird zu einem zweiten Commit – CI baut das Image und muss den neuen Tag ins Konfigurations-Repository schreiben.
• Argo CD betreiben: Upgrades alle drei Monate, RBAC, Single Sign-on und ein Dienst mit weitreichenden Rechten im Cluster, der selbst überwacht werden will.
• Lernkurve: Sync-Waves, Hooks, ignoreDifferences für Felder, die ein Controller selbst setzt – Wissen, das in kleinen Teams oft bei einer Person liegt.
• Zwei Uhr nachts: Hängt ein Sync, braucht es jemanden, der Argo CD, Git und Kubernetes zugleich versteht.

Die Alternative: der gewünschte Zustand im Produkt

Eine Control Plane dreht das Modell um. Der gewünschte Zustand liegt nicht in Git, sondern in der Datenbank des Produkts; geändert wird er über eine Oberfläche oder eine API. Damit das keine Blackbox wird, braucht sie vier Dinge, die GitOps über Git bekommt:

• Ein Audit-Log statt der Git-Historie: wer was wann geändert hat, Person oder Token.
• Eine Konfigurationsprüfung statt Drift-Erkennung: das Gespeicherte gegen den Live-Cluster, Feld für Feld.
• API-Tokens für CI statt Commit-Bot: Die Pipeline löst den Deploy direkt aus.
• Versionen per Digest statt Revert: Eine frühere Version kommt in einem Schritt zurück.

So arbeitet Clusterward auf Scaleway. Apps kommen aus Git – im Cluster ohne Docker-Daemon gebaut oder per GitHub Actions –, als Container-Image oder als Helm-Chart. Images aus der Registry des Clusters werden per Digest ausgerollt, und „Restore this version“ bringt eine frühere gesunde Version ohne neuen Build zurück; warum das mit einem Tag nicht geht, erklärt der Beitrag Rollback auf Kubernetes: Warum ein Tag keine Version ist. Eine Pipeline startet Deploys mit einem API-Token, das eine Rolle, eine Auswahl an Anwendungen und ein Ablaufdatum hat; jede Änderung landet im Audit-Log (Sicherheit & Zugriff). Die Konfigurationsprüfung zeigt, wo der Cluster vom Gespeicherten abweicht.

Was Clusterward nicht ist

Clusterward ist kein GitOps-Werkzeug. Es gibt kein Repository, aus dem der Zustand gezogen wird; der JSON-Export der Konfiguration dokumentiert, er stellt nichts wieder her. Die Konfigurationsprüfung korrigiert nichts von selbst – „Deploy & re-check“ startet ein Mensch. Und Canary- oder Blue-Green-Deployments gibt es nicht: Ein Rollout ersetzt die Pods. Was der Deploy-Weg genau abdeckt, zeigt die Seite Deployments.

Wann ist GitOps die bessere Wahl?

• Es gibt ein Platform-Team, das Argo CD oder Flux als Produkt für die Entwickler betreibt.
• Sie betreiben viele Cluster, über mehrere Clouds oder Regionen hinweg.
• Infrastruktur ist bei Ihnen ohnehin Code: Terraform, Pull Requests, Vier-Augen-Prinzip für jede Änderung.
• Ihr Change-Management verlangt eine Freigabe pro Änderung, die als Pull Request nachweisbar ist.
• Sie brauchen Canary- oder Blue-Green-Releases mit schrittweiser Umschaltung – im Argo-Umfeld liefert das Argo Rollouts.

In diesen Fällen wäre eine Control Plane ohne Git der falsche Kompromiss.

Argo CD oder Control Plane: eine Entscheidungsliste

1. Wer pflegt das Delivery-Werkzeug in einem Jahr? Steht hier kein Name, zählt jede Komponente doppelt.
2. Wie viele Cluster sind es in zwei Jahren? Unter fünf trägt das Multi-Cluster-Argument wenig.
3. Muss jede Änderung per Pull Request freigegeben werden – per Regel, nicht aus Gewohnheit?
4. Wo liegen Ihre Secrets heute, und wer darf sie lesen?
5. Brauchen Sie Canary-Releases, oder reicht ein schneller Rollback?
6. Kommt jemand ohne Kubernetes-Wissen nachts auf die vorige Version zurück?

Wer bei Frage 1 keinen Namen hat, bei Frage 2 unter fünf bleibt und bei Frage 5 „Rollback reicht“ sagt, ist mit einer Control Plane meist schneller in Produktion – und bleibt es. Wer bei Frage 3 „ja, per Regel“ antwortet, sollte GitOps ernsthaft prüfen. Aufwand und Kosten gegenüber einer selbst gebauten Plattform vergleicht die Seite Clusterward vs. Eigenbau.

Fazit

GitOps ist ein gutes Modell mit einem Preis: ein zweites Repository, eine Secret-Strategie und ein Werkzeug, das gepflegt werden will. Teams mit Platform-Team zahlen ihn gern. Teams ohne brauchen vor allem, was GitOps nebenbei liefert – Nachvollziehbarkeit, einen Abgleich mit dem Cluster, einen schnellen Rollback –, und das bekommen sie auch ohne Git als Quelle der Wahrheit.

Sie überlegen, ob Argo CD zu Ihrem Team passt? Beschreiben Sie uns Ihr Setup – wir sagen Ihnen ehrlich, wann GitOps die bessere Wahl ist. Frage stellen →

Quellen und weiterführende Links

• OpenGitOps: die GitOps-Prinzipien (englisch)
• Argo CD: Automated Sync (englisch)
• Argo CD: Secret Management (englisch)
• Argo CD: Release-Rhythmus (englisch)
• Argo Rollouts: Canary und Blue-Green (englisch)