Betrieb & Monitoring
GitOps
GitOps ist ein Betriebsmodell mit Git als einziger Quelle der Wahrheit für den Soll-Zustand; Agenten ziehen ihn und gleichen Abweichungen kontinuierlich ab.
- Git als Single Source of Truth
- Pull-Modell statt Push
- Kontinuierlicher Soll-Ist-Abgleich
- Audit-Trail und Rollback per Git
- Argo CD und Flux CD (CNCF)
GitOps ist ein Betriebsmodell, kein einzelnes Werkzeug. Die Idee: Der gewünschte Zustand eines Systems wird deklarativ in Git abgelegt, und ein Agent im Zielsystem zieht diesen Zustand und sorgt fortlaufend dafür, dass die Realität ihm entspricht. Der Begriff wurde 2017 bei Weaveworks geprägt; die herstellerneutrale Definition liefert das OpenGitOps-Projekt der CNCF mit vier Prinzipien.
Dieser Artikel erklärt die vier GitOps-Prinzipien, den Unterschied zwischen Pull- und Push-Deployment samt Sicherheitsvorteil, die Reconciliation Loop und Drift-Korrektur, die Werkzeuge Argo CD und Flux CD, die Manifest-Quellen Kustomize und Helm, die Trennung von CI und CD, das Secret-Management sowie die Anwendung jenseits von Kubernetes (etwa für Terraform/OpenTofu).
1. Die vier Prinzipien
Das OpenGitOps-Projekt definiert GitOps über vier Prinzipien, die zugleich Anforderungen an die Werkzeuge sind:
- Deklarativ der gewünschte Zustand wird beschrieben, nicht als Befehlsfolge, sondern als Soll (z. B. Kubernetes-YAML).
- Versioniert und unveränderlich der Soll-Zustand liegt versioniert und unveränderlich vor; Git mit seiner vollständigen, hashbasierten Historie erfüllt das.
- Automatisch gezogen Software-Agenten ziehen den Zustand eigenständig aus der Quelle, statt dass ein externes System ihn hineindrückt.
- Kontinuierlich abgeglichen Agenten beobachten den Ist-Zustand laufend und korrigieren Abweichungen vom Soll.
2. Pull statt Push
Beim klassischen Push-Ansatz drückt eine CI-Pipeline (etwa über kubectl apply) Änderungen in den Cluster und braucht dafür Cluster-Zugangsdaten. GitOps bevorzugt das Pull-Modell: Ein Agent läuft im Cluster, überwacht Git und wendet Änderungen selbst an. Der Sicherheitsvorteil ist konkret: Es müssen keine Cluster-Credentials im CI-System liegen. Wird die CI kompromittiert, ist der Cluster nicht automatisch offen.
Das Pull-Modell ist nicht nur eine Geschmacksfrage, sondern ein echter Sicherheitsgewinn. Cluster-Zugangsdaten gehören nicht in jede CI-Pipeline; ein Agent, der von innen aus Git zieht, verkleinert die Angriffsfläche erheblich.
3. Reconciliation und Drift-Korrektur
Kern von GitOps ist die Reconciliation Loop: Der Agent vergleicht periodisch oder ereignisgesteuert den Soll-Zustand aus Git mit dem Ist-Zustand im Cluster. Bei einer Abweichung (Drift) leitet er die Korrektur ein. Manuelle Eingriffe direkt am Cluster werden so erkannt und (bei aktivem Self-Healing) rückgängig gemacht, der Cluster entspricht damit dauerhaft dem, was in Git steht.
4. Argo CD und Flux CD
Zwei CNCF-graduated-Werkzeuge dominieren: Argo CD arbeitet eher zentral-integriert, mit einer Application-Ressource, einer reichhaltigen Web-UI, Diff-Ansicht, dem App-of-Apps-Muster und automatischem Sync/Self-Heal. Flux CD ist modular aufgebaut (GitOps Toolkit aus Source-, Kustomize-, Helm- und Image-Automation-Controllern), läuft dezentral pro Cluster und bringt kein eingebautes Web-UI mit. Beide setzen die GitOps-Prinzipien sauber um; die Wahl hängt von Team, UI-Bedarf und Multi-Cluster-Strategie ab.
5. Manifest-Quellen, CI/CD-Trennung und Secrets
Als Manifest-Quellen dienen Kustomize (patch-basierte Overlays, kubectl-nativ) und Helm (Paketmanager mit Charts). GitOps trennt CI und CD sauber: Die CI baut das Image und aktualisiert das Manifest in Git, der GitOps-Agent (CD) deployt daraus, niemals schreibt die CI direkt in den Cluster. Für Secrets gilt: kein Klartext in Git. Dafür gibt es Sealed Secrets (verschlüsselte Ressourcen im Repo), SOPS (Dateiverschlüsselung mit KMS/age) oder den External Secrets Operator (Abruf aus Vault, AWS/Azure/GCP).
Secret-Management ist nicht inklusive
GitOps verlangt, dass alles in Git liegt, aber Klartext-Secrets dürfen es gerade nicht. Das ist kein gelöstes Out-of-the-box-Problem: Man muss sich bewusst für Sealed Secrets, SOPS oder den External Secrets Operator entscheiden und den entsprechenden Betrieb aufsetzen. Wer das überspringt, baut sich ein Sicherheitsleck.
6. Über Kubernetes hinaus
Die GitOps-Prinzipien sind nicht auf Kubernetes beschränkt; sie gelten für jede deklarativ beschreibbare Infrastruktur. Für Terraform/OpenTofu bringen Controller (etwa der Tofu Controller in Verbindung mit Flux) die Reconciliation-Idee in die Infrastruktur-Provisionierung: Statt apply als einmaligen CI-Schritt gleicht ein Controller den realen Zustand laufend mit dem Soll ab. Die ausgereiftesten Werkzeuge bleiben aber Kubernetes-zentriert.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Vollständige Auditierbarkeit über die Git-History | Primär Kubernetes-zentriert; IaC-GitOps weniger standardisiert |
| Rollback per git revert, automatisch deployt | Secret-Management nicht inklusive, erfordert Zusatzwerkzeuge |
| Drift wird erkannt und korrigiert (Self-Healing) | Konzeptioneller Umstieg und Lernkurve |
| Pull-Modell: keine Cluster-Credentials in der CI | Komplexität wächst mit Apps, Teams und Clustern |
| Disaster Recovery aus dem Git-Repository | Stateful Workloads brauchen besondere Behandlung |
Häufige Fragen zu GitOps
Nein, GitOps ist ein Betriebsmodell mit vier Prinzipien (deklarativ, versioniert, automatisch gezogen, kontinuierlich abgeglichen). Werkzeuge wie Argo CD oder Flux CD setzen dieses Modell für Kubernetes um, aber GitOps selbst ist der Ansatz, Git als alleinige Quelle der Wahrheit zu nutzen.
Über Zusatzwerkzeuge. Verbreitet sind Sealed Secrets (asymmetrisch verschlüsselte Ressourcen, die im Repo liegen dürfen), SOPS (Dateiverschlüsselung mit KMS oder age) und der External Secrets Operator, der Secrets zur Laufzeit aus einem externen Manager wie HashiCorp Vault holt. Klartext-Secrets gehören nie ins Repository.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
GitOps im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.