Argo CD

CNCF Graduated GitOps tool. Used at Intuit, IBM, Tesla, BMW, Adobe. Five microservices: server, application-controller, repo-server, redis, dex. CRDs: Application, AppProject, ApplicationSet. Multi-cluster, RBAC, SSO, PR previews.

Overview

Argo CD: the dominant Kubernetes GitOps tool

Argo CD is the dominant Kubernetes GitOps tool in 2026. It originated at Intuit, graduated in the CNCF in December 2022, and runs in production at Intuit, IBM, Adobe, Tesla, BMW, JPMorgan, Red Hat (the engine behind OpenShift GitOps) and thousands of other organizations.

Why Argo CD wins

Polished UI — The best web UI of any GitOps tool: Application list with health/sync state, per-resource tree, diff view, log viewer, sync history, usable without CLI fluency
Application CRD model — One Application = one deployable unit; App-of-Apps + ApplicationSet handle multi-app management
Strong multi-cluster story — One central installation manages many remote clusters via kubeconfig secrets; the ApplicationSet cluster generator creates one Application per cluster
Rich RBAC + SSO — AppProjects scope each tenant; SSO via Dex or direct OIDC; roles map to AppProject permissions
Argo Rollouts companion — Rollout CRD replaces Deployment for canary and blue/green with metric-based promotion; tightly integrated
Notifications — argocd-notifications-controller posts events to Slack, Teams, email, webhooks, customizable via templates

Where it has friction

Resource consumption — application-controller is CPU-hungry; 1000+ Applications require sharding across replicas
Multi-tenant security model — Bolted on via AppProjects; less clean than Flux's namespace-native approach
Helm + Kustomize integration — Functional but quirky; some advanced patterns need argocd-cm tweaks

When to pick it

A centralized GitOps control plane manages many clusters (mature hub-and-spoke)
Application teams need a polished UI for sync status, drift detection and troubleshooting
Strong RBAC + SSO requirements
You want Argo Rollouts for progressive delivery

Three load-bearing concepts

Application — The unit of deployment: references a source (git), a destination (cluster/namespace) and a syncPolicy
AppProject — The security boundary: restricts which sources, destinations and resource types an Application can use
ApplicationSet — Generates Applications dynamically: the controller creates one Application per generated item

Key concepts

Application CRD — the unit of deployment: One Application = one deployable unit. References git source and K8s destination. source supports plain YAML, Kustomize, Helm, Jsonnet, and plugins. destination.server is K8s API URL. For multi-cluster, register external clusters via argocd cluster add (creates Secret in argocd namespace with kubeconfig); destination.name then references cluster by name. ignoreDifferences essential for any deployment with HPA, VPA, or Operators that mutate fields.
AppProject — security boundary: AppProject restricts what an Application can do. Security primitive in Argo CD. What AppProject restricts: - sourceRepos: which git URLs allowed. - destinations: which clusters/namespaces. - clusterResourceWhitelist / namespaceResourceBlacklist: which resource types. - roles: who can do what (sync, override, delete) on Applications. - syncWindows: when syncs are allowed (change-freeze periods). Multi-tenant pattern: one AppProject per tenant team / environment / business unit.
ApplicationSet — generate Applications dynamically: Meta-CRD that generates Applications. Eliminates Application copy-paste. Generators: list — explicit list: cluster — iterate over registered Argo CD clusters: git directory — iterate over directories in a repo: git files — iterate over JSON/YAML config files: matrix — cross-product: pull-request — Application per open PR (PR previews): scm-provider — discover repos from GitHub org: Full example — one Application per (cluster × service): 3 prod clusters × 20 services = 60 Applications generated automatically. Add a new service directory → new Applications appear.
Multi-cluster setup (hub-and-spoke): Centralized Argo CD managing many remote clusters. Step 1 — install Argo CD on hub cluster. Step 2 — register remote clusters: For production: ServiceAccount tokens (long-lived) or AWS IAM Authenticator (rotates via STS). Avoid personal kubeconfig tokens that expire. Cluster Secret CRD format: Cluster labels enable selective targeting in ApplicationSet. Step 3 — Application targets remote cluster: Step 4 — ApplicationSet generates per-cluster Applications: Network requirements: - Hub needs egress to all spoke cluster API endpoints (VPC peering, Transit Gateway, PrivateLink). - Spokes don't need ingress from hub for periodic sync. Scaling: - application-controller sharded for >500 Applications via --replicas=N + --shard=N. - repo-server scales horizontally. - Redis with Sentinel for HA. For >5000 Applications, consider federated topology (multiple Argo CD installations).
RBAC and SSO: Two RBAC layers: project-level (AppProject roles) and global (CSV in argocd-rbac-cm). Global RBAC: SSO with Dex + GitHub: Direct OIDC (no Dex) — for Okta/Auth0/Azure AD: Common patterns: - platform-team: global admin. - application teams: scoped to their AppProject. Can sync, can't create/delete Applications. - security/audit: read-only across all AppProjects. - on-call: time-bound elevated access (granted manually for incident response).
Recipe: Argo CD on EKS with HA + multi-cluster: Production-grade installation: Bootstrap multi-cluster: Bootstrap apps via app-of-apps: Root Application points at apps/ directory containing more Application CRDs. They get created and managed by Argo CD itself (GitOps managing GitOps). Operational notes: - Backup via Velero (Argo CD state in K8s etcd + Redis); most state is recoverable from git anyway. - ServiceMonitor for kube-prometheus-stack scrapes argocd-* metrics. - Upgrade: Helm chart upgrade after staging validation; check release notes for CRD changes.

When to use it

Centralized GitOps for many K8s clusters with rich RBAC
Application teams need polished UI for sync status, drift detection
Argo Rollouts for progressive delivery is desired
Strong SSO + audit + notification requirements
Multi-cluster patterns: hub-and-spoke, PR previews, branch-per-environment

Interview questions

Walk through Argo CD's five-microservice architecture.
How do you do multi-cluster GitOps with Argo CD at scale?
Walk through ApplicationSet — when do you use which generator?
How do you handle Argo CD upgrades and version skew?
Quick-fire interview answers — Argo CD essentials.