GitOps mit ArgoCD und Flux — Continuous Deployment für den Mittelstand

Wer im Jahr 2026 Kubernetes-Anwendungen noch über klassische Push-Pipelines mit kubectl-apply-Schritten ausrollt, kämpft mit drei wiederkehrenden Problemen: niemand weiß genau, was im Cluster läuft, manuelle Hotfixes erzeugen unsichtbare Drift, und Rollbacks dauern länger als der eigentliche Vorfall. GitOps ist die Antwort, die sich seit etwa 2019 in der Branche durchgesetzt hat und mittlerweile zu einem CNCF-anerkannten Betriebs-Standard geworden ist. Der Kern-Gedanke ist radikal einfach: Git ist die einzige Wahrheits-Quelle für den gewünschten Cluster-Zustand, und ein Controller im Cluster gleicht den tatsächlichen Zustand kontinuierlich mit dem Git-Inhalt ab. Zwei Werkzeuge dominieren den Markt — ArgoCD und Flux, beide CNCF-graduated und production-erprobt in Tausenden Unternehmen. Dieser Artikel zeigt, wie sich GitOps mit beiden Werkzeugen im Mittelstand sinnvoll aufsetzen lässt, wie sie sich unterscheiden, welche Repo-Struktur trägt und wie Secrets, Multi-Cluster und Progressive Delivery dazupassen. Für die Einordnung in die Gesamt-Plattform siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Was GitOps ist — Pull statt Push, Git als einzige Wahrheits-Quelle

GitOps ist kein Werkzeug, sondern ein Betriebs-Modell. Es beruht auf vier Prinzipien, die die CNCF-OpenGitOps-Arbeitsgruppe 2022 formal beschrieben hat: das gewünschte System-Verhalten ist deklarativ beschrieben, der gewünschte Zustand ist versioniert und unveränderlich, Änderungen werden automatisch übernommen, und Software-Agenten gleichen kontinuierlich den Ist-Zustand mit dem Soll-Zustand ab. Diese vier Prinzipien klingen abstrakt, ihre operative Konsequenz ist konkret: niemand greift mehr direkt mit kubectl in den Cluster, jede Änderung ist ein Pull-Request gegen ein Git-Repository, der nach Merge automatisch im Cluster wirksam wird.

Der zentrale technische Unterschied zu klassischer CD ist das Pull-Modell. In einer typischen Jenkins- oder GitHub-Actions-Pipeline pusht der Build-Server am Ende des Jobs Manifeste in den Cluster — das bedeutet, der Build-Server braucht Cluster-Credentials, ist von außerhalb des Clusters erreichbar und ist gleichzeitig CI-System und Deploy-Akteur. Im Pull-Modell läuft der GitOps-Controller (ArgoCD oder Flux) innerhalb des Clusters, beobachtet das Git-Repo und holt sich Änderungen aktiv ab. Der Cluster braucht keine eingehenden Cluster-Credentials für externe Systeme mehr, die Angriffsfläche schrumpft erheblich, und die Trennung zwischen CI (Code-Build, Tests, Container-Image-Bau) und CD (Cluster-Sync) wird sauber.

Operativ heißt das: das CI-System endet damit, dass ein neues Container-Image in eine Registry gepusht wird und das Config-Repo mit der neuen Image-Version aktualisiert wird (entweder via Pull-Request oder via Image-Updater-Komponente). Ab dort übernimmt der GitOps-Controller. Wer GitOps ernsthaft macht, hat in seinem Cluster keinen menschlichen Schreib-Zugang mehr — alle Änderungen passieren über Pull-Requests gegen das Config-Repo, mit Review, mit Audit-Log, mit Begründung im Commit-Message-Body.

Vorteile — Audit, Reproducibility, Rollback

