Introduction to Flux CD

OpenGitOps describes a declarative state that is stored as versioned and immutable, pulled automatically, and continuously reconciled. You position these four principles alongside traditional CI/CD and trace how the Source, Kustomize, Helm, and Notification Controllers cooperate in the Flux GitOps Toolkit. On a workflow diagram, you mark the source, desired state, reconciliation, and feedback.

The DevNinjas Dojo, our cloud learning environment, provides your cluster. You install Flux with flux bootstrap, connect a Git repository and configure its structure. In the flux-system namespace, you use flux check and controller states to examine the prerequisites for the first reconciliation without presenting a completed operating state.

The Source Controller retrieves versioned inputs for downstream controllers. You create a GitRepository object and configure its branch reference and reconciliation interval. Using a repository change, you observe how Flux detects a new commit and produces an updated artifact, then relate its revision, status conditions, and events.

A Flux Kustomization connects a source artifact to the desired cluster state. You create the object, reference prepared Kubernetes manifests, and let Flux apply them in the lab. You then inspect inventory and health checks, model a dependency with dependsOn, and examine how Flux processes the intended order.

One shared base can be adapted with Kustomize overlays for development, staging, and production. You separate environment-specific configuration, apply patches, ConfigMap generators, and namespace changes, and let Flux reconcile each variant. In the lab, you examine how the base and overlays remain separate in the repository while being delivered together.

The Helm Controller translates declarative HelmRelease objects into installations and upgrades. You source a chart, provide values from a ConfigMap, and inspect version selection, remediation, and status conditions. With the Helm v4 integration available since Flux v2.8, you compare the server-side apply default for new HelmReleases with the deliberate opt-in for existing releases.

Since Flux v2.6, OCI artifacts have been generally available as a source for Kubernetes configuration. You publish a Kubernetes manifest and a Helm chart to an OCI registry, create an OCIRepository object, and trace its digest and revision. You then examine how Git and OCI differ in versioning, permissions, and artifact distribution.

The Flux image controllers connect registry contents with versioned manifest changes. You set up the complete flow with ImageRepository for scanning, ImagePolicy for filtering, and ImageUpdateAutomation for commit creation and define which tags are eligible for an update. In the lab, you examine reconciliation and approval boundaries in the automation flow without generally approving fully automated deployments.

Plaintext secrets conflict with the protection needs of a GitOps repository. You work with SOPS and Age keys, examine Sealed Secrets with cluster-side decryption, and include an External Secrets Operator backed by an external secret store. In the lab, you compare where encrypted values, keys, and external sources sit within each workflow.

The Notification Controller connects Flux events with external recipients and incoming webhooks. You configure a provider and alert for selected reconciliation events, then set up a receiver for changes from an external system. In the lab, you examine outgoing notifications and incoming triggers as two different integration directions.

Multiple teams on one cluster require explicit trust and permission boundaries. You configure multi-tenancy with dedicated service accounts, RBAC rules, namespace-scoped Kustomizations, and restricted source permissions. In the lab, you examine for several teams how these resources represent tenant responsibilities within Flux's declarative model.

Flux and Argo CD implement GitOps through different APIs, extensions, and interaction models. You compare their controller and application models, CLI and user interface, multi-tenancy, and image updates through a prepared team scenario. You assess which criteria fit the team structure and infrastructure without deriving a universal ranking.

Flux controllers expose Prometheus metrics for reconciliation and runtime behaviour. You install a Prometheus stack, import Flux dashboards, and examine reconciliation duration, error rates, source latency, and controller resources. Using these signals, you consider which observations support monitoring and alerting without promising a completed production setup.

A failed reconciliation becomes traceable when source, desired state, and controller feedback are considered together. In a provided Flux Operator environment, you investigate a prepared fault through the Web UI, events, and logs from the CLI. You compare the evidence to narrow down possible causes systematically.

Flagger supports progressive delivery with canary, blue/green, and A/B strategies; the practical work focuses on canary. You deploy a sample application with a canary strategy and observe how Flagger gradually shifts traffic according to configured metrics. You then assess promotion and rollback without implementing blue/green or A/B as separate exercises.