Ein Kubernetes-Cluster in Produktion zeigte plötzlich ein Verhalten, das niemand erklären konnte. Ein Pod lief mit einer Konfiguration, die in keinem Deployment-Manifest im Repository zu finden war. Nach zwei Stunden Fehlersuche stellte sich heraus: Ein Engineer hatte drei Wochen zuvor während eines Incidents einen manuellen kubectl patch-Befehl abgesetzt, um schnell zu reagieren.
Der Patch hatte funktioniert. Er wurde nie ins Git-Repository zurückgeschrieben. Beim nächsten regulären Deployment griff niemand mehr auf ihn zurück – er verschwand nicht, weil ihn niemand kannte, sondern weil Cluster und Repository seit diesem Moment zwei unterschiedliche Wahrheiten erzählten.
Das ist kein Einzelfall. Es ist die Standardfolge eines Push-basierten Deployment-Modells, in dem der tatsächliche Zustand eines Systems und seine Beschreibung im Code auseinanderdriften können – und in der Praxis auch auseinanderdriften.
Was GitOps eigentlich bedeutet
GitOps ist keine neue Erfindung von Kubernetes-Tools, sondern die konsequente Anwendung eines einfachen Prinzips: Der gewünschte Zustand eines Systems wird vollständig deklarativ in einem Git-Repository beschrieben. Ein Operator innerhalb des Clusters – etwa Argo CD oder Flux – vergleicht kontinuierlich den tatsächlichen Zustand mit dem im Repository beschriebenen Sollzustand und gleicht Abweichungen automatisch ab.
Der Unterschied zu klassischen Deployment-Pipelines wirkt auf den ersten Blick klein, ist aber fundamental: Statt dass eine Pipeline von außen Änderungen in den Cluster pusht, holt sich der Cluster seine Konfiguration selbst und zieht sie – Pull statt Push.
Push-Pipelines vs. Pull-basierte Reconciliation
In einer klassischen CI/CD-Pipeline besitzt das Build-System Zugangsdaten für den Produktionscluster. Der Pipeline-Runner authentifiziert sich, wendet Manifeste an, meldet Erfolg oder Misserfolg. Das funktioniert – bedeutet aber auch, dass jedes CI-System und potenziell jeder mit Zugriff auf die Pipeline-Konfiguration Schreibrechte auf die Produktionsinfrastruktur besitzt.
Bei GitOps dreht sich das um. Der In-Cluster-Operator hält die einzigen Zugangsdaten zum Cluster. Er beobachtet das Repository, nicht umgekehrt. Niemand außerhalb des Clusters braucht kubectl-Zugriff auf Produktion, um ein Deployment auszulösen – ein Merge in den Main-Branch reicht. Das reduziert die Angriffsfläche erheblich und macht Credential-Sprawl über Dutzende Pipeline-Konfigurationen hinweg überflüssig.
Der Vorteil, der selten genannt wird: Audit und Rollback
Der meistgenannte GitOps-Vorteil ist Konsistenz. Der eigentlich wertvollere Effekt liegt woanders: Jede Änderung an der Produktionsumgebung hat automatisch eine vollständige, unveränderliche Historie – die Git-Historie selbst. Wer hat wann welche Änderung an welcher Komponente vorgenommen, mit welcher Begründung im Commit, reviewt von wem im Pull Request? Diese Frage beantwortet sich von selbst, ohne separates Audit-Log-System.
Rollback wird dadurch trivial: ein git revert auf den letzten funktionierenden Commit, und der Operator gleicht den Cluster automatisch auf den vorherigen Zustand zurück. Kein manuelles Nachvollziehen, welcher der letzten fünf kubectl apply-Befehle rückgängig gemacht werden muss.
Was GitOps nicht löst
GitOps beschreibt, wie Konfiguration in ein System gelangt – nicht, ob die Konfiguration richtig ist. Ein fehlerhaftes Manifest, das erfolgreich gemerged wird, wird genauso zuverlässig ausgerollt wie ein korrektes. GitOps ersetzt keine Tests, keine Staging-Umgebungen und keine Code-Reviews – im Gegenteil macht es sie wichtiger, weil der Weg vom Merge zur Produktion kürzer und automatischer wird.
Ein weiterer blinder Fleck: Secrets. Kubernetes-Secrets im Klartext in einem Git-Repository zu speichern, ist unabhängig vom Deployment-Modell eine schlechte Idee. Tools wie Sealed Secrets oder eine Anbindung an einen externen Secret-Manager (Vault, AWS Secrets Manager) sind in jedem GitOps-Setup Pflicht, nicht optional.
Ein realistischer Einstieg
GitOps für einen gesamten Infrastruktur-Bestand auf einmal einzuführen, ist selten der richtige Weg. Der bewährte Einstieg: ein einzelner, nicht-kritischer Cluster oder Namespace, ein Team, ein Tool – Argo CD und Flux sind beide CNCF-Projekte mit vergleichbarer Reife. Wenn Reconciliation-Zyklus, Repository-Struktur und Secret-Verwaltung dort funktionieren, lässt sich das Muster auf weitere Teams übertragen.
Der eigentliche Kulturwandel liegt nicht im Tool. Er liegt darin, dass ein manueller kubectl-Befehl in Produktion danach als dokumentationspflichtige Notfallmaßnahme gilt – nicht als normaler Arbeitsweg. Genau das hätte den eingangs beschriebenen Incident verhindert.