Drei operative Eigenschaften machen GitOps für mittelständische Unternehmen so attraktiv. Erstens die Audit-Fähigkeit: jede Änderung am Produktiv-System ist ein Git-Commit mit Autor, Zeitstempel, Reviewer und Begründung. Bei einem DSGVO- oder ISO-27001-Audit ist die Frage „Wer hat am 14. März diese Konfiguration geändert?“ in Sekunden beantwortet, ohne Logs aus drei Systemen korrelieren zu müssen. Das ist nicht nur für externe Audits relevant, sondern beschleunigt jede interne Forensik.

Zweitens die Reproduzierbarkeit: weil der Soll-Zustand vollständig in Git liegt, lässt sich ein Cluster jederzeit aus dem Repo rekonstruieren. Im Disaster-Recovery-Szenario reicht das Provisionieren eines neuen Clusters und das Anwenden des Bootstrap-Manifests, der Rest läuft automatisch. In Verbindung mit unserem Artikel zum Zero-Downtime-Deployment ergibt das ein operatives Setup, in dem Cluster-Verluste in Stunden statt Tagen behandelt werden.

Drittens die Rollback-Geschwindigkeit. Ein Rollback ist im GitOps-Modell ein git revert auf das problematische Config-Commit, gefolgt von einem automatischen Sync. Der gesamte Vorgang dauert in der Praxis zwei bis fünf Minuten, ist vollständig auditierbar und braucht keinen manuellen kubectl-Eingriff. Diese drei Eigenschaften zahlen sich auch im Single-Cluster-Setup unmittelbar aus, der Wert steigt mit jeder zusätzlichen Umgebung weiter an.

ArgoCD — Architektur, Applications, ApplicationSets, Sync-Wellen

ArgoCD ist der derzeit am weitesten verbreitete GitOps-Controller, ursprünglich bei Intuit entwickelt und 2022 zum CNCF-Graduated-Projekt aufgestiegen. Architektonisch besteht ArgoCD aus fünf Hauptkomponenten: dem API-Server (die Web-UI und gRPC-API), dem Repository-Server (klont und cached Git-Repos), dem Application-Controller (vergleicht Soll- und Ist-Zustand und synct), dem Redis-Cache und der Web-UI. Alle Komponenten laufen im Cluster und brauchen lediglich ausgehenden Zugriff auf das Git-Repo und die Container-Registry.

Die zentrale Ressource ist die Application — eine Custom Resource, die festlegt, welches Git-Repo, welcher Pfad und welches Ziel-Cluster zusammen eine Anwendung definieren. Für mehr als ein paar Anwendungen wird das schnell unübersichtlich, deshalb gibt es das App-of-Apps-Muster: eine Root-Application, die einen Ordner im Repo beobachtet, in dem weitere Application-Manifeste liegen. So lässt sich der gesamte Cluster-Inhalt deklarativ in einem einzigen Bootstrap-Schritt installieren.

Für skalierende Setups gibt es die ApplicationSet-Ressource, die ein Template plus einen Generator kombiniert. Der Generator kann eine Liste sein, ein Git-Verzeichnis, ein Cluster-Set oder ein Pull-Request. Das ermöglicht Muster wie „für jeden Cluster im Argo-Verzeichnis erzeuge automatisch eine Plattform-Dienste-Application“ oder „für jeden Branch im Feature-Repo erzeuge automatisch eine Preview-Umgebung“. Für Multi-Cluster- und Multi-Tenant-Setups ist ApplicationSet das entscheidende Werkzeug.

Sync-Wellen sind die ArgoCD-Antwort auf Abhängigkeiten: Manifeste lassen sich mit einer argocd.argoproj.io/sync-wave-Annotation versehen, ArgoCD wendet sie dann in aufsteigender Wellen-Reihenfolge an. Das ist wichtig, wenn etwa Namespaces, CRDs und Operatoren vor den Anwendungen installiert werden müssen, die sie nutzen. In Kombination mit den Sync-Hooks (PreSync, Sync, PostSync, SyncFail) entsteht ein deklaratives Abhängigkeits-Modell, das auch komplexe Roll-outs sauber abbildet.

Flux — Architektur, Sources, Kustomizations, HelmReleases

Flux entstand bei Weaveworks (das den Begriff GitOps 2017 geprägt hat) und ist heute ein eigenständiges CNCF-Graduated-Projekt. Architektonisch unterscheidet sich Flux deutlich von ArgoCD: statt einer monolithischen Anwendung mit UI besteht Flux aus vier unabhängigen Controllern (Source-Controller, Kustomize-Controller, Helm-Controller, Notification-Controller), die jeweils einen klar abgegrenzten Aspekt verantworten. Es gibt keine eingebaute UI — Statusabfragen passieren via flux-CLI oder über die Drittsoftware Weave GitOps Dashboard.

Die zentralen Ressourcen sind GitRepository und HelmRepository (Sources, die der Source-Controller klont und auf neue Versionen prüft), Kustomization (die der Kustomize-Controller anwendet) und HelmRelease (die der Helm-Controller installiert und upgradet). Diese Trennung ist konzeptionell sauber und macht Flux gut testbar — jeder Controller ist eigenständig deploybar und in den Cluster-RBAC fein integrierbar.

Flux ist von Anfang an für Multi-Cluster-Setups konzipiert: mit dem Bootstrap-Kommando (flux bootstrap) wird ein Cluster initial mit allen Flux-Komponenten plus dem Verweis auf das Config-Repo versorgt, ab dort verwaltet sich der Cluster selbst aus dem Repo. Für Setups mit identischer Konfiguration über viele Cluster (etwa Edge-Setups oder Multi-Region-Produktion) ist Flux durch seine schlanke Architektur und seine GitOps-native Bootstrap-Routine oft die effizientere Wahl.

ArgoCD vs Flux — Direktvergleich

Beide Werkzeuge sind production-grade und decken die GitOps-Kern-Funktionalität vollständig ab. Die Unterschiede liegen in der Bedien-Philosophie, der UI-Verfügbarkeit und der Multi-Cluster-Bootstrap-Routine. Die folgende Tabelle fasst die wichtigsten Differenz-Punkte zusammen:

Kriterium	ArgoCD	Flux
Web-UI	Vollwertig mitgeliefert, Sync-Status und Rollbacks klickbar	Keine eingebaute UI, optional Weave GitOps Dashboard
Architektur	Monolithisch (API-Server, Repo-Server, Application-Controller)	Komponenten-basiert (Source, Kustomize, Helm, Notification)
Multi-Cluster	Hub-and-Spoke (ein ArgoCD verwaltet mehrere Cluster)	Cluster-lokal, jeder Cluster managed sich selbst
Multi-Tenancy	AppProjects, fein granulare RBAC, SSO-Integration	Namespace-basiert, Kubernetes-RBAC
Helm-Support	Render-Modus, Charts werden zu Manifesten	Native HelmRelease mit echtem Helm-Release-Lifecycle
Image-Updates	Argo Image Updater (Add-On)	Image-Reflector und Image-Automation eingebaut
Lernkurve	UI macht Einstieg einfach	CLI-orientiert, etwas steiler

Praktische Empfehlung aus unseren Beratungs-Projekten: wer eine Plattform-Mannschaft mit ein bis zwei Personen hat und die Anwendungs-Teams selbst Sync-Status und Rollbacks einsehen können sollen, fährt mit ArgoCD klar besser. Wer eine GitOps-erfahrene Plattform-Mannschaft hat, viele Cluster mit identischer Konfiguration ausrollt und das Komponenten-Modell als Vorteil sieht, fährt mit Flux besser. In hybriden Setups gibt es auch Konstellationen, wo ArgoCD für die Anwendungs-Teams und Flux für die Plattform-Schicht eingesetzt wird.

