Einführung in Flux CD

OpenGitOps beschreibt einen deklarativen Zustand, der versioniert und unveränderlich gespeichert, automatisch bezogen und kontinuierlich abgeglichen wird. Sie ordnen diese vier Prinzipien gegenüber klassischer CI/CD ein und verfolgen, wie Source, Kustomize, Helm und Notification Controller im Flux GitOps Toolkit zusammenarbeiten. An einem Ablaufbild markieren Sie Quelle, gewünschten Zustand, Reconciliation und Rückmeldung.

Das DevNinjas Dojo, unsere Cloud-Lernumgebung, stellt Ihren Cluster bereit. Sie installieren Flux mit flux bootstrap, verbinden ein Git-Repository und konfigurieren dessen Struktur. Im flux-system-Namespace betrachten Sie mit flux check und den Controller-Zuständen die Voraussetzungen für die erste Reconciliation, ohne einen fertigen Betriebszustand vorwegzunehmen.

Der Source Controller beschafft versionierte Eingaben für nachgelagerte Controller. Sie erstellen ein GitRepository-Objekt und konfigurieren Branch-Referenz sowie Reconciliation-Intervall. An einer Änderung im Repository beobachten Sie, wie Flux neue Commits erkennt und ein aktualisiertes Artefakt bereitstellt, und ordnen dazu Revision, Statusbedingungen und Ereignisse ein.

Eine Flux Kustomization verbindet ein Quellartefakt mit dem gewünschten Clusterzustand. Sie erstellen das Objekt, referenzieren vorbereitete Kubernetes-Manifeste und lassen Flux sie im Lab anwenden. Anschließend lesen Sie Inventar und Health Checks, modellieren mit dependsOn eine Abhängigkeit und untersuchen, wie Flux die gewünschte Reihenfolge verarbeitet.

Eine gemeinsame Basis kann mit Kustomize Overlays für Entwicklung, Staging und Produktion angepasst werden. Sie trennen umgebungsspezifische Konfiguration, wenden Patches, ConfigMap-Generatoren und Namespace-Anpassungen an und lassen Flux jede Variante reconciliieren. In der Lernumgebung untersuchen Sie, wie Basis und Overlays im Repository getrennt bleiben und gemeinsam ausgeliefert werden.

Der Helm Controller übersetzt deklarative HelmRelease-Objekte in Installationen und Upgrades. Sie beziehen ein Chart, setzen Values aus einer ConfigMap und prüfen Versionsauswahl, Remediation und Statusbedingungen. An der seit Flux v2.8 verfügbaren Helm-v4-Integration vergleichen Sie den Server-Side-Apply-Standard für neue HelmReleases mit der bewussten Umstellung bestehender Releases.

Seit Flux v2.6 können OCI-Artefakte als allgemein verfügbare Quelle für Kubernetes-Konfiguration dienen. Sie veröffentlichen ein Kubernetes-Manifest und ein Helm Chart in einer OCI Registry, erstellen ein OCIRepository-Objekt und verfolgen Digest sowie Revision. Danach ordnen Sie ein, wie sich Git und OCI bei Versionierung, Berechtigungen und Artefaktverteilung unterscheiden.

Die Flux-Image-Controller verbinden Registry-Inhalte mit versionierten Manifeständerungen. Sie richten den kompletten Ablauf mit ImageRepository zum Scannen, ImagePolicy zum Filtern und ImageUpdateAutomation zur Commit-Erstellung ein und definieren, welche Tags für eine Aktualisierung infrage kommen. In der Lernumgebung untersuchen Sie Reconciliation und Freigabegrenzen im Automationsablauf, ohne vollständig automatisierte Deployments pauschal freizugeben.

Secrets im Klartext widersprechen dem Schutzbedarf eines GitOps-Repositories. Sie arbeiten mit SOPS und Age-Schlüsseln, ordnen Sealed Secrets mit clusterseitiger Entschlüsselung ein und beziehen einen External Secrets Operator mit externem Secret Store ein. In der Lernumgebung vergleichen Sie, wo verschlüsselte Werte, Schlüssel und externe Quellen im jeweiligen Ablauf liegen.

Der Notification Controller verbindet Flux-Ereignisse mit externen Empfängern und eingehenden Webhooks. Sie konfigurieren einen Provider und Alert für ausgewählte Reconciliation-Ereignisse und richten anschließend einen Receiver für Änderungen aus einem externen System ein. In der Lernumgebung betrachten Sie ausgehende Benachrichtigung und eingehenden Trigger als zwei unterschiedliche Integrationsrichtungen.

Mehrere Teams auf einem Cluster benötigen explizite Vertrauens- und Berechtigungsgrenzen. Sie konfigurieren Multi-Tenancy mit eigenen ServiceAccounts, RBAC-Regeln, Namespace-bezogenen Kustomizations und eingeschränkten Source-Berechtigungen. In der Lernumgebung untersuchen Sie für mehrere Teams, wie diese Ressourcen die Zuständigkeiten der Mandanten im deklarativen Flux-Modell abbilden.

Flux und Argo CD setzen GitOps mit unterschiedlichen APIs, Erweiterungen und Bedienmodellen um. Sie vergleichen Controller- und Anwendungsmodell, CLI und Benutzeroberfläche sowie Multi-Tenancy und Image-Aktualisierung anhand eines vorbereiteten Teamszenarios. Dabei ordnen Sie ein, welche Kriterien zur Teamstruktur und Infrastruktur passen, ohne eine allgemeingültige Rangfolge abzuleiten.

Flux-Controller stellen Prometheus-Metriken für Reconciliation und Laufzeitverhalten bereit. Sie installieren einen Prometheus-Stack, importieren Flux-Dashboards und betrachten Reconciliation-Dauer, Fehlerraten, Source-Latenzen sowie Controller-Ressourcen. An diesen Signalen ordnen Sie ein, welche Beobachtungen für Monitoring und Alerting geeignet sind, ohne einen fertigen Produktionsbetrieb zu versprechen.

Eine fehlgeschlagene Reconciliation wird nachvollziehbar, wenn Quelle, Sollzustand und Controller-Rückmeldung gemeinsam betrachtet werden. In einer bereitgestellten Flux-Operator-Umgebung untersuchen Sie einen vorbereiteten Fehler über die Web UI, Ereignisse und Logs aus der CLI. Dabei vergleichen Sie die Hinweise, um mögliche Ursachen systematisch einzugrenzen.

Flagger unterstützt Progressive Delivery mit Canary, Blue/Green und A/B; im praktischen Teil bleibt der Schwerpunkt auf Canary. Sie deployen eine Beispielanwendung mit einer Canary-Strategie und beobachten, wie Flagger den Traffic anhand konfigurierter Metriken schrittweise verschiebt. Anschließend ordnen Sie Promotion und Rollback ein, ohne Blue/Green oder A/B selbst umzusetzen.