Begriff
GitOps
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir vor, du bist Admin für 100 Server.
Statt dich auf jedem Server einzuloggen (ssh) und Befehle zu tippen (apt install nginx), machst du etwas anderes.
Du schreibst den Wunschzustand in eine Textdatei in Git ("Ich will 3 nginx Server").
Ein Roboter (GitOps Operator) überwacht dieses Git-Repo.
Sobald du git push machst, sieht der Roboter: "Aha, Chef will Nginx."
Er rennt los und installiert es auf den Servern.
Wenn ein Server kaputt geht (Drift), repariert der Roboter ihn automatisch, damit er wieder so aussieht wie im Git.
Git ist die einzige Quelle der Wahrheit (Single Source of Truth).
Merksatz: Ein Betriebsmodell für Cloud-native Anwendungen, bei dem der gesamte Systemzustand deklarativ in Git versioniert ist und Änderungen automatisch durch Synchronisierung (Pull-Prinzip) angewendet werden.
Du installierst ArgoCD oder Flux in deinem Kubernetes Cluster.
Du gibst ArgoCD die URL zu deinem Git-Repo (github.com/my/infra).
Im Repo liegt eine deployment.yaml.
Du änderst im Git: replicas: 5.
ArgoCD merkt das (Polling oder Webhook).
ArgoCD führt kubectl apply für dich aus.
Im Dashboard siehst du: "Synced".
1. Push vs. Pull
Klassisches CI/CD (Jenkins) ist Push-basiert.
Jenkins hat den Cluster-Admin-Key (kubeconfig). Er verbindet sich von außen und feuert Befehle.
Sicherheitsrisiko: Wenn Jenkins gehackt wird, gehören dem Hacker alle Cluster.
GitOps ist Pull-basiert.
Der Agent (ArgoCD) läuft innerhalb des Clusters. Er braucht keine Admin-Keys nach außen. Er darf nur nach außen lesen (Git).
Er zieht sich die Änderungen rein.
Viel sicherer für Multi-Cluster-Umgebungen.
2. Auto-Healing (Drift Detection)
Admins sind faul. Sie machen kubectl edit deployment direkt auf dem Cluster ("Nur kurz Hotfix").
ArgoCD sieht sofort: "Cluster-Zustand != Git-Zustand".
Es markiert den Status als OutOfSync.
Wenn "Self-Heal" aktiv ist, überschreibt ArgoCD die manuelle Änderung sofort wieder.
Das erzwingt Disziplin: Jede Änderung muss durch Git (und damit durch Code Review) gehen.
3. Progressive Delivery (Flagger)
GitOps harmoniert perfekt mit Canary Deployments. Du änderst das Image im Git auf v2. ArgoCD rollt v2 aus. Der "Flagger" (Addon) übernimmt und schiebt langsam Traffic drauf (5% -> 10%). Wenn Metriken (Prometheus) schlecht werden, macht Flagger automatisch Rollback. ArgoCD zeigt dann wieder v1 an (und markiert v2 als "Failed" im Git Status, wenn es Write-Back kann).
Die Reconciliation Loop (CRDs & Operatoren)
GitOps-Lösungen (wie ArgoCD oder Flux) sind architekturell auf dem "Controller Pattern" (Operatoren) von Kubernetes aufgebaut.
Sie kreieren Custom Resource Definitions (CRDs) für Abstraktionen wie Application oder GitRepository.
Der Herzschlag davon ist der Reconciliation Loop. Ein in Go geschriebenner Controller führt endlos folgenden Kreislauf pro Ressource aus:
- Observe: Schau dir den Live-Zustand (Cluster State) an.
- Diff: Vergleiche ihn gnadenlos mit dem Desired-State (
deployment.yamlim Git). - Act: Patche, erstelle oder lösche Ressourcen per K8s-API, bis der Diff bei Null liegt. Tritt ein Network-Partition-Fehler (z. B. Docker Hub Timeout) auf, blockiert der Loop nicht, sondern retried per exponentiellem Backoff. Das System konvergiert stetig zum Zielzustand (Self-Healing).
Kustomize, Helm & Dependency Management in GitOps
Oft hast du nicht nur starres YAML, sondern ge-templatete Manifeste für Dev, Staging und Prod.
GitOps Controller verstehen nativ Abstraktionen wie Helm und Kustomize.
Flux beispielsweise führt keinen Helm install Client-Befehl von aussen (Push) aus, sondern liest dein als HelmRelease-Ressource im Git liegendes Manifest aus. Der Operator lädt den Chart aus der OCI-Registry, wertet die spezifischen values.yaml in-Cluster aus und spuckt reines, kompiliertes YAML für das Cluster aus. Du hast damit den extremen Vorteil von Helm-Dynamik, behältst aber Versionierung, Diffing-Security und Rollbacks auf purem Git-Niveau bei, ohne lokale CLI-Zustandsdrifts risikieren zu müssen.
SOPS und External Secrets (Secret Injection)
Wie überlebt eine Datenbank oder API das "Cleartext in Git"-Verbot unter GitOps-Vorgaben?
Das External Secrets Operator (ESO) Muster:
Im Git Repository committest du nur eine unkritische Hülle, die ExternalSecret heißt (key: payment-api-token, backend: AWS Secrets Manager).
Der Cluster-Operator erkennt nach dem Pull das Manifest, authentifiziert sich per IAM-Rollensystem selbstständig beim Cloud-Providers (Vault/AWS/GCP), zieht das rohe Passwort asynchron via API ab und manifestiert es als lokales Kubernetes Secret im Speicher des Clusters. Alternativ pflegen Dev-Teams Mozilla SOPS, hierbei wird die YAML-Datei asymmetrisch mit GPG verschlüsselt ins Git comitted, und erst der Fluxcd/Argo Controller hat per hardwareseitig gebundenem KMS-Key das Recht, die Datei beim Kubernetes-Apply transparent im RAM zu entpacken.
Quick-Check
Brauche ich Kubernetes für GitOps?
Jein. Der Begriff kommt aus der K8s-Welt. Aber das Prinzip (Systemzustand = Git) geht auch mit Terraform ("Atlantis") oder Ansible ("Ansible Pull"). Aber K8s ist die perfekte Plattform dafür (weil es deklarativ ist).Was, wenn Git down ist?
Dann stoppen die Updates. Aber der Cluster läuft weiter! Die "Last Known Good Configuration" ist ja schon angewendet. GitOps hat keinen Einfluss auf die Runtime-Stabilität, nur auf die Change-Rate.Secret Management?
Das größte Problem. Man darf Passwörter nicht in Git speichern. Lösungen: Sealed Secrets (verschlüsselt im Git, entschlüsselt im Cluster) oder External Secrets Operator (holt Secrets aus AWS/Vault und injiziert sie).