Repo-Struktur — App-of-Apps, Monorepo, Env-Branching

Die Repo-Struktur entscheidet maßgeblich darüber, ob ein GitOps-Setup nach sechs Monaten noch wartbar ist. Drei Muster haben sich etabliert, und nicht jedes passt zu jedem Unternehmen. Die folgende Übersicht zeigt die wichtigsten Entscheidungs-Achsen:

• App-Code und Config getrenntDer Quellcode der Anwendung lebt in einem Application-Repo (mit Dockerfile, Helm-Chart-Template, Tests), die ausgerollten Manifeste leben in einem separaten Config-Repo, das nur GitOps-Controller beobachten. Diese Trennung ist die wichtigste Strukturentscheidung — sie vermeidet, dass jeder Code-Commit automatisch zu einem Deploy führt, und sie hält die Berechtigungen klar (Anwendungs-Entwickler schreiben am App-Repo, Plattform-Team prüft am Config-Repo).
• Config-Repo als MonorepoIm Config-Repo werden alle Anwendungen, Plattform-Dienste und Cluster-Konfigurationen zentral verwaltet. Das ist für mittelständische Setups bis etwa 100 Anwendungen die bevorzugte Lösung — gemeinsame Reviews, übergreifende Refactorings und ein konsistenter PR-Workflow sind so wesentlich einfacher als bei einem Repo pro Anwendung.
• App-of-Apps oder Kustomization-HierarchieEine Root-Application (ArgoCD) oder Root-Kustomization (Flux) zeigt auf ein Verzeichnis, in dem weitere Application- oder Kustomization-Definitionen liegen. So lässt sich ein Cluster mit einem einzigen Bootstrap-Schritt vollständig ausstatten — keine 50 manuellen kubectl-applys, sondern ein deklarativer Einstiegspunkt.
• Umgebungen als Ordner, nicht als BranchesDev, Staging und Prod sind eigene Ordner mit Kustomize-Overlays oder Helm-Values, nicht eigene Branches. Branches als Umgebungs-Trenner sind ein verbreiteter Anti-Pattern — sie erzeugen schwer aufzulösende Drift, weil Cherry-Picks und Merges zwischen den Branches nie sauber bleiben.
• Promotion via Pull-RequestEine neue Image-Version landet zuerst im Dev-Overlay, ein automatischer PR aktualisiert dann das Staging-Overlay, nach Tests wird der Prod-Overlay-PR manuell freigegeben. So ist jeder Promotions-Schritt ein nachvollziehbarer Git-Vorgang mit Reviewer und Begründung.

Für die Anbindung an das vorgelagerte CI siehe unseren Artikel zu CI/CD-Pipeline aufbauen — die Build-Schritte enden mit einem Container-Push und einem Config-Repo-Update, ab dort übernimmt der GitOps-Controller. Diese saubere Trennung ist der wichtigste Architektur-Hebel des gesamten Ansatzes.

Secrets — SealedSecrets, SOPS, External-Secrets, Vault

Klartext-Secrets gehören nicht in Git, verschlüsselte Secrets aber sehr wohl. Vier Muster sind in der GitOps-Praxis etabliert, sie unterscheiden sich in Komplexität und strategischem Reifegrad. Die folgende Tabelle ordnet die Optionen ein:

Lösung	Verschlüsselung	Geeignet für	Reepa-Empfehlung
SealedSecrets (Bitnami)	Asymmetrisch, cluster-spezifischer Public Key	Einzelne Cluster, einfacher Einstieg	Einstieg, Klein- und Mittelstand bis 3 Cluster
Mozilla SOPS	age, GPG oder Cloud-KMS (AWS/GCP/Azure)	Multi-Cluster, ohne extra Controller	Mittelstand, wenn Cloud-KMS ohnehin vorhanden
External-Secrets-Operator	Git enthält nur Referenzen, Secrets in Vault/Cloud	Setups mit zentralem Secret-Speicher	Strategisch beste Lösung ab mehreren Clustern
HashiCorp Vault direkt	Vault Agent oder CSI-Driver	Hohe Compliance-Anforderungen	Banken, Versicherer, regulierte Branchen

