Helm
Charts, values and releases — the model behind helm upgrade, the template language in the forms you actually write, dependencies and distribution, hooks and tests, and the failures that only appear on the second deploy.
Stage 1 — Charts & Releases
4 lessonsThe three jobs Helm actually does, why Helm 3 removed the in-cluster server, and how a release revision lives in a Secret you can inspect with kubectl.
What every file in a chart is for, why version and appVersion move independently, and the two directories with special rules — charts/ and crds/.
Revisions as an append-only log, the four flags that make an upgrade survivable, and the honest limits of what a rollback can undo.
The exact order in which values sources override each other, why lists replace rather than merge, and how to design a values interface somebody else can use.
Stage 2 — Templating
4 lessonsGo templates as Helm uses them: the built-in objects, actions and whitespace control, and why indentation is where most rendering failures live.
The Sprig functions worth memorising, why include beats template in every case that matters, and how to build a helpers file other charts can reuse.
if, with and range in the forms you will actually write — plus the scope rebinding that causes the most confusing error message in Helm.
Four failure stages with four different tools — knowing whether you are looking at a values problem, a render problem, an API rejection or a runtime failure.
Stage 3 — Dependencies & Distribution
3 lessonsDeclaring subcharts, overriding their values from the parent, what global actually shares — and why one umbrella release means one failure domain.
Turning a directory into a versioned artifact, publishing to an OCI registry rather than an index.yaml, and giving consumers something they can actually verify.
Where each hook runs, why a rollback cannot undo one, and how ten lines of chart test turn a green deploy into a verified one.
Stage 4 — Production Operations
3 lessonsThe three-way merge that reverts your kubectl edits, the immutable fields no patch can change, and how to clear a release stuck in pending-upgrade.
Why a password in a values file leaks four ways, the three mechanisms that keep it out, and how to layer environments without letting them drift.
Three ways a chart reaches a cluster, what each gives up, and the chart-testing pipeline that catches a broken chart before anyone installs it.
Stage 5 — Capstone
1 lessonBuild a chart somebody else could operate — schema, subchart, hooks, tests, signed and published — then put it through nine drills including the ones that fail.
🗺️ Beginner → Expert Roadmap
5 stages with prerequisites and a concrete mastery check at each.
🎯 What You'll Learn
- • Describe Helm as three jobs — template engine, package format and release manager — and say which one you cannot replace with a script.
- • Find a release's state with kubectl alone, and read the manifest out of a revision Secret.
- • Name what every file in a chart is for, and why version and appVersion move independently.
- • Predict which values source wins, and explain why a list override replaces rather than merges.
- • Write templates whose whitespace and indentation are deliberate, not trial and error.
- • Use include rather than template, and know exactly why the difference matters.
- • Recover from the scope error that with and range cause, and reach the root with $.
- • Diagnose a chart failure at the right stage — values, render, API server or runtime.
- • Wire subcharts with conditions and global values, and accept the one-release coupling knowingly.
- • Publish a signed chart to an OCI registry and let a consumer verify it.
- • Place hooks correctly, keep their failure evidence, and design migrations that survive a rollback.
- • Explain the three-way merge that reverts a kubectl edit, and handle an immutable-field rejection.
- • Clear a release stuck in pending-upgrade without deleting the workload.
- • Keep secrets out of values files, and know what SOPS does and does not protect.
- • Choose between pipeline-driven and GitOps delivery on drift detection rather than preference.
- • Ship a chart somebody else can operate, proven by nine drills including the ones that fail.
🛡️ Best Practices in Production
The short version of this path. Every lesson also ends with the specific mistake it exists to prevent.
- ✓ Design
values.yamlas a public interface: document every key, and validate it withvalues.schema.json. - ✓ Derive every resource name from
.Release.Nameso the chart can be installed twice in one namespace. - ✓ Keep
selectorLabelsinvariant — a Deployment's selector is immutable. - ✓ Use
includerather thantemplate, andnindentrather thanindent. - ✓ Upgrade with
--atomic --timeout, and runhelm diff upgradebefore every production change. - ✓ Pin dependencies, commit
Chart.lock, and usehelm dependency buildin CI. - ✓ Publish signed charts to an OCI registry, and install by version or digest.
- ✓ Add
templates/tests/that exercise the real contract, and runhelm testin CI.
- ✗ Secrets in a values file — they reach Git, the release Secret and every
helm get values. - ✗ Expecting a list override to merge. Lists always replace, entirely.
- ✗ Generating passwords with
randAlphaNumwithout alookupguard — they rotate on every upgrade. - ✗ A migration hook that is not backward compatible. Rollback restores manifests, never your schema.
- ✗ Missing
before-hook-creationon a hook Job, which fails the second upgrade on an immutable field. - ✗ Templating
replicaswhile an HPA manages the same Deployment.