Every now and then, I open the CNCF Landscape and think: Would most non-engineers be able to differentiate if these are names of Software Engineering tools or Pokémon?
So when I casually mentioned "I'm doing GitOps now" in a team meeting, I was immediately bombarded with:
"Oh, are you using Argo?"
"ArgoCD or Argo Workflows?"
"Why not Flux?"
"Flux v1 or v2?"
"Are you using Helm?"
"Helm with Kustomize or just Helm?"
"What about Jsonnet?"
"Have you tried Kapitan?"
"Don't forget Argo Events!"
"And Argo Rollouts!"
I nodded along, pretending I knew what everyone was talking about, frantically taking notes that looked like:
Argo (CD? Workflows? Events? Rollouts? Is this one tool or four???)
Flux (there are versions???)
Helm (⛵ boat emoji because lmao)
Kustomize (customize but with K because...Kubernetes???)
Three months and countless conversations, building and breaking later, I finally understand what all these tools actually DO. So I'm writing this blog to save you from the same confusion I went through. And yes Falco is straight up legendary Pokémon :D
What Even Is GitOps?
Before we dive into all these tools, let's get one thing straight: GitOps is just a fancy way of saying "Git is the boss of your infrastructure."
Instead of SSHing into servers or running kubectl commands from your laptop, everything goes through Git:
- Want to deploy? Push to Git.
- Want to rollback? Revert the Git commit.
- Want to know what's running in production? Look at Git.
The magic happens through pull-based deployment: Instead of your CI/CD pushing changes TO your cluster, your cluster pulls changes FROM Git. (This also means your CI/CD never needs production credentials hehe)
Now let me introduce slowly all the fancy keywords being thrown around here.
The Configuration Tools: How to Structure Your Kubernetes YAML
Before you can do GitOps, you need to organize your Kubernetes configurations.
Plain YAML: The Starting Point
This is just raw Kubernetes manifests. Cute YAML files.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: nginx:1.14.2
What they do: Nothing (Just like my DNS server that I wrote in rust T-T)
The problem they creates: You end up copying these files for each environment (dev, staging, prod) and manually editing values. Lots of circus.
How it ties to GitOps: These YAML files live in Git, and GitOps tools apply them to your cluster.
Helm: The Package Manager
Helm treats Kubernetes applications like packages. My javascript bros found their npm for Kubernetes.
# Template
replicas: {{ .Values.replicas }}
# Values file
replicas: 3
What it does:
- Templates your YAML using Go templates
- Packages applications into "charts"
- Manages releases (install, upgrade, rollback)
- Handles dependencies between apps
How it ties to GitOps: Your Helm charts and values files live in Git. GitOps tools like ArgoCD/Flux can render and deploy Helm charts directly.
Kustomize: The Patcher
Kustomize says "don't template, just patch." Start with plain YAML and overlay changes.
# Base YAML stays plain
# Then you add patches for each environment
patches:
- target:
kind: Deployment
name: my-app
patch: |-
- op: replace
path: /spec/replicas
value: 5
What it does:
- Takes base YAML files and applies patches/overlays
- No templating language, All is YAML
- Built into kubectl (
kubectl apply -k
) (this is the selling point fr)
How it ties to GitOps: Your base configs and overlays live in Git. GitOps tools natively understand Kustomize directories.
FAST FAST REVISION
- Plain YAML: No tooling, lots of duplication
- Helm: Powerful templating + package management, but another language to learn
- Kustomize: Stay close to vanilla YAML, just patch what's different
The GitOps Engines: The Deployment Orchestrators
These tools watch your Git repos and make sure your cluster matches what's in Git.
ArgoCD: The GitOps Powerhouse
ArgoCD is probably what most people think of when they hear "GitOps."
What it does:
- Watches your Git repositories
- Compares desired state (Git) with actual state (cluster)
- Syncs changes automatically or manually
- Provides a web UI to visualize everything
What makes it different:
- The UI: Beautiful web interface showing your entire application topology
- Multi-cluster support: Manage multiple clusters from one ArgoCD instance
- Sync waves and hooks: Complex deployment orchestration
- Built-in RBAC: Enterprise-ready from day one
How it works with config tools:
- Automatically detects if you're using Helm, Kustomize, or plain YAML
- Can pass values to Helm or parameters to Kustomize
- Supports custom plugins for other tools
Flux: The Cloud Native GitOps
Flux takes a more modular, Kubernetes-native approach.
What it does:
- Same core idea: syncs Git with your cluster
- But built as a set of small, focused controllers
- No UI - everything is a Kubernetes resource
What makes it different:
-
Architecture: Not a monolithic app but a collection of controllers:
- Source Controller (fetches from Git)
- Kustomize Controller (builds and applies)
- Helm Controller (manages Helm releases)
- Notification Controller (alerts and webhooks)
- Multi-tenancy first: Designed for platform teams serving multiple dev teams
- Lighter footprint: Uses fewer resources than ArgoCD
- GitOps for GitOps: Flux can manage itself
How it works with config tools:
- Native Kustomize support through Kustomize Controller
- Native Helm support through Helm Controller
- Can even fetch Helm charts from OCI registries
ArgoCD vs Flux:
Aspect | ArgoCD | Flux |
---|---|---|
UI | Beautiful web UI | No UI (but you can add one) |
Architecture | Monolithic application | Set of controllers |
Resource usage | Heavier | Lighter |
Learning curve | Easier (thanks to UI) | Steeper (all CLI/YAML) |
Multi-tenancy | Supported | First-class citizen |
Self-management | Can manage itself | Designed to manage itself |
Community | Larger, more tutorials | Smaller but growing |
Choose ArgoCD if: You want a UI, easier onboarding, enterprise features out of the box
Choose Flux if: You prefer everything as code, need strong multi-tenancy, building a platform
The Argo Ecosystem: Where the confusion happens
As it turns out, ArgoCD is actually part of a larger family. And as far as I have seen on the internet, People pick some members of this family to work with flux.
Argo Workflows: The Pipeline Runner
What it does: Runs complex, multi-step workflows on Kubernetes
Think of it as Jenkins or GitHub Actions, but Kubernetes-native. Each step in your workflow runs as a container.
What makes it different:
- Workflows are Kubernetes resources (YAML)
- DAG-based (define dependencies between steps)
- Massive parallelization capabilities
- Native Kubernetes integration (uses pods, volumes, configs)
Common use cases:
- CI/CD pipelines
- Data processing pipelines
- Machine learning workflows
- Batch jobs
How it ties to GitOps: Often triggered by Argo Events to build and push images, which then triggers ArgoCD to deploy them.
Argo Events: The Event Handler
What it does: Listens for events and triggers actions in Kubernetes
It's like IFTTT or Zapier for Kubernetes: "When this happens, do that."
What makes it different:
- Huge variety of event sources:
- Webhooks (GitHub, GitLab, Slack)
- Message queues (Kafka, NATS, SQS)
- Time-based (cron, calendar)
- Cloud events (S3 uploads, pub/sub)
- Can trigger any Kubernetes resource (including Argo Workflows)
Common use cases:
- Trigger builds on Git push
- Process files when uploaded to S3
- Run nightly batch jobs
- Incident response automation
How it ties to GitOps: Provides the event-driven glue between your source code changes and your GitOps deployments.
Argo Rollouts: The Progressive Delivery Tool
What it does: Advanced deployment strategies (canary, blue-green, experiments)
While ArgoCD gets your app deployed, Rollouts controls HOW it gets deployed.
What makes it different:
- Gradual rollouts with automatic rollback
- Integration with metrics providers (Prometheus, Datadog)
- Traffic management with service meshes
- A/B testing and experimentation
How it ties to GitOps: Works alongside ArgoCD/Flux to provide safe, gradual deployments.
How It All Fits Together
Here's how these tools work together in a real GitOps pipeline:
The Complete Flow
1. Developer pushes code to GitHub
2. Argo Events detects the push
3. Argo Events triggers Argo Workflows
4. Argo Workflows:
- Builds the application
- Runs tests
- Builds and pushes Docker image
- Updates image tag in the config repo
5. ArgoCD/Flux detects the config change
6. ArgoCD/Flux applies the changes to Kubernetes
7. Optionally: Argo Rollouts performs canary deployment
Repository Structure in GitOps
You typically have two repos:
Application Repository : Owned by Developers
my-app/
├── src/
├── Dockerfile
└── .github/workflows/ # or Argo Workflows
Configuration Repository : Owned by the cool kids (Devops Team)
k8s-configs/
├── apps/
│ └── my-app/
│ ├── base/ # Kustomize base
│ │ └── deployment.yaml
│ ├── overlays/ # Kustomize overlays
│ │ ├── dev/
│ │ └── prod/
│ └── charts/ # Or Helm charts
└── argocd/ # ArgoCD applications
└── apps/
Tool Combinations in the Wild
Common Pattern 1: The Argo Stack
- ArgoCD for GitOps
- Argo Workflows for CI/CD
- Argo Events for automation
- Kustomize for configuration
Common Pattern 2: The Flux Stack
- Flux for GitOps
- GitHub Actions/GitLab CI for CI/CD
- Helm for third-party apps
- Kustomize for internal apps
Common Pattern 3: The Hybrid
- Flux for platform/infrastructure (used by platform team)
- ArgoCD for applications (used by dev teams - they get a UI!)
- Helm for third-party apps
- Kustomize for customization
So Which Pokemon do I choose?
You don't need all these tools. Start with ArgoCD/Flux + Kustomize. That's enough for 80% of use cases.
The tools are the easy part. The hard part is changing your team's workflows and getting everyone to stop running kubectl manually.
Secret management is still painful. You'll need something like Sealed Secrets, SOPS, or External Secrets Operator.
Image tag updates are annoying. Every new build means a commit to your config repo. (Both Flux and ArgoCD have solutions for this.)
Don't try to build the perfect GitOps platform on day one. You will shoot yourself in the foot.
But if you are like me and still want to break things just for the sake of it :
The TL;DR of the mess
- GitOps: Git is your source of truth, clusters pull from Git
- Helm vs Kustomize: Helm for packages and templating, Kustomize for patching
- ArgoCD vs Flux: ArgoCD for nice UI and easy start, Flux for platform building
- Argo Family: Workflows for pipelines, Events for automation, Rollouts for progressive delivery
Remember: These tools exist to solve problems. If you don't have the problem, you don't need the tool. Start with your pain points and add tools as needed. As engineers, it is our no. 1 goal to solve actual problems instead of creating 20 new problems with an over-engineered tech-stack.
Top comments (11)
Had good time reading this ! Well explained :)
Thanks for reading!
Amazing!
Thanks for reading
Well explained!
Thanks for reading!
intresting
Thanks for reading!
This is really cool stuff. You explained it really well, surprisingly very easy to grasp and interesting too
Thanks for reading!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.