Lesson: What Helm Is and Why

What you'll learn

• The problem Helm solves on top of Kubernetes.
• What a chart, a release, and a repository are.
• How Helm relates to the raw kubectl apply you learned in Module 7.
• When Helm is the right tool — and when it's overkill.

By the end you'll be able to explain Helm to someone who knows Kubernetes but has never packaged an app.

---

The lesson

1. The problem: lots of YAML, repeated

In Module 7 you deployed an app by writing separate manifests — a Deployment, a Service, a ConfigMap, an Ingress, maybe a PVC — and running kubectl apply -f. That works for one app in one place. But real life is messier:

• You need the same app in dev, staging, and prod with different replica counts, image tags, and hostnames.
• You want to install someone else's app (a database, a monitoring stack) without hand-writing 15 manifests.
• You need to upgrade cleanly and roll back if it breaks.

Copy-pasting and hand-editing YAML for each case is error-prone. Helm is the package manager for Kubernetes that fixes this — think apt or npm, but for clusters.

2. The three words you must know

CHART       a package: a bundle of templated Kubernetes manifests + default values
RELEASE     one installation of a chart into a cluster (named, versioned, upgradeable)
REPOSITORY  a place charts are published and fetched from (like a package registry)

A chart is a template; a release is a running instance of that template with your values filled in. You can install the same chart many times as different releases (e.g. web-dev, web-prod).

   CHART (template + defaults)
        │  helm install web-prod ./chart -f prod-values.yaml
        ▼
   RELEASE "web-prod"  ──renders──▶  Deployment + Service + Ingress  ──▶  cluster
        │
        │  helm upgrade / helm rollback / helm uninstall
        ▼
   versioned history you can move forward and back

3. How it relates to kubectl apply

Helm doesn't replace Kubernetes — it generates the same Kubernetes objects you already know, then applies them for you. Under the hood a release still becomes Deployments, Services, etc. The difference:

• kubectl apply — you manage static YAML files yourself.
• helm install/upgrade — Helm renders YAML from templates + your values, tracks it as a named release, and remembers every revision so you can roll back.

So everything from Module 7 still applies; Helm sits one layer above it.

4. What Helm gives you

• Templating — one chart, many environments, via a values.yaml you override per install.
• Release lifecycle — install, upgrade, rollback, uninstall, all tracked.
• Reuse — install community charts (e.g. ingress controllers, databases, Grafana) in one command instead of authoring everything.
• Atomic-ish upgrades — with --atomic, a failed upgrade automatically rolls back.

In the lab, Helm is the v3/v4 line (no more the old server-side "Tiller" — modern Helm is a client-side binary that talks to the cluster API directly). The Jumpbox already has helm installed and pointed at the live cluster, so you can try everything here for real.

5. When NOT to reach for Helm

Helm is powerful but not free of cost — templated YAML can get hard to read. For a single tiny app you control, plain manifests (or kubectl apply -k / Kustomize) may be simpler. Reach for Helm when you have multiple environments, third-party apps to install, or a need for clean upgrades/rollbacks. As always: match the tool to the job (a theme from Module 9).

Few static manifests, one env      →  kubectl apply
Same app across envs / upgrades    →  Helm
Installing someone else's app      →  Helm (use their chart)

---

Dig deeper

• Helm — official docs: "Using Helm"
• Helm — "Quickstart Guide"
• Artifact Hub — find public charts
• Helm — Glossary (chart, release, repository…)

Search terms

• what is helm kubernetes package manager
• helm chart vs release vs repository
• helm vs kubectl apply difference
• helm 3 architecture no tiller
• when to use helm vs kustomize

Check yourself

1. In one sentence, what problem does Helm solve on top of Kubernetes?
2. Define chart, release, and repository — and how a chart relates to a release.
3. Does Helm replace Kubernetes objects like Deployments? Explain.
4. Name two things Helm gives you that raw kubectl apply does not.
5. Give one situation where you'd not bother with Helm.