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 Argo CD, 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.
• Werkzeuge liegen auf dem Runner. kubectl, helm und ihre Versionen müssen überall installiert und synchron gehalten werden, wo deployt wird.
• Das Feedback endet bei „angewendet“. Der Job weiß, dass der API-Server das Manifest akzeptiert hat. Er weiß nicht, ob die Pods tatsächlich gesund geworden sind.

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.

Entwickler ─▶ App-Repo ─▶ CI (Test, Build) ─▶ Image-Registry
                            │
                            └─ committet neuen Image-Tag ─▶ Config-Repo
                                                            ▲
                                    Argo CD (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. Argo CD kann reines YAML, Helm-Charts und Kustomize-Overlays lesen und rendert sie zu Kubernetes-Manifesten, bevor es sie anwendet.

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, ConfigMaps, Ingresses usw.).

Der Grund: 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, und du willst keine Pipeline-Logik, die einen Commit untersucht, um zu entscheiden, was übersprungen wird. Der letzte Schritt der CI-Pipeline wird zu „den neuen Image-Tag in das Config-Repo committen“, und Argo CD übernimmt ab da. Außerdem trennt es die Verantwortlichkeiten sauber: Entwickler besitzen die CI, Plattform- oder Betriebsteams besitzen die Auslieferung.

Git zum einzigen Weg machen: Drift-Erkennung und Self-Heal

Argo CD beobachtet neben dem Repository auch den Live-Cluster. Wenn beide voneinander abweichen, wird die Anwendung als OutOfSync gemeldet. Je nach Konfiguration meldet Argo CD das dann nur oder setzt den Cluster auf den Stand von Git zurück (siehe die Anleitung zur Sync-Policy in dieser Reihe).

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. Junior-Entwickler können Pull Requests öffnen, nur wenige dürfen mergen. Dafür brauchst du keine Cluster-Rollen pro Person.
• Ein schnelles manuelles kubectl edit in der Produktion ist nicht mehr unsichtbar.

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 Argo CD bringt den Cluster darauf. Dasselbe gilt für die Wiederherstellung. Geht ein Cluster verloren, erstellst du einen neuen, installierst Argo CD, registrierst dasselbe Repository, und die Workloads werden daraus neu erzeugt. Alles, was nicht in Git liegt, etwa persistente Daten oder anderswo verwaltete Secrets, braucht weiterhin eine eigene Backup-Strategie.

Eine Argo-CD-Instanz kann außerdem viele Cluster verwalten, sodass ein einzelnes Repository eine ganze Flotte steuern kann.

Was Argo CD nicht ersetzt

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