Helm
Packaged, versioned releases for the cluster - one parameterized chart instead of a pile of hand-tweaked manifests, with a healthy respect for how upgrade and values actually behave.
What it is & why I use it
Helm packages Kubernetes workloads as versioned charts: a templated set of manifests plus the values that parameterize them. In AutomationLab it is how the cluster's workloads are deployed and upgraded as coherent releases rather than as loose files applied one at a time.
I use it because a chart turns "a dozen manifests that have to agree with each other" into one unit with a version and a set of inputs. The same chart can render different environments by swapping values, which is exactly what keeps two similar deployments from drifting into two subtly different piles of YAML.
How I use it in the lab
- Charts as the unit of release. Workloads are deployed as charts, so an upgrade or rollback moves a whole release together, with a version attached.
- Parameterized, not copied. One chart is rendered with different values for different roles rather than forking the templates - a shared values file carries the common settings and per-release files override just what differs.
- GitOps-friendly. Chart and values live in git and are reconciled like any other declared state, so what is released is reviewable and reproducible.
- Templated for reuse. Where several deployments are near-identical, the template plus values keeps them genuinely the same thing configured differently, not copies that slowly diverge.
Architecture
In action
Lessons learned & gotchas
helm upgrade
reconciles what the chart declares, but a resource you removed from the chart is
not necessarily deleted - it can linger as an orphan that the release no longer manages
but the cluster still runs. "I took it out of the chart" is not the same as "it is gone."
Second: when you override values, Helm deep-merges maps but replaces lists
wholesale - supply a one-item array and you do not add to the default list, you
replace all of it. Both come from assuming Helm merges the way you would in your head; it
has its own rules, and you have to render and check rather than trust your intuition.
- Render before you ship. Templating the chart to raw manifests and reading them catches "that value did not land where I thought" before it hits the cluster. The rendered output is the truth, not the values file you hoped would produce it.
- Watch for orphans on removal. When a release stops managing a resource, confirm it actually went away - an orphaned workload keeps running, keeps costing, and keeps being a thing nobody remembers deploying.
- Parameterize deliberately. A shared values file is powerful and dangerous: change a common default and every release that inherits it moves at once. Know what is shared versus per-release before you edit the shared layer.
Impact
Helm keeps the cluster's workloads as coherent, versioned, parameterized releases instead of a drift-prone heap of manifests. The lasting lesson is to stop assuming it behaves the way merging works in your head: upgrade will not prune what you removed, and overrides replace lists rather than extend them - so render the chart and read the output, every time.
Code & further reading
Published charts and values are scrubbed of cluster addresses, hostnames, and any secret references before they go public.