Flux CD: Git as the Source of Truth for Kubernetes

Why it exists

Traditional CI/CD pipelines often push changes to Kubernetes, which requires giving the CI system powerful cluster credentials and can lead to 'configuration drift' where the live cluster state no longer matches version control. Flux was created to solve this by having an in-cluster agent pull changes, making Git the indisputable source of truth.

The mental model

Think of Flux as a robot living inside your Kubernetes cluster. Its only job is to stare at a Git repository you've designated. When it sees a new commit, it pulls the changes and methodically makes the cluster's state match the configuration defined in the Git repo's manifests. It's a one-way synchronization from Git to Kubernetes.

How it works

Flux is a set of controllers that run inside your cluster. After a flux bootstrap command, these controllers begin a reconciliation loop. The main components are: the Source Controller, which fetches artifacts from Git, Helm, or OCI repositories; the Kustomize Controller, which applies plain Kubernetes YAML; the Helm Controller, which manages Helm chart releases; and Image Automation Controllers, which can update YAML in Git when a new container image is published. These agents work together to continuously align the cluster's state with the desired state in Git.

When to use it

Use Flux to implement GitOps for Kubernetes. It's ideal for teams wanting a declarative, auditable, and automated way to manage cluster configuration and application delivery. Because it ensures consistency from a central repository, it excels in managing multiple environments or clusters (dev, staging, prod) from different branches or folders in Git.

When not to use it

Flux is Kubernetes-native; it is not a general-purpose automation tool for other infrastructure. Crucially, Flux is not a CI tool. It does not build your code, run tests, or publish artifacts. You still need a separate system like GitHub Actions or Jenkins for the CI part of your pipeline. Flux handles the Continuous Delivery (CD) from an artifact source to the cluster.

One canonical example

A developer changes the container image tag in a deployment.yaml file and pushes the commit to the main branch. Flux's Source Controller, polling the Git repo, detects the change. It signals to the Kustomize Controller that there's a new version of the manifest. The Kustomize Controller applies the change, and Kubernetes triggers a rolling update of the application to the new version. The entire process is automated after the git push.