Your First Helm Chart

Helm makes Kubernetes apps shippable. The basic chart is one command; the rest is values customization.

Step 1: Install Helm

Helm is a single binary; install once, point it at any cluster the kubeconfig knows about.

• macOS. brew install helm is the canonical path.
• Linux. curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash.
• Verify. helm version prints the client version; mismatch with chart API versions surfaces here.
• Cluster. Any working kubeconfig context will do; kind from the earlier tutorial is enough for the lab.

Step 2: Generate chart

• helm create my-app, creates skeleton.
• Inspect my-app/, templates + values.yaml.

Step 3: Customize values

The whole point of Helm is that values.yaml is the single knob; templates stay generic, environments diverge through values overlays.

• image. Set image.repository and image.tag to your container; leave pullPolicy: IfNotPresent for prod.
• replicas. Set replicaCount per environment; small for dev, scaled out in prod.
• resources. Add CPU and memory requests and limits; without them the scheduler cannot pack nodes safely.
• env-specific overlays. Keep values-staging.yaml and values-prod.yaml alongside the base, applied with -f.

Step 4: Install + upgrade

Install, upgrade, rollback are all the same lifecycle; Helm tracks revisions per release so a bad upgrade is reversible by number.

• Install. helm install my-release ./my-app creates revision 1 and reports the resources applied.
• Upgrade. helm upgrade my-release ./my-app diffs and applies; revision number increments.
• Rollback. helm rollback my-release 1 restores to the named revision; use helm history to see the list.
• Dry-run. helm upgrade --dry-run --debug renders the manifests without applying; this is the safety net before prod.

Antipatterns

• Hard-coding values in templates. Defeats Helm.
• Skipping helm lint. Errors at install time.
• Big chart, one team. Reuse via subchart instead.

What to do this week

Three moves. (1) Run the tutorial end-to-end on your own laptop / sandbox. (2) Apply the pattern to one production workload. (3) Document the variations you needed; share with the team.