Kubernetes GitOps at Scale — Multi-Cluster mit dem ApplicationSet Cluster-Generator

Dieses 115-Minuten-Modul holt genau das nach, was der Vorgängerkurs bewusst nur als Ausblick genannt hat: den Cluster-Generator. Dort habt ihr gelernt, dass ein List- oder ein Git-Directory-Generator automatisch mehrere Application-Objekte aus einer Liste oder einem Verzeichnismuster erzeugt. Der Cluster-Generator tut dasselbe, aber auf einer anderen Achse: Er erzeugt automatisch eine Application pro Cluster, der bei Argo CD registriert ist – als Kubernetes-Secret mit dem Label argocd.argoproj.io/secret-type: cluster im Namespace argocd. Registriert ihr einen zweiten Cluster, entsteht ohne jede Änderung am ApplicationSet-Manifest automatisch eine zweite Application – genau das qualitative Prinzip, das ihr beim Git-Directory-Generator schon für Verzeichnisse gesehen habt, hier übertragen auf ganze Cluster. Im ersten Hands-on baut ihr zwei eigenständige kind-Cluster (hub mit Argo CD und workload) auf und registriert workload als Cluster-Secret im Hub. Ein einziges ApplicationSet mit Cluster-Generator erzeugt daraufhin automatisch zwei Applications – eine für den Hub-Cluster selbst (der ohne eigenes Secret automatisch mitzählt) und eine für workload. Im zweiten Hands-on geht ihr einen Schritt weiter: Ein dritter Cluster, prod, wird ebenfalls registriert, aber ein selector.matchLabels-Label-Selector im Cluster-Generator ignoriert ihn zunächst – erst als ihr das Cluster-Secret explizit labelt, erscheint die zugehörige Application. Genau der Hebel für einen kontrollierten Rollout: erst registrieren, dann bewusst pro Cluster freigeben. Technischer Rahmen: Statt mehrerer Minikube-Profile (ungeprüftes Docker-Netzwerk-Risiko zwischen Profilen) läuft dieses Modul über drei eigenständige kind-Cluster – kind-Cluster landen laut kind-Quellcode automatisch im selben Docker-Netzwerk kind, ohne dass ihr dafür etwas konfigurieren müsst. Zwei Grenzen dieses Kurses werden ausdrücklich benannt: Die Docker-Netzwerk-Erreichbarkeit zwischen den Cluster-Containern bedeutet nicht, dass sich die in den Clustern laufenden Pods gegenseitig über Service-DNS erreichen können – echtes Cross-Cluster-Workload-Networking ist nicht Teil dieses Kurses. Und die verwendeten Zugangsdaten ( cluster-admin-Rechte, übersprungene TLS-Prüfung) sind eine bewusste Trainings-Vereinfachung, keine produktionsreife Absicherung. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: der Matrix-Generator (Cluster- mit Git-Directory-Generator kombiniert) sowie das values-Feld für Pro-Cluster-Parameter – beide jetzt im eigenständigen Aufbaumodul Kubernetes GitOps at Scale — Matrix-Generator: Cluster × Verzeichnis kombiniert als echtes Hands-on. Ausdrücklich NICHT Teil dieses Kurses: produktive Multi-Cluster-Topologien mit mehr als drei Clustern samt Zugangsdaten-Rotation und engerem RBAC-Scoping, sowie der Matrix-Generator als eigenes Hands-on. Pflicht ist das Modul “Kubernetes GitOps at Scale — ApplicationSet & Generators” – dieses Modul setzt dessen ApplicationSet-Grundlagen und die dort schon deployte Anwendung services/frontend direkt fort. Die Session läuft komplett lokal über kind ( Kubernetes-in-Docker) – kein Cloud-Account, keine Kostenwirkung.