Kubernetes GitOps at Scale — App-of-Apps & Sync-Waves

In diesem 110-Minuten-Modul löst ihr ein Problem, das im ArgoCD-Kurs bewusst außen vor geblieben ist: Eine einzelne Application pro Kommando zu pflegen funktioniert für eine Demo, aber nicht für zehn, zwanzig oder hundert Anwendungen – spätestens dann will niemand mehr jede Application einzeln per kubectl apply anlegen. Das App-of-Apps-Pattern löst das: Eine Parent-Application zeigt nicht auf rohe Deployment-Manifeste, sondern auf ein Git-Verzeichnis voller Application-Manifeste – und wenn die Parent-Application synct, legt ArgoCD alle darin beschriebenen Child-Applications selbst an. Danach seziert ihr die Sync-Waves: die Annotation argocd.argoproj.io/sync-wave, mit der sich eine erzwungene Reihenfolge zwischen Ressourcen durchsetzen lässt, die voneinander abhängen – etwa ein Namespace vor einem Secret, das wiederum vor einem Deployment existieren muss, das dieses Secret mountet. Im ersten Hands-on registriert ihr eine Parent-Application, deren source ein Git-Verzeichnis mit drei Child-Application-Manifesten ist, löst den Sync aus und beobachtet live, wie ArgoCD alle drei Child-Applications automatisch anlegt und synct – ohne dass ihr eine einzige davon selbst per kubectl apply registriert. Im zweiten Hands-on baut ihr euch zunächst bewusst eine Race-Bedingung: Namespace, Secret und Deployment gleichzeitig ohne Sync-Wave deployen, und live sehen, wie das Deployment das Secret nicht mounten kann, weil es zum Zeitpunkt des Pod-Starts noch nicht existiert. Anschließend behebt ihr das mit sync-wave-Annotationen ( -1/0/1) und beobachtet, wie ArgoCD jetzt wartet, bis eine Welle abgeschlossen ist, bevor die nächste startet. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: ApplicationSet als Generator-basierte Alternative zum manuell gepflegten Child-App-Verzeichnis, sowie eine vertiefte Abgrenzung zu Flux’ eigenem Dependency-Modell. Ausdrücklich NICHT Teil dieses Kurses: Progressive Delivery mit Argo Rollouts (eigenes Aufbaumodul), CI/Image-Build und ein eigenständiger Multi-Cluster-Hands-on – der Anwendungsfall Multi-App-/Cluster-Bootstrap wird benannt und eingeordnet, aber nicht selbst als zweiter Cluster aufgebaut. Pflicht ist das Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” – dieses Modul setzt dessen Git-Repo und ArgoCD-Installation direkt fort, statt sie zu wiederholen. Die Session läuft komplett lokal über Minikube (–driver=docker) – ArgoCD selbst läuft rein containerisiert im Cluster, ohne Cloud-Account und ohne Kostenwirkung.