Lesson 1 · Helm fundamentals

What Helm is & why

The package manager for Kubernetes — and the "copy-paste YAML 106 times" problem it kills.

Your win: explain what Helm does in one sentence, the chart / release / values triad, and why this repo reaches for it instead of hand-writing Kubernetes manifests.

The problem Helm solves

Course 2 taught the Kubernetes objects — Deployment, Service, ConfigMap, KEDA ScaledObject, PDB, ServiceAccount. A single backend service needs all of those, and this repo runs ~25 services across a matrix of environments × organisations (Course 1's env×org model). Hand-writing that YAML would mean thousands of near-identical manifests, drifting out of sync the moment anything changes. Helm is the fix: the package manager for Kubernetes.1 You write the objects once as templates, and stamp them out with per-service, per-cell values.

One sentence Helm templates, packages, installs, and upgrades sets of Kubernetes objects as versioned units. Instead of applying raw YAML, you install a chart — and get a managed, upgradeable, rollback-able release.

The three words you must own

TermWhat it is
Chartthe package — a directory of templates + default values + metadata (Chart.yaml). This is the reusable artifact.
Valuesthe config fed into a chart's templates (.Values) — what makes one install differ from another.
Releaseone installed instance of a chart in a cluster, with a name and a revision history. Install the same chart twice → two releases.
Chart (templates + values.yaml) │ + your Values (-f files, --set) ▼ helm template / render ──► concrete K8s manifests │ helm upgrade --install ──► a RELEASE in the cluster (revision 1, 2, 3 … → rollback)

Why it matters here specifically

Anchor — Helm is how this repo produces K8s deployments/helm/ holds ~106 charts. Every backend service is one chart (Lesson 2), and the objects you learned in Course 2 are all rendered from Helm templates — nobody runs kubectl apply on hand-written YAML. Remember Course 1's skaffold render? That's literally helm template under the hood, and skaffold run is helm upgrade --install. So you've been driving Helm since Course 1 without naming it. Helm is pinned to v3.14.4 (deployments/versions/helm).
Helm 3 vs 2 (a common interview trap) Helm 3 is client-only — there's no in-cluster "Tiller" server (Helm 2 had one, and it was a security headache). Release state lives in Kubernetes Secrets in the release's namespace. If someone asks "where does Helm store release history?", the answer is "in-cluster Secrets, since v3."
Read this next

Helm docs — Charts (intro) + Using Helm

What a chart is, and the install/upgrade/release lifecycle. The canonical starting point.

→ helm.sh — Charts
→ helm.sh — Using Helm (releases)

Check yourself (from memory)

Q1. Helm is best described as…

It templates, packages, installs and upgrades sets of K8s objects as versioned units — charts installed as releases.

Q2. A release is…

Install a chart → a named release with revision history. Same chart installed twice = two releases.

Q3. In this repo, skaffold render corresponds to…

Skaffold render = helm template (hydrate manifests); skaffold run = helm upgrade --install. You've used Helm since Course 1.
What is Helm, the chart/release/values triad, and how does this repo use it?
recall, then click to reveal
HELM = the Kubernetes PACKAGE MANAGER: it templates, packages, installs and upgrades sets of K8s objects as versioned units. TRIAD: a CHART is the package (templates + default values + Chart.yaml); VALUES are the config fed to templates (.Values); a RELEASE is one installed instance of a chart (named, with revision history → rollback). Helm 3 is client-only (no Tiller); release state lives in in-cluster Secrets. REPO: deployments/helm/ = ~106 charts (one per service); every Course-2 object is rendered from Helm. skaffold render = helm template; skaffold run = helm upgrade --install. Pinned v3.14.4.
Want to see the exact objects one service chart emits, or why Helm 3 dropped Tiller? Ask me — chart anatomy is Lesson 2.

1. Helm — Charts; Using Helm.