Introduction to Flux CD

What sets GitOps apart from traditional CI/CD, and why are more teams adopting the declarative approach? You will learn the four GitOps principles and understand how Flux implements them through its GitOps Toolkit: Source Controller, Kustomize Controller, Helm Controller and Notification Controller work together as independent Kubernetes operators. By the end of this block, you can explain the Flux architecture on a whiteboard.

Theory is good, practice is better: you install Flux using flux bootstrap on your own cluster and connect it to a Git repository. You configure the repository structure, set up the flux-system namespace and verify all controllers are running correctly with flux check. Each participant works in their own cloud environment.

The Source Controller is the heart of Flux: it watches Git repositories, Helm repos and OCI registries for changes. You create your first GitRepository object, configure branch selectors and reconciliation intervals, and watch live as Flux detects new commits and produces artifacts.

Time to deploy: you create a Kustomization object and let Flux automatically apply your Kubernetes manifests to the cluster. Health checks show you whether the deployment succeeded. You configure dependency management between Kustomizations so that infrastructure rolls out before applications.

One repository, three environments: you build a multi-environment setup with Kustomize overlays for dev, staging and production. You cleanly separate environment-specific configuration from the base using patches, ConfigMap generators and namespace overrides. The result is a Git structure you can transfer directly to your daily projects.

Many teams rely on Helm charts for their deployments. The Flux Helm Controller manages HelmRelease objects that automatically install, upgrade and roll back charts on failure. You configure values overrides from ConfigMaps, test chart versioning with SemVer ranges and see how, since Flux v2.8, Helm v4 server-side apply resolves the ownership conflicts that were common in earlier versions.

Git is not the only way: since Flux v2.6, OCI artifacts are a full delivery channel for manifests and Helm charts. You push a Kubernetes manifest and a Helm chart to an OCI registry (e.g. GitHub Container Registry) and configure an OCIRepository object as source. The advantage: the same registry for container images and deployment artifacts, less infrastructure, faster reconciliation.

New container version built, now what? The Image Automation Controller watches container registries, detects new image tags based on policies (SemVer, alphabetical, numerical) and automatically updates manifests in the Git repository. You set up the complete flow: ImageRepository for scanning, ImagePolicy for filtering and ImageUpdateAutomation for committing. The result: from registry push to deployment without manual intervention.

Secrets do not belong in plaintext in a Git repository. You work with three approaches that cover different requirements:

• SOPS encrypts secrets directly in YAML files using Age keys, with Flux decrypting automatically during deployment
• Bitnami Sealed Secrets uses a cluster controller so developers can create secrets without knowing the decryption key
• External Secrets Operator synchronizes secrets from external vaults like AWS Secrets Manager, HashiCorp Vault or Azure Key Vault into Kubernetes

By the end, you know which approach fits your security model: Git-native, cluster-side or central vault.

Flux works in the background, but your team needs transparency. With the Notification Controller you configure alerts that are sent to Slack, Microsoft Teams or other channels on failed reconciliations or successful deployments. Additionally, you set up webhook receivers so external systems (e.g. GitHub, Harbor) can immediately notify Flux about changes.

In enterprises, multiple teams share a cluster. You configure multi-tenancy with Flux: dedicated ServiceAccounts and RBAC roles per tenant, namespace isolation, restricted source and Kustomization permissions. Onboarding a new team becomes a declarative Git commit instead of a ticket marathon.

Both tools are CNCF Graduated, but their philosophy differs fundamentally. You compare Flux and Argo CD using concrete criteria: controller architecture vs. monolithic application, CLI-first vs. web-UI-first, pull-based vs. app-of-apps pattern. Based on a real scenario, you evaluate which tool fits which team structure and infrastructure. No holy war, but an informed decision-making foundation.

How do you know Flux is working correctly? You install the kube-prometheus-stack and import the official Flux Grafana dashboards. At a glance you see: reconciliation duration, error rates, source latencies and controller resource consumption. When anomalies occur, the Prometheus alerting rules you configured in the previous block kick in.

The Flux Operator Web UI provides a graphical interface for Flux clusters: sync status, GitOps graphs for delivery pipelines and detail views for HelmReleases and Kustomizations. In parallel, you learn the CLI tools for daily work: flux logs, flux events, flux trace and flux diff help you systematically debug failed reconciliations.

To close, a look beyond the basics: Flagger extends Flux with canary deployments, blue/green and A/B testing. You deploy a sample application with a canary strategy and watch Flagger gradually shift traffic and automatically roll back on error metrics. This block gives you a solid foundation to evaluate progressive delivery for your projects.