Helm, From Zero
You have a Deployment, a Service, a ConfigMap, and an Ingress. Now you need them in dev, staging, and prod - same shape, different image tags, different replica counts, different hostnames. So you copy the YAML three times and pray you remember to change every value in every copy. You won't. Something drifts, and the bug only shows up in prod.
Helm is the way out. A chart is your manifests with the per-environment parts pulled out into a values.yaml file. One template, many environments. And every deploy becomes a versioned release you can roll back with a single command. This guide gets you from "what even is a chart" to shipping and rolling back with confidence - and knowing when Helm is the wrong tool.
How to read this
Go in order. Phase 1 builds the mental model: what a chart actually is and the problem it solves, so the commands later feel obvious instead of magic. Phase 2 is the everyday loop - install, upgrade, rollback, values, releases - the stuff you'll run every day. Phase 3 is where it bites: templating gotchas, the --dry-run habit that saves you, and the honest call on Helm vs Kustomize vs plain manifests.
If Kubernetes itself is still fuzzy, read Kubernetes Without the Hype first - Helm only makes sense once you know what a Deployment and a Service are.
The phases
- The Mental Model: A Chart Is Templated Manifests - what a chart is, why values exist, what a release is.
- The Everyday Loop: Install, Upgrade, Rollback - the commands you run daily and how releases get tracked.
- Where It Bites: Templating Gotchas and When Not to Use Helm - whitespace, dry-runs, and Helm vs Kustomize vs raw YAML.