GitOps has crossed the chasm. What started as a blog post from Weaveworks in 2017 is now the default CD model for Kubernetes-native organizations. The Git repository is the source of truth. The cluster reconciles itself to match. Humans don’t kubectl apply in production.

In this world, the two dominant tools are Flux (v2) and ArgoCD. They solve the same fundamental problem with very different philosophies. Choosing between them — or knowing when to use both — is a meaningful architectural decision.

Photo by Yancy Min on Unsplash

What GitOps Actually Means

Before the tools: a quick grounding. GitOps has four principles (per OpenGitOps):

1. Declarative — the desired state of the system is described declaratively
2. Versioned and immutable — the desired state is stored in a system that enforces immutability and retains complete version history
3. Pulled automatically — software agents automatically pull the desired state declarations from the source
4. Continuously reconciled — software agents continuously observe actual system state and attempt to apply the desired state

Both Flux and ArgoCD implement all four. The differences are in UX, operational model, and architectural assumptions.

Flux v2 — The Kubernetes Native Approach

Flux v2 (the Flux project under CNCF) was a complete rewrite of the original Flux. It’s built around a toolkit of composable controllers:

• source-controller — watches Git/Helm/OCI repositories
• kustomize-controller — applies kustomize overlays
• helm-controller — manages Helm releases
• notification-controller — sends alerts, receives webhooks
• image-automation-controller — updates image tags in Git

Each controller is a standalone Kubernetes CRD + controller. You compose them.

Flux Architecture

Git Repository
      ↓ (poll/webhook)
source-controller (GitRepository CRD)
      ↓
kustomize-controller (Kustomization CRD)
      ↓
Kubernetes API

Flux runs entirely in your cluster. There’s no separate UI service or central control plane. Everything is Kubernetes-native: kubectl get gitrepositories, flux get all.

Flux Sample Configuration

# GitRepository - where Flux watches
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/my-app
  ref:
    branch: main
---
# Kustomization - what to apply
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 10m
  path: ./deploy/production
  prune: true
  sourceRef:
    kind: GitRepository
    name: my-app
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: my-app
      namespace: default

Flux Strengths

• Fully Kubernetes-native — no external services, CRD-everything
• Multi-tenancy — designed for platform teams managing many teams/clusters
• GitOps toolkit composability — use only what you need
• Flux image automation — automatically opens PRs when new image tags appear
• Excellent Helm support — HelmRelease CRD is first-class
• CNCF Graduated — proven production maturity
• OCI support — pull Helm charts and manifests from OCI registries

Flux Weaknesses

• No built-in UI — you need to add Weave GitOps or build your own
• CLI learning curve — the flux CLI is powerful but non-trivial
• Less visible for developers — harder for app teams to see deployment state without tooling investment

ArgoCD — The Visibility-First Approach

ArgoCD was built with a strong emphasis on visibility and developer self-service. The UI is not an afterthought — it’s a core product. Developers can see exactly what’s deployed, what’s drifted, and why a sync failed.

ArgoCD Architecture

Git Repository
      ↓ (poll/webhook)
ArgoCD Application Controller
      ↓
ArgoCD API Server → UI + CLI
      ↓
Kubernetes API

ArgoCD has more components: an application controller, an API server, a repository server, and the web UI. This is a larger operational surface but provides much richer out-of-the-box experience.

ArgoCD Sample Configuration

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/my-app
    targetRevision: main
    path: deploy/production
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas  # Managed by HPA, ignore

ArgoCD Strengths

• Best-in-class UI — visual diff, sync status, health, logs — all in one place
• App of Apps pattern — manage hundreds of apps with a single parent app
• ApplicationSets — templated multi-cluster, multi-tenant deployments
• Strong RBAC — fine-grained access control for teams
• Rollback in the UI — non-technical users can trigger rollbacks
• Sync waves and hooks — sophisticated ordering of multi-resource deployments
• Large ecosystem — Notifications, ApplicationSets, Image Updater plugins

ArgoCD Weaknesses

• Not purely pull-based — ArgoCD server is stateful and needs to be managed
• Multi-cluster complexity — managing many clusters requires careful argocd server placement
• Heavier footprint — more components to run and upgrade
• Git repo credentials — managing secrets for private repos is more involved

Side-by-Side Comparison

When to Choose Flux

• Platform engineering teams managing many clusters/tenants
• Security-first environments — Flux’s simpler architecture has smaller attack surface
• “Kubernetes all the way down” shops that want everything as CRDs
• Progressive delivery with Flagger integration
• Limited UI requirement — your team is comfortable in CLI + kubectl

When to Choose ArgoCD

• Developer-facing deployments where app teams need visibility and self-service
• Organizations with mixed technical levels — the UI makes state accessible to non-SREs
• Complex deployment workflows — sync waves, resource hooks, pre/post jobs
• ApplicationSet-heavy architectures — templated fleet deployments
• Existing ArgoCD investment — the ecosystem and expertise are deep

Using Both

It’s not unusual to run Flux and ArgoCD together:

• Flux for platform-layer resources (operators, CRDs, infra components)
• ArgoCD for application-layer deployments (where devs need visibility)

This is actually the model some mature platform teams have converged on. Flux’s composability makes it excellent for “infrastructure GitOps”; ArgoCD’s UX makes it excellent for “application GitOps.”

Progressive Delivery: The Next Layer

Both tools integrate with progressive delivery controllers:

Photo by imgix on Unsplash

Flagger (Flux ecosystem): automated canary deployments, blue/green, A/B testing via traffic shifting (works with Istio, Linkerd, NGINX, Traefik)

Argo Rollouts (ArgoCD ecosystem): canary + blue/green with analysis-based promotion, deep UI integration

Both are excellent. Choose based on which ecosystem you’re already in.

Practical Getting Started

Flux:

# Install Flux CLI
brew install fluxcd/tap/flux

# Bootstrap to GitHub
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=./clusters/production

ArgoCD:

# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Access the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

Both are approachable. Flux has more initial CLI surface to learn; ArgoCD gets you to a working UI faster.

The Bottom Line

If you’re starting a GitOps journey today, ArgoCD is the faster path to team adoption — the UI makes the value proposition immediately visible.

If you’re building a multi-tenant platform and want the most operationally clean, Kubernetes-native approach, Flux is the better long-term foundation.

Either way: get off imperative kubectl. The benefits of GitOps — audit trail, rollback, drift detection, environment parity — are real and worth the initial investment.

Resources

• Flux Documentation
• ArgoCD Documentation
• OpenGitOps Principles
• Flagger Progressive Delivery
• Argo Rollouts
• Kargo — Multi-stage promotion

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)