Helm — Package Management for Kubernetes

Every chapter so far has piled up more raw YAML — StatefulSets, DaemonSets, Jobs, RBAC objects. This chapter covers the tool that manages all of that at real scale: Helm.

The Problem With Raw YAML at Scale

k8s1-12's capstone alone needed roughly eight separate YAML resources — a namespace, ConfigMap, Secret, three Deployments, three Services, an Ingress, a PVC. Manually managing, versioning, and deploying dozens of interrelated YAML files for a real application becomes genuinely unwieldy. Worse: what if the same application needs deploying to dev, staging, and prod with slightly different values — replica counts, resource limits, image tags? Raw YAML has no built-in templating — that means separate, near-duplicate files per environment, or external tooling.

What Helm Actually Is

A package manager for Kubernetes — conceptually similar to apt/npm/pip, but for Kubernetes applications. A chart is a Helm package: a collection of templated YAML manifests plus metadata. Installing a chart with specific configuration values produces a release — a named, tracked deployment of that chart into a cluster.

Chart Structure, Explained

Templating — Turning the Capstone Into a Chart

A fragment of k8s1-12's own Deployment YAML, templated:

A separate values-prod.yaml overriding just replicaCount: 10 and a different tag lets the exact same chart deploy meaningfully different dev and prod configurations — directly solving the "raw YAML per environment" problem from the intro.

Helm Commands — The Basic Workflow

• helm install <release-name> <chart> — deploy a new release.
• helm upgrade — apply changes to an existing release, often triggering k8s1-5's own rolling-update mechanism underneath.
• helm rollback — revert to a previous release revision, a direct parallel to k8s1-5's kubectl rollout undo, tracked at the whole-chart/release level instead of a single Deployment.
• helm uninstall — remove a release and everything it created.

Helm Repositories

Charts can be packaged and shared via repositories, conceptually similar to a package registry. Many popular applications — databases, monitoring stacks — already have official or community Helm charts available, meaning common infrastructure components often don't need to be written from scratch at all — a genuinely practical, time-saving point.

When Helm Is Worth the Extra Layer

Honest framing, matching this course's own recurring convention: for a single, simple application with one environment, raw YAML plus kubectl apply (Course 1's own approach) is perfectly fine and arguably simpler to understand. Helm earns its added complexity specifically once there are multiple environments needing different configuration, or a genuinely complex multi-resource application worth packaging and reusing — exactly the "8 YAML files, multiple environments" scenario the intro raised.

Helm & GitOps

Helm charts, being just files, version-control naturally (git1-git3), and are commonly the actual deployment artifact a GitOps pipeline applies — a topic Course 2's own k8s2-9 covers directly.

Hands-On Exercises