Module 2 · Concepts — Helm, templating, and why you'll use charts anyway

What Helm actually is

Helm is a templating + package manager for Kubernetes. Three things, in order of importance:

1. Templating — lets you parameterise your YAML (image tag, replica count, resource limits) via a values.yaml file. This is the feature you'll use every day.
2. Packaging — bundles a set of related manifests (Deployment + Service + Ingress + …) into a single "chart" you can version and distribute.
3. Release management — tracks installed versions so you can helm upgrade and helm rollback. Less load-bearing than people think; you can get the same outcome with kubectl apply and a good CI pipeline.

People argue about whether Helm is the right abstraction (Kustomize is the main alternative). Don't worry about it — in a real job you'll encounter both, and Helm is the more common distribution format for third-party software.

The chart layout

A Helm chart is a directory with a specific structure:

podinfo/
  Chart.yaml              # chart metadata (name, version, appVersion)
  values.yaml             # default values, overridable at install time
  templates/
    deployment.yaml       # Go-template-ized K8s manifests
    service.yaml
    _helpers.tpl          # template helpers, shared snippets

The templates are standard Go text/template files that produce YAML. You write things like:

spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

At install time, helm install renders the templates against values.yaml (plus any overrides) and applies the resulting YAML to the cluster.

Values, overrides, and the one rule

values.yaml ships defaults. You override them three ways, in increasing priority:

1. A second values file at install time: helm install -f prod-values.yaml
2. Inline overrides: --set image.tag=6.7.0
3. Explicit parameters from pipelines, e.g. --set-string image.tag=$GITHUB_SHA

The one rule of Helm values: the structure of values.yaml is your contract with everyone who uses the chart. Breaking it (renaming a field) is a breaking change. Treat it like an API.

What you should already be able to see

If you deployed podinfo in module 1 with raw YAML, imagine maintaining three of those — one per environment (dev/staging/prod), each with a different image tag and replica count. You either copy-paste and drift, or template. Helm is the most common way to template.

That's the whole case for using it. The rest is mechanics.

Relevant links

• Chart template guide — the official walkthrough of templating syntax.
• helm create — scaffolds a chart with sensible defaults. You'll use it in the task.