Bill Gernert
Platform & Orchestration

Helm

Packaged, versioned releases for the cluster, 5 of them running today - 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 and whyHow I use it inArchitectureLessons learned and gotchasImpactFurther reading

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

Helm architecture: Values to reconciled release A chart combines shared values and release overrides, renders the Kubernetes objects, and becomes a release that Git reconciliation keeps aligned. ARCHITECTURE FLOW VALUES TO RECONCILED RELEASE Chart: Versioned templates and defaults CHART Versioned templates and defaults Shared values: Common platform settings SHARED VALUES Common platform settings Release overrides: Workload-specific settings RELEASE OVERRIDES Workload-specific settings Render: Produce the Kubernetes objects RENDER Produce the Kubernetes objects Cluster release: Apply the declared resources CLUSTER RELEASE Apply the declared resources Git reconciliation: Keep the release aligned GIT RECONCILIATION Keep the release aligned Cyan. Automated step or path. Green. Recorded or healthy outcome. Dashed box. Stored state or record. Rounded box. Actor or process. Arrow. Direction of work or data.
The release path combines a chart, shared values, and release overrides before render and reconciliation. Cluster addresses and hostnames are omitted.

Lessons learned & gotchas

Gotcha - upgrade does not prune, and lists do not merge Two Helm behaviors that surprise you at the worst time. First: 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 1-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

1 chart
many rendered releases
Versioned
upgrade and rollback
Render
then trust, not before

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.

Further reading

Helm docs