Kubernetes GitOps mit Flux — Abgrenzung und Umstieg von ArgoCD

Drei Kurse dieses Repos haben eine Abgrenzung zu Flux angekündigt und sie bewusst nicht vertieft – dieses 110-Minuten-Modul löst genau dieses Versprechen ein. Statt Flux nebenbei in einer Zeile zu erwähnen, seziert ihr die Flux-Architektur strukturell gegen das bereits bekannte ArgoCD-Modell: Wo ArgoCD eine einzige Application-CRD für Quelle, Ziel und Sync-Policy verwendet, trennt Flux das in eigenständige Controller und Custom Resources – source-controller für Herkunft ( GitRepository, HelmRepository, OCIRepository), kustomize-controller für reine Kubernetes-Manifeste über die Kustomization-CRD, und helm-controller für Helm-Releases über die HelmRelease-CRD. Im ersten Hands-on installiert ihr Flux ohne Git-Bootstrap-Assistenten per kubectl apply gegen das offizielle Install-Manifest, registriert eine GitRepository gegen dasselbe eigene Git-Repo, mit dem ihr schon im ArgoCD-Kurs gearbeitet habt, und darauf aufbauend eine Kustomization, die dieses Repo tatsächlich in Cluster-Ressourcen übersetzt – und beobachtet die Reconciliation live per flux get kustomizations. Danach seziert ihr das Dependency-Modell: Die Kustomization -Eigenschaft dependsOn erzwingt eine Reihenfolge – aber zwischen ganzen Kustomization-Objekten, deren Ready-Bedingung erfüllt sein muss, nicht zwischen einzelnen Ressourcen innerhalb eines Objekts wie bei ArgoCDs Sync-Wave-Annotation. Im zweiten Hands-on baut ihr genau das nach: zwei getrennte Kustomization-Objekte, eines mit dependsOn auf das andere, und beobachtet, wie Flux nachweislich wartet, bis die referenzierte Kustomization Ready ist, bevor die abhängige angewendet wird. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: das Umstiegs- und Koexistenz-Szenario – Flux und ArgoCD können denselben Cluster parallel bedienen, solange beide nur disjunkte Ressourcen reconcilen, und ein Umstieg lässt sich Anwendung für Anwendung durchführen –, sowie HelmRelease als Flux-Pendant zum ArgoCD-Ausblick auf Helm-Chart-als-Application-Source. Ausdrücklich NICHT Teil dieses Kurses: eine erneute Erklärung von Reconciliation-Loop und Pull-Prinzip – das gilt aus dem ArgoCD-Kurs als bekannt –, Progressive Delivery, ein eigenständiger Multi-Cluster-Hands-on und eine allgemeine GitOps-Einführung (die gibt es bereits als frei zugänglichen Artikel). Pflicht ist das Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD”; empfohlen, aber keine Pflicht, sind “Kubernetes GitOps at Scale — App-of-Apps & Sync-Waves” und “Kubernetes GitOps at Scale — ApplicationSet & Generators” – wer sie kennt, erlebt den direkten Vergleich dependsOn gegen Sync-Wave bzw. Flux gegen ApplicationSet aus erster Hand. Die Session läuft komplett lokal über Minikube ( –driver=docker) oder kind – Flux selbst läuft rein containerisiert im Cluster, ohne Cloud-Account und ohne Kostenwirkung.