Für die meisten mittelständischen Setups empfehlen wir den Einstieg über SealedSecrets oder SOPS und den Übergang zu External-Secrets-Operator mit Vault, sobald mehr als zwei oder drei Cluster im Spiel sind. SealedSecrets hat einen Nachteil, der in der Praxis oft unterschätzt wird: der Verschlüsselungs-Key ist cluster-spezifisch, ein Disaster-Recovery braucht zwingend ein Backup dieses Keys. Wer das vergisst, hat im Recovery-Fall ein Repo voller Secrets, die niemand mehr entschlüsseln kann.

Progressive Delivery — Flagger und Argo Rollouts

GitOps liefert den Roll-out-Mechanismus, sagt aber nichts darüber, wie ein Roll-out ablaufen soll. Wer Canary-Releases, Blue-Green-Deployments oder feature-flag-gesteuerte Promotions braucht, ergänzt GitOps um eine Progressive-Delivery-Schicht. Zwei Werkzeuge dominieren: Argo Rollouts (typischerweise mit ArgoCD kombiniert) und Flagger (typischerweise mit Flux kombiniert, ursprünglich von Weaveworks).

Argo Rollouts ersetzt das Standard-Deployment-Objekt durch eine eigene Rollout-Ressource, die Canary-Schritte, Auto-Promote-Bedingungen und Analyse-Runs auf Basis von Prometheus-Metriken unterstützt. Flagger arbeitet als Operator, der bestehende Deployments mit Annotations versieht und den Canary-Verlauf über Service-Mesh-Werkzeuge wie Istio, Linkerd oder die NGINX-Ingress-Controller-Schwergewichts-Routing-Mechanik abbildet. Beide Werkzeuge analysieren während eines Canary-Schritts automatisch Metriken (Fehlerrate, Latenz, benutzerdefinierte SLI) und brechen den Roll-out ab, wenn die Werte aus dem grünen Bereich laufen.

Für mittelständische Setups ist Progressive Delivery oft erst der zweite Schritt nach dem GitOps-Einstieg. Wer aber Anwendungen mit hohem Geschäftsrisiko (Online-Shop, Buchungs-System, Bezahl-Funktionen) ausrollt, sollte Progressive Delivery von Anfang an einplanen — die Investition lohnt sich beim ersten verhinderten Produktiv-Vorfall.

Multi-Cluster und Multi-Umgebung

Sobald mehr als ein Cluster im Spiel ist, wird die Frage interessant, ob ein zentraler GitOps-Controller alle Cluster managed (Hub-and-Spoke) oder ob jeder Cluster sich selbst aus dem Repo managed (Cluster-lokal). ArgoCD ist klassisch ein Hub-and-Spoke-Werkzeug: ein zentraler ArgoCD-Cluster registriert die Ziel-Cluster und syncen Anwendungen in sie hinein. Das vereinfacht das Reporting (eine UI für alle Cluster), schafft aber einen zentralen Ausfallpunkt und braucht Cluster-Credentials in zentraler Verwahrung.

Flux folgt dem Cluster-lokalen Modell: jeder Cluster hat seinen eigenen Flux-Stack und beobachtet das gemeinsame Config-Repo (typischerweise mit einem clusterspezifischen Pfad). Das ist resilienter (Ausfall eines Clusters betrifft die anderen nicht), aber das Reporting muss über externe Werkzeuge (Grafana, Weave GitOps Dashboard) aggregiert werden. Für Setups mit mehreren Produktions-Regionen ist das Cluster-lokale Modell architektonisch sauberer.

