Argo, Flux, Kustomize, Helm and all the fancy stuff about GitOps

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:

• 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?

1. You don’t need all these tools. Start with ArgoCD/Flux + Kustomize. That’s enough for 80% of use cases.

2. The tools are the easy part. The hard part is changing your team’s workflows and getting everyone to stop running kubectl manually.

3. Secret management is still painful. You’ll need something like Sealed Secrets, SOPS, or External Secrets Operator.

4. 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.