Topic 41

Helm

PackagingTemplating

Helm is the package manager for Kubernetes. It bundles a set of manifests into a chart, parameterizes them with values, and installs a configured copy as a tracked release you can upgrade and roll back. It is how most third-party software is distributed for Kubernetes.

Helm's strength is templating and lifecycle management; its weakness is that templating YAML can spiral into unreadable logic. Knowing where the line is keeps Helm an asset rather than a liability.

Charts, Values, and Releases

A chart is a directory of templated manifests plus metadata and a values.yaml of defaults. Values override those defaults at install time, so one chart produces different deployments for dev and prod. A release is an installed, named instance of a chart; Helm records each release and its revision history, which is what makes upgrade and rollback possible.

Installing a chart with overrides

# install a release named 'web' from a chart, overriding values
helm install web ./web-chart \
  --set replicaCount=3 \
  --values prod-values.yaml

# later: upgrade, then roll back if needed
helm upgrade web ./web-chart --values prod-values.yaml
helm rollback web 1

Templating

Charts template manifests with Go templating: values are substituted, and helpers, conditionals, loops, and named partials let one chart cover many configurations. This is powerful — a single chart can deploy a whole application with optional components toggled by values. It is also where Helm earns criticism: heavy templating turns YAML into a program that is hard to read and reason about. The discipline is to template what genuinely varies and resist encoding complex logic in templates.

Dependencies and Repositories

Charts can declare dependencies on other charts (a chart for your app that pulls in a chart for its cache), and they are distributed through repositories — increasingly OCI registries, the same place container images live. Pinning chart and dependency versions matters as much as pinning image versions: an unpinned dependency means an install can pull different code over time.

Upgrade, Rollback, and Drift

Helm tracks each release's revision history, so helm rollback returns to a previous revision's manifests. The caveat is drift: if someone edits the live objects directly (or another controller changes them), Helm's view and the cluster diverge, and the next upgrade may not do what you expect. This is one reason Helm is often driven by GitOps (Topic 43) rather than run by hand — and why reviewing rendered output (helm template) before applying is good practice.

Helm vs Kustomize

Helm — templating + packaging + release lifecycle. Strong for distributing configurable software; risks template sprawl.

Kustomize — template-free overlays and patches, built into kubectl. Simpler to reason about; no packaging or release tracking (Topic 42).

Common Mistakes

Encoding complex logic in templates until the chart is unreadable.
Leaving chart or dependency versions unpinned, so installs drift over time.
Committing secret values into values.yaml in Git.
Running helm install/upgrade by hand against prod and accumulating drift from live edits.
Applying an upgrade without reviewing the rendered manifests first.

Best Practices

Template only what genuinely varies; keep charts readable and push logic out of YAML.
Pin chart and dependency versions just as you pin image versions.
Keep secrets out of values — use a secrets store or sealed/external secrets.
Render and review with helm template before applying; ideally drive Helm through GitOps.
Use values files per environment rather than long --set chains.

RelatedKustomize — the template-free alternative (Topic 42)GitOps — drives Helm declaratively, avoiding drift (Topic 43)OCI registries — now host charts alongside images

Knowledge Check

What is a Helm release?

An installed, named instance of a chart with revisions tracked for rollback
A semantic version tag stamped on a built container image
A namespace that Helm creates to hold the chart's objects
A single rendered manifest file emitted by the chart's templating engine

What is the main criticism of Helm's templating?

Heavy templating turns YAML into hard-to-read logic
It cannot override the chart's default values at install time
It cannot roll back to an earlier release revision
It can only render one manifest per chart at a time

Why is Helm often driven by GitOps rather than run by hand?

Hand-run installs plus live edits drift Helm's view from the cluster
Helm has no CLI and can only be invoked by a controller
A GitOps controller is the only thing that can render chart templates
Helm needs an in-cluster controller to render its templates

You got correct