Was ist GitOps?
GitOps ist ein Betriebsmodell für Infrastruktur und Deployments, das Git als einzige Quelle der Wahrheit („Single Source of Truth") nutzt: Der gewünschte Zustand wird deklarativ in einem Git-Repository beschrieben, und ein Agent wie ArgoCD oder Flux gleicht die laufende Umgebung kontinuierlich damit ab (Reconciliation), statt Befehle manuell auf Servern auszuführen. Vorteil für regulierte Branchen: vollständiger Audit-Trail über die Git-Historie, automatische Drift-Korrektur und klar getrennte Verantwortlichkeiten zwischen CI (Build, Test) und CD (Sync).
Auch bekannt als: Git-basiertes Deployment · GitOps-Prinzip · Deklaratives Deployment
Ist GitOps bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Der Ablauf ist ein Kreislauf. Ein Agent wie ArgoCD oder Flux läuft im Zielcluster und liest in kurzen Abständen das Git-Repository mit dem Soll-Zustand, etwa Kubernetes-Manifeste oder Helm-Charts. Er vergleicht diesen Stand mit dem, was tatsächlich im Cluster läuft. Findet er eine Abweichung, wendet er den Soll-Zustand an. Diesen fortlaufenden Abgleich nennt man Reconciliation. Die Pipeline pusht also nichts mehr in die Umgebung, der Agent zieht sich den Stand selbst.
Das CNCF-Projekt OpenGitOps hat das Modell in vier Prinzipien gefasst. Der Soll-Zustand ist deklarativ beschrieben, er ist versioniert und unveränderlich mit vollständiger Historie gespeichert, Agenten ziehen ihn automatisch, und sie gleichen ihn kontinuierlich mit dem Ist-Zustand ab. Deployment wird dadurch zu einem Git-Vorgang: Ein Pull Request ändert den Soll-Zustand, nach dem Merge zieht der Agent die Umgebung nach.
Weicht der Cluster ab, etwa weil jemand per kubectl direkt eine Konfiguration geändert hat, erkennt der Agent diese Drift. Je nach Einstellung meldet er sie oder setzt die Änderung automatisch zurück. Für regulierte Branchen ist das der eigentliche Gewinn. Jede Änderung am Produktionszustand hat einen Commit mit Review, und CI (Build und Test) und CD (der Sync) sind sauber getrennt. Unkontrollierte Handeingriffe, in OT-Umgebungen besonders riskant, bleiben nicht unbemerkt.
GitOps ist eng mit Kubernetes verbunden, weil dessen deklaratives Modell gut passt, das Prinzip gilt aber auch darüber hinaus. Zwei Stolpersteine tauchen fast immer auf. Secrets gehören nicht im Klartext ins Repository und werden über Sealed Secrets oder externe Secret-Stores eingebunden. Und die Repository-Struktur, getrennt nach Umgebungen und Anwendungen, will geplant sein, etwa über das App-of-Apps-Pattern. Flux ist seit 2022 ein graduiertes CNCF-Projekt und wird auch nach dem Aus des Gründers Weaveworks im Februar 2024 von anderen Unternehmen weiterentwickelt.
Neuer Cluster steht per App-of-Apps in einem Durchlauf
Ein Plattform-Team baute neue Kubernetes-Cluster bisher nach einer Wiki-Anleitung von Hand auf, und kein Cluster glich dem anderen. Heute beschreibt ein Root-Repository den kompletten Stack mit Ingress, Cert-Manager und Monitoring. ArgoCD rollt ihn über das App-of-Apps-Pattern aus, und jeder neue Cluster entsteht identisch.
Manuelle Änderung am Produktions-Cluster wird zum Log-Eintrag
Bei einem Fertigungsbetrieb ändert jemand unter Zeitdruck eine Konfiguration direkt am Produktions-Cluster. ArgoCD erkennt die Abweichung vom Soll-Zustand in Git, stellt den definierten Zustand wieder her und protokolliert den Vorgang. Die Änderung, an die sich drei Monate später niemand mehr erinnert hätte, steht damit mit Zeitstempel im Log.
Ist GitOps für Sie der nächste Schritt?
GitOps lohnt sich nicht für jeden gleich stark — es hängt daran, wie Sie heute ausliefern und ob Kubernetes im Spiel ist. Zwei Klicks ordnen ein, wo Ihr größter Hebel liegt.
Wie liefern Sie heute überwiegend aus?
- Was ist der Unterschied zwischen GitOps und klassischem CI/CD-Deployment?
- Bei klassischem CI/CD pusht eine Pipeline Änderungen aktiv auf die Zielumgebung. Bei GitOps zieht ein Agent den Soll-Zustand aus Git und gleicht ihn kontinuierlich ab. Aus dem Push wird ein Pull, und die Pipeline braucht keine Zugangsdaten mehr für die Produktionsumgebung.
- Wie verwalte ich Secrets in einem GitOps-Workflow?
- Secrets gehören nicht im Klartext ins Git-Repository. Üblich sind verschlüsselte Ansätze wie Sealed Secrets oder die Anbindung externer Secret-Stores über Operatoren. Im Repository liegen dann nur verschlüsselte oder referenzierende Objekte.
- Funktioniert GitOps auch außerhalb von Kubernetes?
- Ja, das Prinzip aus deklarativem Soll-Zustand in Git und automatischem Abgleich ist nicht an Kubernetes gebunden. Die verbreiteten Werkzeuge ArgoCD und Flux sind allerdings auf Kubernetes ausgerichtet, weil dessen deklaratives Modell besonders gut passt.
Wo steht Ihr Team bei GitOps?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu GitOps: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01CNCF OpenGitOpsOpenGitOps Principles(externe Seite, öffnet in neuem Tab)
Die vier Prinzipien deklarativ, versioniert, automatisch gezogen und kontinuierlich abgeglichen.
- /02Flux ProjectFlux Core Concepts(externe Seite, öffnet in neuem Tab)
Erklärt Reconciliation, Sources und Drift-Korrektur am zweiten großen GitOps-Werkzeug.
- /03Argo ProjectArgo CD Documentation(externe Seite, öffnet in neuem Tab)
Umsetzung des Pull-Modells mit Sync-Status, Self-Healing und Multi-Cluster-Betrieb.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance