Flux

Alright, let’s cut through the noise. You’re sold on GitOps—the idea of declaring your desired state in git and having something automatically reconcile your cluster is brilliant. But now you’re staring down two giants: ArgoCD and Flux. This isn’t a Coke vs. Pepsi choice; it’s more like choosing between a Swiss Army knife and a perfectly balanced chef’s knife. Both are excellent tools, but they have different philosophies and sweet spots. Let’s get into the weeds.

Right, so you’ve got Flux humming along, deploying your apps beautifully. But now you’ve got a new problem: other people. Maybe it’s another team, a contractor, or a client who needs a sliver of your cluster. You need to give them a sandbox—a dedicated namespace with GitOps superpowers—without handing them the keys to the entire kingdom and your prized prod database. This, my friend, is where namespaced tenancy in Flux saves the day.

Right, so you’ve got Flux deployed and your manifests are happily syncing from Git. Fantastic. But let’s be honest: you’re not really doing GitOps until you’ve automated the most common, tedious, and error-prone task of them all—updating a flipping image tag. You know the drill. A new version of your app (v1.2.3) gets built, pushed to your registry, and now you, the brilliant human, have to: git clone the repo. Manually find and edit deployment.yaml (or worse, a Kustomize patch). git commit -m "bump image to v1.2.3 because I am a glorified search-and-replace tool". git push. Wait for Flux to sync the change. Hope you didn’t typo v.1.2.3 and break everything. This is absurd. We have robots for this. Flux’s Image Automation controllers are those robots. Their job is to watch your container registry, notice new tags, and—this is the key part—write a new commit back to your Git repository with the updated tag. The automation loop is closed. You get a pull request or a direct commit (your choice, you maniac) and Flux applies the change itself. It’s beautiful.

Right, so you’ve got your cluster bootstrapped with Flux. It’s happily syncing your Kustomization resources, and you feel like you’ve got a handle on this whole GitOps thing. But let’s be real: you’re probably not just deploying raw YAML. You’re almost certainly using Helm charts, either your own or, more likely, a bunch from the community. Manually running helm install or helm upgrade is a hard no-go in our new GitOps utopia. It’s a imperative speck in our declarative masterpiece. This is where the HelmRelease comes in to save the day, and your sanity.

Right, so you’ve got your Git repository set up as your source of truth—your single, glorious, version-controlled system of record. But let’s be honest, you’re probably not deploying the exact same YAML to every environment. You need to change the number of replicas in production, or swap out a config map for staging. This is where Kustomize struts in, and Flux’s Kustomization resource is how you make it dance. Think of a Kustomization (the Flux kind, capitalized, we’ll get to that) as the conductor of your deployment orchestra. It doesn’t hold the musical scores itself; it points to a directory in your Git repo that contains your kustomization.yaml (the Kustomize kind, lowercase, yes it’s confusing) and then it tells Flux, “Hey, go to this git repository, grab everything in this folder, run kustomize build on it, and apply the resulting YAML to the cluster.” It’s the crucial link between your fancy, overlayed manifests and the cluster they’re supposed to run on.

Right, let’s talk about where Flux gets its marching orders from. You’ve told it to deploy your fancy app, but Flux, being the pedantic but brilliant robot it is, refuses to take your word for it. It needs to see things in writing. In Git. This is where GitRepository and HelmRepository come in—they are Flux’s primary sources for truth, the well from which it draws all its manifests and charts.

Alright, let’s pull back the curtain on Flux’s architecture. Forget the marketing fluff; we’re here to talk about the moving parts that actually do the work. At its core, Flux isn’t a single monolithic application. It’s a collection of specialized controllers, each with a single, well-defined job. This is a brilliant design choice because it means you can use just the parts you need and understand exactly what’s failing when (not if) something goes sideways.