GitOps & Continuous Delivery
Argo CD, Flux, and progressive delivery on Kubernetes.
GitOps means the cluster's desired state lives in git, and a controller in the cluster pulls and reconciles. By 2026 it's the default for production k8s.
The two big controllers
- ★ Argo CD — UI-first; great visibility into sync state and diffs; ApplicationSets for many-app patterns. The default in 2026.
- ★ Flux (CNCF) — controller-first, GitOps Toolkit primitives, Helm + Kustomize support. Smaller surface, very stable.
Both are excellent. Choose Argo if your team likes the UI; Flux if your team prefers everything as YAML / Kustomization resources.
Progressive delivery (canary / blue-green)
- ★ Argo Rollouts — Argo's progressive delivery; canary, blue-green, header-routed splits. Pairs naturally with Argo CD.
- ★ Flagger — same niche, works with Flux or standalone; Prometheus-driven success metrics.
- Linkerd Smi-Spec / Service Profiles — for traffic-split semantics in Linkerd.
CI ↔ CD boundary
The modern split:
- CI (GitHub Actions / Buildkite / Dagger) builds the image, pushes to registry, opens a PR to bump image tag in the deploy repo.
- CD (Argo CD / Flux) sees the new tag in the deploy repo and syncs the cluster.
Image-update bots:
- Argo CD Image Updater — auto-bump image tags in git when new images are pushed.
- Flux Image Automation — same idea, Flux-flavored.
- Renovate — also works for image tag updates in deploy repos.
Multi-cluster / multi-tenant
- Argo CD ApplicationSets — generate apps from cluster lists, git directories, or pull requests.
- Flux multi-tenancy with namespaces and RBAC.
- Argo CD Multi-cluster — register external clusters as targets.
Spinnaker (older / heavier)
- Spinnaker — Netflix-derived; complex; declining outside of huge enterprise.
Older non-GitOps CD
- Jenkins / Jenkins X — still around; Jenkins X tries to be GitOps.
- GoCD — niche.
- Drone / Woodpecker — pipelines but not GitOps controllers per se.
Feature flags + GitOps
- See Feature Flags. GitOps controls what's deployed; flags control what's enabled — separate concerns.
Patterns to adopt
- ★ Two repos: app + deploy. Or one repo with two branches. Don't deploy from feature branches.
- ★ Render manifests deterministically. Helm + values, or Kustomize overlays — pick one and stick to it per app.
- Sync-wave annotations for ordered apply (CRDs before resources that use them, etc.).
- Don't
kubectl applyfrom a shell. That's "ClickOps" — it'll drift from git. - Auto-prune orphaned resources; otherwise stale objects pile up.
- Notifications — Argo and Flux both push to Slack / Discord / webhooks on sync events.
- App-of-Apps (Argo) or Kustomization root (Flux) — bootstrap one cluster from one git path.
Pick this if…
- Default new k8s GitOps: Argo CD.
- You want minimal surface area: Flux.
- Canary / blue-green: Argo Rollouts + Argo CD, or Flagger.
- Many clusters: Argo CD ApplicationSets.
- Image bump automation: Argo CD Image Updater or Renovate.