Continuous-Delivery

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.

Right, let’s talk about locking this thing down. You’ve got your shiny ArgoCD instance running, syncing your entire universe of applications. It’s a thing of beauty. It’s also a terrifyingly powerful system that, if left open, would let an intern accidentally delete every production namespace from here to next Tuesday. We’re not about that life. We’re going to talk about giving people the exact amount of power they need, and not a bit more, using ArgoCD’s built-in Role-Based Access Control (RBAC) and then connecting it to your real identity provider (SSO) so you don’t have to manage a separate set of credentials. Because let’s be honest, you’d lose the password file.

Right, so you’ve got one application. You’ve got one cluster. You’ve got one ArgoCD Application resource pointing at one Helm chart. It’s a beautiful, simple, monogamous relationship. Then your boss walks in and says, “Great, now do that for 12 microservices across 3 environments and 5 regional clusters.” Suddenly, your neat little YAML file looks less like a solution and more like a threat. This is where you stop copy-pasting Application manifests and start using ApplicationSets. Think of an ApplicationSet as a factory—or, if you’re feeling cheeky, a YAML-cloning machine. It’s a custom resource that takes a template of an ArgoCD Application and generates actual Application resources based on a list of parameters you provide. It’s the only sane way to manage applications at scale without drowning in a sea of almost-identical YAML.

Right, so you’ve got ArgoCD happily syncing your main branch to production. It feels good, doesn’t it? You push a git commit, ArgoCD notices, and bam—your cluster matches your manifest. It’s declarative nirvana. But then you have a sobering thought: “Wait, my deployment YAML has a container image tag pinned to v1.2.3. When I build a new image, v1.2.4, I still have to manually edit a git commit and push it to update that tag.” You’re right. That is a buzzkill. You’ve automated the what and where but not the which version. This is where the ArgoCD Image Updater comes in—to automate that last, tedious, and hilariously error-prone manual step.

Right, let’s talk about what “healthy” and “synced” even mean in the cold, logical eyes of ArgoCD. This isn’t some feel-good wellness retreat; it’s a brutally honest assessment of your cluster’s state. My job is to make sure you understand the diagnosis. At its core, ArgoCD performs two distinct checks on every resource you’ve asked it to manage. First, it asks, “Are you alive and functioning correctly?” That’s Health. Then it asks, “Do you look exactly like the manifest I have in my Git repository?” That’s Sync Status. A resource can be healthy but out-of-sync (you changed a replica count in Git but haven’t applied it yet), or synced but unhealthy (you applied a broken configuration that crashed the Pod on startup). You need both to be green for me to stop nagging you.

Right, let’s talk about getting your cluster to actually do the thing you just defined in a YAML file. This is where ArgoCD stops being a fancy museum of your Git commits and starts being the engine that keeps your applications running. We call this the Sync Policy, and it’s the difference between you manually poking the deploy button and the system having a mind of its own (a blessedly obedient one, if you configure it right).

Right, let’s talk about getting your entire fleet of applications under ArgoCD’s control without losing your mind clicking buttons in the UI. If you’re manually creating an Application resource for every single microservice, you’re not doing GitOps; you’re just moving the data entry from kubectl apply to a YAML file. The real power move is the Application of Applications pattern. It’s exactly what it sounds like: an Application resource that points not to a Helm chart or Kustomize overlay of your app, but to a repository full of other Application resources. It’s declarative inception, and it’s how you bootstrap an entire environment with a single definition.

Right, let’s pull back the curtain. You’re about to deploy your entire application infrastructure by pushing a YAML file to a Git repo. It feels like magic, but magic you don’t understand is just a fancy way to get yourself into a spectacular mess. So let’s break down the three wizards behind the curtain: the Application Controller, the Repo Server, and the API Server. Knowing how they bicker and work together is the difference between “it just works” and “why is everything on fire?”

Right, let’s get this straight. You’re about to learn the one principle that makes GitOps more than just a fancy buzzword. It’s the hill the entire methodology dies on, and if you don’t internalize this, the rest of this chapter is just you learning a fancy new tool to shoot yourself in the foot with. It’s this: Git is the single source of truth. Not a source. The source. The canonical, unassailable, definitive record of what your system should look like. Your Kubernetes cluster? That’s just a runtime instance, a mere mortal reflection of the divine blueprint stored in Git. It’s transient, potentially flawed, and ultimately subservient. If the cluster gets drunk and decides to deviate from the Git manifest, Git wins. Every. Single. Time. This isn’t a suggestion; it’s the core mechanism.