Die meisten Teams beginnen das Deployment auf Kubernetes auf dieselbe Weise: Das CI-System baut ein Image und führt dann kubectl apply oder helm upgrade gegen den Cluster aus. Das funktioniert, bis die Zahl der Anwendungen und Cluster wächst. Diese Anleitung erklärt, was sich ändert, wenn stattdessen ein Agent im Cluster, wie Flux, den Soll-Zustand aus Git zieht, und welche Kompromisse damit einhergehen.

Das Push-Modell und wo es an Grenzen stößt

In einer Push-Pipeline ist der CI-Job das Einzige, was den Cluster anfasst:

1. Ein Commit löst Tests und einen Image-Build aus.
2. Der Job aktualisiert ein Manifest mit dem neuen Image-Tag.
3. Der Job führt kubectl apply (oder helm upgrade) gegen den Cluster aus.

Mit wachsender Größe zeigen sich drei Probleme:

• Zugangsdaten liegen außerhalb des Clusters. Jede Pipeline braucht eine kubeconfig oder Cloud-Zugangsdaten, und das vervielfacht sich mit jeder Anwendung und jedem Cluster.
• Es passiert einmalig. Nachdem der Job beendet ist, beobachtet nichts den Cluster. Das kubectl edit von jemandem vor zwei Wochen bleibt unsichtbar, bis es einen Vorfall verursacht.
• Es gibt keine einfache Antwort auf „was ist deployt?“. Du musst den Cluster selbst inspizieren, weil der letzte Lauf der Pipeline keine verlässliche Aufzeichnung ist.

Die Richtung umkehren: Pull

Beim Pull-Modell läuft ein Agent im Cluster, beobachtet ein Git-Repository, vergleicht, was dort deklariert ist, mit dem, was läuft, und wendet die Differenz an. Flux ist dieser Agent. Er besteht aus mehreren kleinen Controllern, die jeweils eine Aufgabe erledigen:

Controller	Was er tut
source-controller	Holt Git-Repositories, Helm-Repositories, OCI-Artefakte und Buckets und stellt sie den anderen bereit
kustomize-controller	Baut und wendet Kubernetes-Manifeste (reines YAML oder Kustomize-Overlays) aus einer Source an
helm-controller	Installiert, upgradet, testet und rollt Helm-Releases zurück
notification-controller	Sendet Alerts (Slack, Teams und andere) und empfängt Webhooks
image-reflector / image-automation controllers	Optional. Scannen Container-Registries und committen neue Image-Tags zurück nach Git

Entwickler ─▶ App-Repo ─▶ CI (Test, Build) ─▶ Image-Registry
                            │
                            └─ committet neuen Image-Tag ─▶ Config-Repo
                                                            ▲
                                          Flux (im Cluster) ┘ zieht, vergleicht, wendet an
                                                │
                                                ▼
                                            Kubernetes

Cluster-Zugangsdaten verlassen den Cluster nie, weil nur der Agent im Cluster Änderungen anwendet. Menschen und CI-Systeme brauchen nur Schreibzugriff auf Git.

Die vier GitOps-Prinzipien

Die OpenGitOps-Arbeitsgruppe definiert GitOps über vier Prinzipien. Flux setzt alle um:

1. Deklarativ. Das System wird in YAML beschrieben, nicht in Skripten.
2. Versioniert und unveränderlich. Git ist die einzige Quelle der Wahrheit. Jede Änderung ist ein Commit, der geprüft und zurückgenommen werden kann.
3. Automatisch gezogen. Freigegebene Änderungen werden vom Cluster geholt, nicht an ihn gepusht.
4. Kontinuierlich abgeglichen. Agents vergleichen Soll- und Ist-Zustand und korrigieren Drift.

Flux verwaltet sich selbst

Ein besonderes Flux-Merkmal ist Bootstrap. Der Befehl flux bootstrap installiert Flux in den Cluster und committet Fluxs eigene Manifeste in dein Git-Repository, und konfiguriert Flux dann so, dass es aus genau diesem Repository synchronisiert. Vom ersten Tag an wird sogar das GitOps-Werkzeug über Git verwaltet. Die nächste Anleitung führt es Schritt für Schritt durch.

Anwendungscode und Konfiguration in getrennten Repositories halten

Üblich ist die Empfehlung, zwei Repositories zu verwenden: eines für den Anwendungs-Quellcode, eines für die Kubernetes-Konfiguration (Deployments, Services, HelmReleases usw.).

Konfiguration ändert sich nach ihrem eigenen Takt. Das Bearbeiten eines Services oder einer ConfigMap sollte keine vollständige Build-und-Test-Pipeline für Code auslösen, der sich nicht geändert hat. Mit zwei Repositories wird der letzte Schritt der CI-Pipeline zu „den neuen Image-Tag in das Config-Repo committen“, und Flux übernimmt ab da. Außerdem trennt es die Verantwortlichkeiten sauber: Entwickler besitzen die CI, Plattform- oder Betriebsteams besitzen die Auslieferung.

Flux bietet dir zwei Wege, den neuen Image-Tag in das Config-Repo zu bekommen:

• CI committet ihn. Ein Skript in der Pipeline aktualisiert den Tag im YAML und pusht. Das funktioniert mit jedem CI-System.
• Flux committet ihn. Die optionalen Image-Automation-Controller beobachten die Registry und pushen die Tag-Änderung selbst nach Git. Siehe die Anleitung zur Image-Automatisierung in dieser Reihe.

Git zum einzigen Weg machen: Drift-Korrektur

Flux gleicht in einem Intervall ab. Weicht der Live-Cluster von Git ab, wendet Flux Gits Version erneut an, sodass eine manuelle Änderung zurückgesetzt wird. Das hat praktische Folgen:

• Jede Änderung hat einen Commit, einen Autor und meist einen geprüften Pull Request, was dir einen Audit-Trail liefert.
• Berechtigungen wandern nach Git. Viele Leute können Pull Requests öffnen, nur wenige dürfen mergen.
• Ein schnelles manuelles kubectl edit in der Produktion ist keine stille, dauerhafte Änderung mehr.

Rollback und Wiederherstellung werden zu Git-Operationen

Weil der Soll-Zustand versioniert ist, ist die Rückkehr zu einem bekannten guten Zustand ein git revert, und Flux bringt den Cluster darauf. Dasselbe gilt für die Wiederherstellung. Geht ein Cluster verloren, erstellst du einen neuen, führst flux bootstrap gegen dasselbe Repository und denselben Pfad aus, und die Workloads werden aus Git neu erzeugt. Alles, was nicht in Git liegt, etwa persistente Daten oder anderswo verwaltete Secrets, braucht weiterhin eine eigene Backup-Strategie.

Was Flux nicht ersetzt

Flux ist ein Auslieferungs-Toolkit, kein Build-Werkzeug. Du brauchst weiterhin CI, um Code zu testen, Images zu bauen und in eine Registry zu pushen. Es ist Kubernetes-spezifisch, andere Deployment-Ziele brauchen also andere Werkzeuge. Und es ist nicht der einzige GitOps-Controller: Argo CD setzt dieselben Prinzipien mit einem anderen Design um, was die Vergleichsanleitung in dieser Reihe behandelt. Der Rest dieser Reihe setzt Flux voraus und beginnt mit der Installation. Die vollständige Referenz findest du in der offiziellen Flux-Dokumentation.