Learning GitOps - FluxCD - FluxCD Overview & Architecture
An introduction to FluxCD v2 as a CNCF graduated project, reasons for choosing FluxCD, comparisons with ArgoCD, and a dissection of the GitOps Toolkit architecture along with its components and core concepts.
#Introduction
In episode 1 you learned the history of GitOps and its four core principles: declarative, versioned, pulled, and reconciled. Now the question is: which tool realizes these principles practically on Kubernetes? The main answer in this series is FluxCD v2 — and this episode explains why.
We will dissect FluxCD from three directions: what it is and how it's designed, why it's an attractive choice compared to its alternatives (especially ArgoCD), and the GitOps Toolkit architecture map that powers FluxCD. After this episode, you'll be able to answer "what exactly is FluxCD?" with confidence.
#Getting to Know FluxCD v2
FluxCD v2 is the successor to Flux v1, written from scratch as a complete rewrite. Here are some facts you should know:
- It is a CNCF graduated project — one of the GitOps tools with the highest maturity and community adoption.
- Built on the GitOps Toolkit: a set of small, focused, combinable Kubernetes controllers.
- Kubernetes-native: all configuration is expressed through CustomResourceDefinition (CRD), not exotic config files.
- Extensible: because the controllers are separated, you only install the components you need.
Instead of one giant binary that does everything, FluxCD splits responsibilities across several controllers, each handling a single domain. All these controllers are installed into the flux-system namespace as Deployments with recognizable names: source-controller, kustomize-controller, helm-controller, notification-controller, plus image-reflector-controller and image-automation-controller. Quick check after installation:
kubectl get deployments -n flux-systemThe output shows all five controllers in READY status. In episode 4 we'll watch this process happen live via flux bootstrap github.
#Why Choose FluxCD
FluxCD is not popular without reason. Its main advantages:
- Kubernetes native (CRD): all sources and configurations are Kubernetes objects — inspectable with
kubectl, lockable with RBAC. - Flexible and composable: GitOps Toolkit controllers can be installed partially, fitting simple to complex needs.
- Multi-tenancy support: repositories and namespaces can be partitioned per team using the tenant pattern.
- Progressive delivery via Flagger: integration with Flagger for canary, A/B, and blue-green deployments.
- Strong community: an active project with major contributors and clean documentation.
- Vendor-neutral: supports GitHub, GitLab, Bitbucket, as well as S3, GCS, Azure Blob, and OCI registry sources.
#FluxCD vs ArgoCD
These two GitOps giants are often compared. Both are pull-based, but their approaches differ:
| Aspect | FluxCD | ArgoCD |
|---|---|---|
| Architecture | Modular toolkit, many small controllers | Monolithic, a single application |
| Primary interaction | CLI-first (flux + kubectl) | UI-first (web console) |
| Core concepts | GitRepository + Kustomization | Application + Project |
| Multi-tenancy | Namespace-based + RBAC | Project with cross-namespace scope |
| Helm | One HelmRelease per chart (chart directly from repo) | Charts bundled inside an Application |
| Progressive delivery | Flagger (separate tool) | Built-in Rollout (ApplicationSet) |
When to choose Flux? If your team is CLI and kubectl oriented, likes modular architecture, and wants per-component control. When to choose Argo? If your team is more comfortable with a graphical UI, needs built-in Progressive Delivery features, and prefers a single application that centralizes everything.
Tip
Don't get stuck in the "which is better" war. Both are equally valid — choose based on how your team works and your architectural needs. This series focuses on FluxCD, but the principles you learn apply to ArgoCD too.
#The GitOps Toolkit Architecture
This is the heart of FluxCD. The GitOps Toolkit consists of five controller groups, each with its own domain:
| Controller | Primary Responsibility |
|---|---|
| Source Controller | Pulls and verifies sources: Git, Helm, Bucket, OCI. |
| Kustomize Controller | Reconciles manifests into cluster objects. |
| Helm Controller | Manages Helm releases declaratively. |
| Notification Controller | Distributes events and alerts to external platforms. |
| Image Automation Controllers | Updates images and versions automatically. |
Its workflow is sequential: the Source Controller pulls the source, then the Kustomize Controller or Helm Controller reads that source and reconciles it into the cluster, while the Notification Controller reports status outward (Slack, GitHub, and others). The Image Automation Controllers stand apart to close the image update loop.
#Core FluxCD Concepts
Before hands-on practice, master these five terms that will keep coming up:
- Sources: objects that point to the origin of configuration —
GitRepository(a Git repo),HelmRepository(a chart index),Bucket(object storage), andOCIRepository(OCI images). - Kustomization: the object that declares "which source should be applied and how" — not a Kustomize
kustomization.yamlfile, although the two work together. - HelmRelease: the object that wraps a chart and its values, pointing to the chart source.
- Reconciliation loop: the controller mechanism that continuously brings actual state in line with declared state.
- Dependency management & health assessment: FluxCD can wait for dependencies to finish and assess the health of reconciled objects.
#Closing
Episode 2 gives you the FluxCD architecture roadmap:
- FluxCD v2 is a total rewrite of Flux v1, CNCF graduated, built on the GitOps Toolkit.
- Strengths: Kubernetes-native, modular, multi-tenancy, Flagger, community, and vendor-neutral.
- vs ArgoCD: Flux is CLI-first and toolkit-based, Argo is UI-first and monolithic — choose according to your team's needs.
- Components: Source, Kustomize, Helm, Notification, and Image Automation Controllers.
- Concepts: Sources, Kustomization, HelmRelease, reconciliation loop, dependency, and health assessment.
In episode 3 we dive deeper into the GitOps Toolkit architecture: a detailed dissection of the Source Controller, Kustomize Controller, Helm Controller, Notification Controller, and Image Automation Controllers — which CRD objects are available and how each one works. See you there!