Reagans Formulierung bezog sich auf Verträge. Im Betrieb passt sie besser zu GitOps, als die meisten Anbieterfolien zugeben: Ja, Git ist der Vertrag. Und ja, man schaut trotzdem auf den Cluster, bevor man schlafen geht.
Foto von Mikhail Nilov auf Pexels
GitOps verspricht Reconciliation: gewünschten Zustand in Git deklarieren, einen Controller die Realität angleichen lassen, Drift erkennen, Änderungen über Commits nachvollziehen. Argo CD wurde für viele Teams zum Gesicht dieser Geschichte. Ich nutze es. Einiges daran mag ich. Ich sehe aber auch, wie es Dinge automatisch synchronisiert, die ich pausiert hätte, wenn noch ein Mensch den Apply-Button gehalten hätte.
Dieser Beitrag ist nicht gegen GitOps. Er ist für Klarheit: wann deklaratives Synchronisieren hilft, wann Drift ein Symptom und keine Sünde ist, und wann der Zwang, alles durch Git zu schleusen, neue Fehlermodi erzeugt.
Wofür GitOps gut ist
Audit Trail. Wer was wann geändert hat, mit Kommentaren aus der PR-Prüfung. Besser als SSH-Historie und Stammeswissen.
Wiederholbare Umgebungen. Gleiche Manifeste, andere Cluster — wenn Overlays diszipliniert sind.
Wiederherstellungserzählung. „Commit revertieren und synchronisieren“ ist eine Rollback-Geschichte, die Führungskräfte verstehen.
Weniger kubectl-Heldentum. Weniger einmalige Applies vom Laptop — wenn Leute wirklich aufhören, vom Laptop aus anzuwenden.
Sichtbarkeit an einem Ort. Argo CDs UI mit OutOfSync-Ressourcen half mir beim Onboarding schneller als grep in zwölf Repos.
Für Plattformteams mit vielen Services sind diese Vorteile real. Ich argumentiere nicht dafür, zu Schneeflocken-Clustern zurückzugehen, die drei Leute mit root und einem Gebet pflegen.
Was „vertrauen, aber prüfen“ praktisch heißt
Vertrauen: gemergtes main spiegelt die Absicht wider; der Controller soll sicher konvergieren.
Prüfen: Vor und nach dem Sync bestätigt ein Mensch oder ein automatisierter Check, dass die Realität den Erwartungen entspricht und die Auswirkung auf Kunden akzeptabel ist.
Prüfen ist nicht optional, weil:
Git kennt die Cluster-Historie nicht. Manuelle Hotfixes, Incident-Patches und fehlgeschlagene Teil-Applies hinterlassen Minen.
Controller verstehen keinen Geschäftskontext. Ein erfolgreicher Sync kann ein kaputtes Image deployen, wenn der Tag in Git falsch, aber syntaktisch gültig ist.
Prune- und Sync-Optionen löschen Dinge. Prüfen heißt zu lesen, was entfernt wird, nicht nur, was hinzukommt.
Abhängigkeiten existieren außerhalb von Git. DNS, Zertifikate, externe Datenbanken, Feature Flags, Quotas — Git ist nicht das ganze System.
Meine minimale Prüf-Gewohnheit:
- Diff in Git lesen.
- Diff in Argo CD (oder
argocd app diff) lesen, inklusive Hooks und Prune. - Fehlerrate und Sättigung während des Rollout-Fensters beobachten.
- Nach dem Sync bestätigen, dass keine unerwarteten OutOfSync-Ressourcen bleiben — Drift könnte etwas sagen.
Der Pipeline vertrauen. Das Ergebnis prüfen.
Drift ist nicht immer der Feind
GitOps-Kultur behandelt Drift manchmal wie moralisches Versagen. Jedes manuelle kubectl ist Häresie; OutOfSync-Badges beschämen Teams.
Die Realität ist unordentlicher.
Incident-Hotfix. Produktion war ausgefallen. Jemand skalierte manuell oder patchte eine ConfigMap. Git zog später nach — oder noch nicht. Der Cluster durfte vorübergehend abweichen.
Controller-generierte Felder. Mutating Webhooks, Defaults, HPA passt Replicas an — der Live-Zustand weicht vom Manifest ab, ohne dass jemand etwas falsch gemacht hat.
Secrets und externe Operatoren. SealedSecrets, External Secrets, Cloud-IAM — was in Git liegt, ist nicht zwingend das, was läuft.
Ausprobieren außerhalb von Produktion. Engineers lernen durch Herumprobieren. Striktes Auto-Sync in Dev bremst, wenn jedes Experiment einen PR braucht.
Drift ist ein Signal. Erst fragen, warum, bevor man ihn wegsynchronisiert.
Fragen, die ich stelle, wenn Argo OutOfSync zeigt:
- Hat jemand während eines Vorfalls gepatcht? Dokumentieren und backporten oder live zurücknehmen.
- Ist der Diff harmlose Metadaten?
- Ist der Live-Zustand richtig und Git falsch? Git korrigieren, nicht nur synchronisieren.
- Verursacht der Sync Downtime (Pod-Restart, CRD-Replace, Ingress-Tausch)?
Blindes Synchronisieren war der Grund, warum ich einmal zusehen durfte, wie ein Service-Typ zurücksprang und externer Traffic wegfiel, weil Git einen alten Wert enthielt, den jemand Wochen zuvor im Cluster „repariert“ hatte.
Wann GitOps am meisten hilft
Muster, für die ich stark plädiere:
Multi-Cluster-Standardisierung. Plattform-Baseline in Git; Overlays pro Umgebung. Drift-Erkennung findet Teams mit Ausnahmen.
Regulierte Change Control. PR-Prüfung plus Merge-Gates plus Sync-Audit überzeugt Auditoren eher als geteiltes kubeconfig.
Häufige Deploys mit kleinen Diffs. Controller rollen inkrementell aus; Git-Historie korreliert mit Vorfällen.
Teams, die schon in PR-Kultur leben. GitOps trifft sie dort, wo sie arbeiten.
Disaster-Recovery-Übungen. Aus Git auf einen frischen Cluster neu anwenden — wenn man es vierteljährlich wirklich testet.
In diesen Fällen reduziert GitOps Varianz. Varianz ist eine Quelle nächtlicher Alarme.
Wann GitOps schadet
Nicht jeder Schmerz bedeutet „falsch implementiert“. Manches ist strukturell.
Stateful Systeme mit komplexen Migrationen. Einweg-Schema-Änderungen lassen sich nicht sauber reconciliieren. Dafür braucht man Runbooks, nicht nur Revert-Commits.
Viel Indirektion durch Helm oder Kustomize. Prüfende sehen gerendertes YAML ohne passende Werkzeuge nicht. Schlechte Änderungen verstecken sich in Vorlagen.
Auto-Sync auf Produktion ohne Leitplanken. Geschwindigkeit ohne Pausenfenster entfernt den menschlichen Prüfschritt.
Organisationsgrenzen passen nicht zu Repos. Drei Teams, ein Cluster, ein Monorepo — Merge-Konflikte und Schuldzuweisungen.
Die Versuchung, Secrets in Git zu legen. Selbst verschlüsselt werden Rotation und Reaktion auf Leaks schwerer. Prüfen umfasst Secret-Hygiene, nicht nur kubectl.
Plattform nicht bereit. Keine CI-Render-Tests, keine Policy-Checks (OPA, Kyverno), kein Staging-Cluster — GitOps verstärkt, was man ohnehin schlecht macht.
Lernumgebungen. Pflicht-GitOps für Lernende, die Pods erkunden, erzeugt Reibung mit wenig Sicherheitsgewinn.
Ich habe GitOps-Einführungen gesehen, weil Führung einen Blog gelesen hatte, nicht weil das Team die Probleme hatte, die GitOps löst. Diese Reihenfolge erzeugt Groll und Umgehungen: geheimes kubectl, doppelte Manifeste, „Notfall“-Namespaces außerhalb von Argo.
Argo-CD-Details, die ich auf die harte Tour gelernt habe
Argo ist exzellent und meinungsstark. Ein paar praktische Notizen, ohne vollständige Dokumentation vorzutäuschen.
Application- vs. AppProject-Grenzen. Falsch konfigurierte Projects öffnen cluster-admin-Pfade. AppProject so ernst prüfen wie Application.
Sync Waves und Hooks. Jobs laufen PreSync; Ressourcen werden je nach Hook-Policy gelöscht. Den Sync-Plan lesen, nicht nur den Git-Diff.
Replace vs. apply. Manche Ressourcen brauchen replace; versehentliches replace löscht und erstellt neu. Besonders spannend bei StatefulSets.
Prune-Propagation. --prune entfernte beim letzten Sync einen Namespace, den jemand außerhalb des Umfangs wähnte. Prune-Einstellungen gehören in die Prüfcheckliste.
Verzögerung beim Health Assessment. Argo sagt Healthy; die Anwendung ist es nicht. Metriken und Probes nutzen, nicht nur grünes UI.
Multi-Source-Apps. Mächtig; Diffs werden schwieriger. Langsamer werden.
CLI und RBAC. Wer darf argocd app sync auf Produktion ausführen? Wenn die Antwort „alle mit SSO“ ist, ist die Prüfung geschwächt.
Ignore differences. ignoreDifferences beseitigt Rauschen, bis es echte Probleme versteckt. Regelmäßig neu prüfen.
Das ist kein Argument gegen Argo. Es ist ein Argument dafür, Sync wie eine Produktionsänderung zu behandeln — weil es eine ist.
Mentalmodell der Reconciliation-Schleife
Ein nützliches Bild:
Git (desired) --> Controller --> Cluster (actual)
^ |
| v
+---- drift ----+Die Schleife läuft kontinuierlich. Die Aufgabe ist nicht nur, Git zu pushen. Die Aufgabe ist sicherzustellen, dass die Annahmen der Schleife stimmen: korrekter Kontext, kompatibler Live-Zustand, sichere Sync-Optionen, Beobachtbarkeit während der Konvergenz.
Wenn die Schleife kämpft — Sync-Thrashing, wiederholtes OutOfSync — Sync stoppen und diagnostizieren. Thrashing entsteht oft durch konkurrierende Controller (HPA vs. Deployment-Replicas in Git), Webhook-Mutationen oder jemanden, der noch am selben Objekt mit kubectl arbeitet.
GitOps mit imperativen Gewohnheiten kombinieren
Hybrid ist kein Scheitern. Reife Teams, die ich respektiere, nutzen:
- GitOps für App-Deploys und Plattform-Baseline.
- Runbooks für Break-Glass-kubectl mit verpflichtendem Folge-PR.
- Drift-Tickets statt Drift-Scham.
- Freeze-Fenster in riskanten Geschäftsperioden — Sync pausiert, Kommunikation klar.
„Alles durch Git“ klingt sauber. Reinheit bricht um drei Uhr morgens, wenn die Lösung ein Feld ist und die PR-Pipeline vierzig Minuten braucht. Besser ein ehrlicher Break-Glass mit Audit als eine geheime kubectl-Kultur.
Nach Break-Glass zweimal prüfen: Cluster-Zustand und Abgleich mit Git. Dauerhafte Drift ist Schuld.
Metriken, die über Sync-Status hinaus zählen
Argo-Metriken sind nötig, nicht hinreichend.
Deployment-Erfolgsrate — Rollouts abgeschlossen vs. fehlgeschlagen.
MTTR nach schlechtem Merge — wie schnell Revert plus Sync den Service wiederherstellt.
OutOfSync-Alter — chronische Drift zeigt Prozesslücke.
Anzahl manueller Syncs — eine hohe Auto-Sync-Fehlerrate bedeutet falsche Vorlagen oder fehlende Cluster-Voraussetzungen.
Korrelation von Vorfällen mit Git-Merges — wenn jeder Alarm auf einen Plattform-PR folgt, ist die Tiefe der Prüfung das Thema, nicht die Tool-Marke.
Ein grünes Sync-Icon ist kein SLO.
Was ich Teams empfehle zu versuchen
Ein pragmatischer Mittelweg:
- GitOps zuerst auf Staging. Diff, Hooks und Prune-Schmerz ohne Kunden-Auswirkungsbereich lernen.
- Manueller oder halbautomatischer Sync auf Produktion, bis Prüf- und Render-Werkzeuge reif sind.
- Verpflichtendes
helm template/ kustomize build in CI mit Artefakt am PR. - Wöchentlicher Drift-Report — OutOfSync-Liste mit Verantwortlichen, nicht nur Auto-Heal.
- Break-Glass-Dokument — wer darf kubectl nutzen, wie wird zurückportiert, welches SLA gilt für den Git-Fix?
- Prüfcheckliste bei Produktions-Sync — dieselbe Gegenprüfungsmentalität wie bei kubectl-apply-Beiträgen, die ich anderswo schreibe.
Keine Wunderwaffe. Iteration.
Persönliche Haltung
Ich vertraue GitOps genug, um es täglich zu nutzen. Ich prüfe genug, um nach Plattform-Merges in Bereitschaftsnächten schlafen zu können. Ich verkaufe es nicht als Moral. Ich sehe es als Werkzeug mit Grenzen.
Eine Luftfahrt-Parallele, einmal und ohne Posterpathos: Flugpläne werden eingereicht und geflogen, und trotzdem schaut man aus dem Fenster. Instrumente lügen gelegentlich. Die Boden-Kontrolle verpasst eine geänderte Freigabe. Dem Plan vertrauen, gegen die Realität prüfen.
Git ist der Plan. Der Cluster ist die Realität. Argo CD ist der Autopilot, der beides koppelt — nützlich, nicht unfehlbar.
Abschluss
GitOps hilft, wenn Varianz, Audit und Wiederholbarkeit die eigentlichen Probleme waren. GitOps schadet, wenn es als Religion übernommen wird, Auto-Sync menschliches Urteil zum falschen Zeitpunkt entfernt oder Drift als Verbrechen statt als Gesprächsanlass behandelt wird.
Der Pipeline vertrauen. Ergebnisse prüfen. Git korrigieren, wenn live richtig war. Live korrigieren, wenn Git richtig war. Dem Team den Unterschied beibringen.
Wenn du heute Argo CD betreibst: Nimm eine Produktions-Application und geh den letzten Sync durch. Was wäre gebrochen, wenn Prune aktiv gewesen wäre? Was ist gerade OutOfSync und warum? Fünf Minuten Prüfung sind besser als eine weitere Stunde „Vertrau mir“.