Für die Umgebungs-Trennung empfehlen wir physisch getrennte Cluster für Produktion und alles andere, und logisch getrennte Namespaces für Dev und Staging im selben Nicht-Produktions-Cluster. Wer Produktions-Workload und Test-Workload im selben Cluster betreibt, riskiert Noisy-Neighbor-Effekte und Sicherheits-Kollateralschäden, die im GitOps-Modell zwar schneller behebbar, aber nicht weniger schmerzhaft sind. Mehr dazu in unserem Kubernetes-Leitfaden für den Mittelstand.

Migration aus klassischem CD

Die Migration aus einer Jenkins- oder GitHub-Actions-basierten Push-CD erfolgt typischerweise in vier Phasen über acht bis sechzehn Wochen. Phase eins ist die Plattform-Vorbereitung: ArgoCD oder Flux wird im ersten Cluster installiert, ein Config-Repo wird angelegt, und Plattform-Dienste (Ingress, Cert-Manager, Monitoring) werden als erste Anwendungen migriert. Diese Phase ist arm an Risiko, weil noch keine produktiven Anwendungen betroffen sind.

Phase zwei migriert die erste Pilot-Anwendung — typischerweise ein internes Tool mit geringem Risiko. Die Pipeline wird so umgebaut, dass sie statt eines kubectl-Schritts einen Config-Repo-PR erzeugt. Die Anwendungs-Entwickler erleben hier zum ersten Mal den GitOps-Workflow und liefern wichtiges Feedback. Phase drei rollt das Muster auf weitere Anwendungen aus, Phase vier auf produktions-kritische Workloads.

Ein häufiger Fehler in der Migration ist der Versuch, parallel beide Modelle (Push und Pull) zu betreiben — das endet fast immer in Drift-Konflikten, weil sowohl die alte Pipeline als auch der neue Controller den Cluster-Zustand verändern wollen. Sauberer ist der Cutover pro Anwendung an einem definierten Datum: ab Tag X laufen alle Änderungen über GitOps, die alte Pipeline wird stillgelegt.

Reepa-Setup für mittelständische Kunden

Für unsere Mittelstands-Kunden setzen wir typischerweise auf ArgoCD als Hub-and-Spoke-Lösung mit einem dedizierten ArgoCD-Cluster und ein bis drei Workload-Clustern (Dev/Staging gemeinsam, Prod separat, optional ein DR-Cluster). Die Repo-Struktur trennt Application- und Config-Repos, das Config-Repo ist ein Monorepo mit App-of-Apps-Bootstrap. Secrets werden in der Einstiegs-Phase über SealedSecrets verwaltet, mit dem strategischen Migrationspfad zu External-Secrets-Operator mit HashiCorp Vault, sobald die zweite Produktions-Umgebung dazukommt.

Für Anwendungen mit hohem Geschäftsrisiko ergänzen wir Argo Rollouts mit Prometheus-basierten Analyse-Runs. Bei stark regulierten Branchen (Medizin, Finanzen) ist die Audit-Pipeline um signierte Commits (sigstore/gitsign) und Policy-as-Code (OPA Gatekeeper oder Kyverno als Admission-Controller) erweitert. Die Audit-Lese-Berechtigung im Config-Repo erfüllt damit gleichzeitig Anforderungen aus DSGVO Artikel 32, ISO 27001 Control A.8.32 und NIS2 zu nachvollziehbaren Änderungs-Prozessen.

Der typische Projektrahmen für die Erstaufsetzung mit zwei Clustern und etwa zehn Anwendungen liegt bei 20 bis 30 Beratungs-Tagen, Folgebetreuung ist meist als Retainer mit zwei bis vier Tagen pro Monat sinnvoll. Wer das gesamte Setup als Managed Service bezieht, vermeidet die initiale Aufbau-Kurve, gibt aber einen Teil der Kontrolle ab — die Wahl hängt von der Plattform-Reife des Kunden ab.

Häufige Fragen