Flux isn’t just another GitOps tool; it’s a system that fundamentally changes how you think about deploying code by making your Git repository the single source of truth for your cluster’s desired state.
Let’s see Flux in action. Imagine you have a simple web application. You’ve defined its Kubernetes deployment and service in YAML files, and these are stored in a Git repository.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-registry/my-app:v1.0.0
ports:
- containerPort: 8080
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
Flux, running in your cluster, continuously monitors this Git repository. When you push a new commit—say, updating the image tag in deployment.yaml to v1.0.1—Flux detects this change. It then pulls the updated manifest and applies it to your Kubernetes cluster, ensuring the cluster’s state matches your Git repository.
The core problem Flux solves is bridging the gap between your intention (expressed in Git) and the reality of your running applications in Kubernetes. Traditionally, this involves manual kubectl apply commands or complex CI/CD pipelines that push changes to the cluster. Flux reverses this: the cluster pulls its desired state from Git. This Git-centric approach provides a clear audit trail, enables easy rollbacks by reverting Git commits, and empowers developers to manage deployments directly.
Flux achieves this through a set of controllers, each responsible for a specific aspect of the GitOps workflow. The Source Controller fetches manifests from various sources (Git, Helm repositories, S3 buckets). The Kustomize Controller applies Kustomize configurations. The Helm Controller manages Helm releases. And the Notification Controller handles events and alerts. Together, they form a robust system for continuous reconciliation of your cluster’s state with your Git repository.
When you promote releases through environments like staging and production, you’re essentially managing different branches or directories within your Git repository. For instance, your staging environment might reference a specific branch or path in Git that contains the manifests for staging, while your production environment points to another.
# flux-system/gotk-sync.yaml (simplified example)
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: my-app-repo
namespace: flux-system
spec:
interval: 1m
url: ssh://git@github.com/your-org/your-repo.git
ref:
branch: main # Or a specific path for staging/production
# ... other configurations
# flux-system/gotk-kustomization-staging.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: my-app-staging
namespace: flux-system
spec:
interval: 5m
path: ./kustomizations/staging # Path within the Git repo
sourceRef:
kind: GitRepository
name: my-app-repo
prune: true
validation: client
# ... other configurations
To promote a release from staging to production, you would update your production configuration (e.g., change the path or ref in the Kustomization manifest for production to point to the new version’s artifacts). Flux, observing this change in its own configuration (which is also typically managed in Git), will then pull the new production manifests and apply them.
The most surprising part of Flux’s operation is how it handles drift detection and reconciliation. It doesn’t just apply changes; it continuously watches the actual state of your cluster. If a resource is manually changed outside of GitOps (e.g., someone runs kubectl edit deployment my-app), Flux will detect this discrepancy during its next reconciliation loop and automatically revert the change to match the state defined in Git. This ensures that your cluster always adheres to the declared state, preventing configuration drift.
The next logical step after mastering GitOps promotion is to explore automated canary deployments and progressive rollouts using Flux’s integration with tools like Flagger.