Das Wichtigste in Kürze
- GitOps macht Git zum Single Source of Truth für Infrastruktur und Anwendungs-Konfiguration.
- ArgoCD und Flux sind die beiden führenden GitOps-Controller für Kubernetes.
- Pull-basiertes Modell: Der Cluster synchronisiert sich selbst mit dem Git-Repository.
- Drift Detection erkennt automatisch, wenn der Cluster-Zustand vom Git-Zustand abweicht.
- GitOps vereinfacht Rollbacks auf einen Git-Revert — keine manuellen kubectl-Befehle.
Was im Git-Repository steht, läuft im Cluster. Was nicht im Repository steht, läuft nicht. GitOps reduziert Infrastructure-Automation auf ein Prinzip, das jeder Entwickler bereits kennt: Änderungen per Pull Request, Reviews, Merge — und der Cluster synchronisiert sich automatisch. Kein manuelles kubectl apply, kein Drift, keine Überraschungen.
Das GitOps-Prinzip
GitOps basiert auf vier Grundsätzen: Erstens, der gewünschte Zustand des Systems ist deklarativ in Git beschrieben. Zweitens, Git ist die einzige Quelle der Wahrheit — keine manuellen Änderungen am Cluster. Drittens, genehmigte Änderungen werden automatisch angewendet. Viertens, Software-Agents (Controller) stellen sicher, dass der tatsächliche Zustand dem gewünschten Zustand entspricht.
Das klingt nach CI/CD, ist aber fundamentally anders: CI/CD ist push-basiert (Pipeline deployt aktiv). GitOps ist pull-basiert (Controller im Cluster pollt das Git-Repository und synchronisiert). Der Controller hat Cluster-Zugriff, die CI-Pipeline nicht — ein Security-Vorteil.
ArgoCD: Der Marktführer
ArgoCD ist das populärste GitOps-Tool mit einer grafischen Oberfläche, die den Synchronisierungsstatus aller Applikationen visualisiert. Features: Multi-Cluster-Management, RBAC, SSO-Integration, Application Sets (Templates für viele ähnliche Deployments), Health Checks und automatische Sync-Policies.
Die Architektur: ArgoCD läuft als Controller im Cluster, überwacht Git-Repositories und vergleicht den gewünschten Zustand (Git) mit dem tatsächlichen Zustand (Cluster). Bei Abweichungen kann ArgoCD automatisch synchronisieren oder einen Alert auslösen.
ArgoCD ist der Standard für Teams, die eine visuelle Übersicht brauchen und Multi-Cluster-Setups verwalten.
Flux: Die leichtgewichtige Alternative
Flux (v2, von Weaveworks, jetzt CNCF-Projekt) verfolgt einen modulareren Ansatz: Separate Controller für Git-Synchronisierung (source-controller), Helm-Releases (helm-controller), Kustomize-Patches (kustomize-controller) und Notifications (notification-controller).
Flux hat keine eigene UI — stattdessen integriert es in bestehende Tools (Grafana, VSCode, CLI). Für Teams, die Kubernetes nativ per CLI verwalten und keine separate UI brauchen, ist Flux oft die bevorzugte Wahl. Die Modularität ermöglicht es, nur die benötigten Komponenten zu installieren.
GitOps in der Praxis: Workflow und Patterns
Der typische GitOps-Workflow: Entwickler erstellt einen Branch, ändert Kubernetes-Manifeste oder Helm-Values, erstellt einen Pull Request. Das Team reviewed die Änderung, ein CI-Job validiert die Manifeste (kubeval, conftest). Nach Merge synchronisiert ArgoCD/Flux den Cluster automatisch.
Rollback: Ein Git-Revert auf den vorherigen Commit — der Controller synchronisiert den alten Zustand. Kein manuelles kubectl rollout undo, keine Unsicherheit über den vorherigen Zustand.
Environment-Promotion: Änderungen fließen von Dev → Staging → Production durch Merges zwischen Branches oder Directories. Jedes Environment hat seinen eigenen Pfad im Repository.
Grenzen und Anti-Patterns
Secrets in Git: Kubernetes Secrets im Klartext in Git ist ein Sicherheitsrisiko. Lösungen: Sealed Secrets (verschlüsselt im Git, Controller entschlüsselt im Cluster), SOPS (Mozilla, verschlüsselt mit KMS) oder External Secrets Operator (Secrets aus Vault/AWS Secrets Manager synchronisieren).
Langsame Feedback-Loops: Push-basierte CI/CD deployt sofort nach Build. GitOps hat einen Sync-Intervall (typisch 30s-5min). Für Teams, die Instant-Deployments brauchen, kann das frustrierend sein — löbar durch Webhooks für sofortige Sync-Trigger.
Nicht für alles geeignet: GitOps funktioniert am besten für deklarative Kubernetes-Workloads. Für imperative Prozesse (Datenbank-Migrationen, einmalige Jobs) braucht man weiterhin CI/CD-Pipelines als Ergänzung.
Häufige Fragen
Was ist der Unterschied zwischen GitOps und CI/CD?
CI/CD ist push-basiert: Eine Pipeline wird getriggert und deployt aktiv in den Cluster. GitOps ist pull-basiert: Ein Controller im Cluster pollt Git und synchronisiert. GitOps hat Vorteile bei Security (Pipeline braucht keinen Cluster-Zugriff), Drift Detection und Rollbacks. In der Praxis ergänzen sich beide — CI für Build/Test, GitOps für Deployment.
ArgoCD oder Flux — welches Tool ist besser?
ArgoCD für Teams, die eine visuelle UI, Multi-Cluster-Management und Application Sets brauchen. Flux für Teams, die CLI-first arbeiten, einen modularen Ansatz bevorzugen und tief in das Kubernetes-Ökosystem integriert sind. Beide sind CNCF-Projekte und produktionsreif.
Wie handhabt man Secrets in GitOps?
Drei bewährte Ansätze: Sealed Secrets (asymmetrische Verschlüsselung, Controller entschlüsselt), SOPS (symmetrische Verschlüsselung mit KMS), External Secrets Operator (synchronisiert aus Vault, AWS Secrets Manager). Niemals Klartext-Secrets in Git — auch nicht in private Repositories.
Funktioniert GitOps nur mit Kubernetes?
Primär ja, weil Kubernetes deklarativ und reconciliation-fähig ist. Terraform und Crossplane ermöglichen GitOps-artige Workflows für Cloud-Infrastruktur. Für klassische VMs und On-Premise ist GitOps weniger natürlich, aber Ansible mit Git-basiertem Workflow kommt dem Konzept nahe.
Wie groß ist der Overhead von ArgoCD?
ArgoCD benötigt ca. 200-500 MB Memory und 0,5-1 CPU-Cores für die Control Plane. Für große Setups (> 500 Applications) skaliert man die Application Controller horizontal. Für einen einzelnen Cluster mit 50 Applications ist der Overhead minimal.
Quelle des Titelbildes: Pexels / RealToughCandy.com
