Helm repo add argo. Enter. Pods blooming in argocd namespace like weeds after rain — server, controller, Redis, a repo server nobody asked about.
Installing Argo CD on Kubernetes with Helm? It’s the gateway drug to GitOps, that buzzword du jour where Git becomes your single source of truth. Or so the pitch goes. I’ve chased these trends since Jenkins was king; now it’s Argo CD’s turn, promising clusters that self-heal from manifest drift. But let’s cut the crap — who pockets the cash? Open source heroics from Intuit’s crew, sure, but enterprise forks and consulting gigs follow.
Argo CD is a GitOps continuous delivery controller for Kubernetes.
That’s straight from the docs. Simple: Git holds your desired state — manifests, Helm charts, Kustomize whatever. Argo polls it, sniffs out differences from live cluster, syncs if you say so. No CI builds here; that’s Jenkins or GitHub Actions’ job. This thing’s pure deployment enforcer, always whispering, “Live match Git? No? Fix it.”
But here’s my twist, one you won’t find in tutorials: This echoes the old Puppet days, circa 2010, when config management went declarative. Puppet Masters ruled; now Git’s the master. Prediction? In five years, every SRE job req lists Argo CD proficiency — or Flux, its quieter rival. Yet, drift detection’s great until your Git repo’s a warzone of merge conflicts.
Why Helm? (And Why Not Just kubectl apply?)
Raw manifests? Fine for toys. Helm’s the pro move — declarative installs, values.yaml tweaks without forking upstream. Keeps your Argo CD setup in Git, ironically.
Prerequisites: Kubernetes humming, kubectl pointed right, Helm 3+ ready. Test with kubectl get nodes and helm version. Green? Go.
Step one: helm repo add argo https://argoproj.github.io/argo-helm. Update repos. Boom, official charts at your fingertips.
kubectl create namespace argocd. Isolation’s king; don’t pollute default.
Now, the money shot: helm install argocd argo/argo-cd --namespace argocd. Watch kubectl get pods -n argocd. They’ll roll out: argocd-server, argocd-repo-server, argocd-application-controller, argocd-redis, argocd-dex-server if enabled.
Tweak it. Grab a values.yaml:
server: service: type: ClusterIP configs: params: server.insecure: true dex: enabled: true
helm install argocd argo/argo-cd -f argocd-values.yaml --namespace argocd. Reproducible. Upgrade later with helm upgrade.
What the Hell Are These Pods Doing?
Post-install chaos: Five core beasts, plus optionals. Let’s dissect, no fluff.
Argo CD Server: Your UI dashboard and API gateway. Port-forwards to localhost:8080-ish. Logs in with admin password from secret. This is where juniors gawk at sync waves.
Application Controller: The brains. Watches apps (your deployments, defined in Git), compares desired vs. live, applies diffs. Multi-threaded syncs — scales with cluster size.
Repo Server: Sneaky one. Clones Git repos on-demand, renders Helm/Kustomize to Kubernetes YAML. Can’t trust cluster nodes for that; security. Eats CPU on big charts.
Redis: Cache and queue. Stores app states, sync tasks. Tune it or watch latencies spike.
Optionals? Dex for OAuth (Google, GitHub login). Notifications controller for Slack pings. ApplicationSet for templated apps — GitOps on steroids.
Verify: kubectl get svc -n argocd. Port-forward server: kubectl port-forward svc/argocd-server -n argocd 8080:443. Grab initial password: kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath={.data.password} | base64 -d.
Is Argo CD Actually Better Than Flux or Plain kubectl?
Flux? Lighter, event-driven, no UI bloat. Argo wins on polish — that Web UI sells it to managers. But cynical me asks: Who’s monetizing? Codefresh, Harness wrap it in SaaS. Open Core? Nah, fully OSS, but support contracts loom.
Custom first: Insecure server flag for dev (don’t in prod). Scale controller replicas. Dex for SSO. Notifications? Enable, hook Slack — drift alerts beat firefighting.
Post-install: Create your first app pointing to Git repo. Watch it sync. Drift? Button says “Sync.” Health checks roll in.
Pitfalls I’ve seen: Repo server OOMs on massive monorepos. Redis HA needs values tweaks. RBAC fights if cluster’s locked down.
Why Does Argo CD Matter — Or Not — for Your Ops Grind?
Platform teams love it: Self-service deploys, audit trails in Git. But if your team’s small, overkill. Start simple.
Bold call: GitOps like this kills manual kubectl apply forever. Yet, when AWS EKS drifts from Git? Blame the human merging PRs.
Scale tip: Use ApplicationSets for multi-cluster. I’ve deployed it across 50 nodes; holds up.
🧬 Related Insights
- Read more: Mesa Developers Slam the Door on Rogue AI Code: Humans Only, With Receipts
- Read more: EIE: How One Engine Crams Multiple LLMs onto Your GPU, Leaving Ollama in the Dust
Frequently Asked Questions
What does Argo CD actually do in Kubernetes?
Monitors Git for desired state, syncs cluster to match — drift detection and auto-apply.
How do I access Argo CD UI after Helm install?
Port-forward server service to :8080, grab admin secret password, login at localhost.
Does Argo CD replace Jenkins or GitLab CI?
No — it’s CD only. Pair with CI for builds, use Argo for deployments.
Can I install Argo CD without Helm?
Yes, kubectl apply manifests, but Helm’s easier for configs and upgrades.
