Kubernetes GitOps at Scale — ApplicationSet & Generators

Dieses 110-Minuten-Modul löst das Problem, mit dem der Vorgängerkurs bewusst geendet hat: Dort habt ihr eine Parent-Application registriert, deren source ein Git-Verzeichnis mit drei Child-Application-Manifesten war – aber jede dieser drei Dateien musstet ihr weiterhin einzeln anlegen und pflegen. Bei drei Diensten ist das machbar. Bei zwanzig ist es die Aufgabe eines Generators. Genau dafür gibt es den ApplicationSet-Controller: Statt einer Application-Datei pro Anwendung schreibt ihr ein einziges ApplicationSet-Objekt, das über einen Generator automatisch beliebig viele Child-Applications erzeugt. Drei Generator-Typen lernt ihr heute kennen: den List-Generator (eine feste Liste von Key/Value-Paaren im Manifest selbst), den Git-Directory-Generator (jedes Verzeichnis, das einem Muster im Repo entspricht, wird automatisch zu einer Application) und – nur als Ausblick – den Cluster-Generator (eine Application pro registriertem Ziel-Cluster). Im ersten Hands-on baut ihr einen List-Generator, der aus einer festen Liste von drei Diensten automatisch drei Child-Applications erzeugt – dieselben drei Dienste (frontend, backend, worker), für die ihr im Vorgängerkurs noch drei einzelne Dateien in apps/ angelegt habt. Im zweiten Hands-on geht ihr einen Schritt weiter: Ihr legt einen Git-Directory-Generator an, der ein Verzeichnismuster im Repo beobachtet, und committet danach einen komplett neuen Ordner für einen vierten Dienst – ohne irgendeine Application-YAML anzufassen. Live seht ihr, wie der ApplicationSet-Controller daraus automatisch eine vierte Child-Application erzeugt. Zwei Grenzen dieses Kurses werden ausdrücklich benannt: Der Git-Generator pollt das Repo standardmäßig alle drei Minuten statt sofort zu reagieren – kein Bug, sondern eine bewusste Konfigurationsentscheidung, die sich per Webhook umgehen lässt. Und ein Tippfehler in einer Template-Variablen erzeugt keinen harten Validierungsfehler beim kubectl apply, sondern eine fehlerhafte oder unvollständig gerenderte Application, die erst beim Sync auffällt. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: der Cluster-Generator für Multi-Cluster-Rollouts sowie eine Abgrenzung zu Flux’ eigenem dependsOn-Modell. Ausdrücklich NICHT Teil dieses Kurses: ein eigenständiger Multi-Cluster-Hands-on, produktive Webhook-Konfiguration gegen einen echten Git-Provider und weitere Generator-Typen (SCM-, Pull-Request-, Matrix-/Merge-Generator). Pflicht ist das Modul “Kubernetes GitOps at Scale — App-of-Apps & Sync-Waves” – dieses Modul setzt dessen Git-Repo und Minikube-Cluster direkt fort, statt sie zu wiederholen. Die Session läuft komplett lokal über Minikube ( –driver=docker) – der ApplicationSet-Controller läuft rein containerisiert im Cluster, ohne Cloud-Account und ohne Kostenwirkung.