Flux CD

Flux's Architecture#

Flux v2's design split a monolithic controller into the GitOps Toolkit — a set of independent controllers that compose. The source-controller fetches Git, Helm, OCI, or S3 sources. The kustomize-controller and helm-controller render and apply manifests. The image-reflector and image-automation controllers watch container registries and update manifests in Git. The notification-controller fans out events to Slack, MS Teams, Discord, GitHub status, and others.

The trade-off vs Argo CD: more components to deploy and reason about, but each one is small, replaceable, and independently version-pinned. Operators who want fine-grained control of each layer prefer this; operators who want one binary prefer Argo CD.

Custom Resources#

• GitRepository, HelmRepository, OCIRepository, Bucket — declarative sources.
• Kustomization — render a Kustomize overlay from a source and apply it.
• HelmRelease — install/upgrade a Helm chart from a source.
• ImageRepository + ImagePolicy + ImageUpdateAutomation — watch a registry, choose a tag, write the chosen tag back to Git.
• Alert + Provider + Receiver — outbound notifications + inbound webhooks.

Kustomization Example#

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: ml-platform
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example-org/ml-platform-gitops
  ref: { branch: main }
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: ml-platform-prod
  namespace: flux-system
spec:
  interval: 5m
  sourceRef: { kind: GitRepository, name: ml-platform }
  path: ./deploy/kustomize/overlays/prod
  prune: true
  wait: true

Image Automation#

Flux's image-automation pipeline is genuinely useful in CI/CD: the image-reflector-controller polls a container registry, the image-automation-controller picks the newest matching tag and commits a manifest update back to Git, the kustomize-controller deploys it. The commit becomes the audit trail — every running version is traceable to the Git commit that introduced it.

Argo CD has the same capability via the separate Image Updater project, but in Flux it is a first-class part of the core distribution.

Multi-Tenancy#

Flux v2 has a stricter tenancy story than Argo CD's AppProjects. Each tenant gets its own namespace, its own ServiceAccount, and Flux controllers impersonate that SA when reconciling — so a tenant cannot apply manifests outside their namespace even if they push manifests to Git for it. This is the right model for sovereign multi-tenant clusters where the operator must prove tenant isolation to auditors.

Cluster API Integration#

Flux is the canonical GitOps engine for Cluster API (CAPI) fleets — declarative provisioning of Kubernetes clusters themselves, managed from a parent cluster. Each managed cluster's bootstrap reconciles via Flux from Git; the parent cluster's Flux reconciles the CAPI Cluster objects. This is the cleanest pattern for managing tens to hundreds of edge clusters from a central control plane.

Flux vs Argo CD: Pragmatic Choice#

If your team values a polished UI, fleet management dashboards, and a single binary — Argo CD. If your team values composability, modular controllers, native image automation, and stricter multi-tenancy — Flux. Both are CNCF Graduated, both will run for years without drama, both have major enterprise customers. The cost of switching is real but bounded.