Helm: Kubernetes Package Manager

The Problem: YAML at Scale

Deploying a real application to Kubernetes requires 5–10 YAML files: a Deployment, a Service, a ConfigMap, an Ingress, a ServiceAccount, maybe a HorizontalPodAutoscaler. Multiplied across dev, staging, and production, this becomes dozens of files that differ only in a handful of values (image tag, replica count, domain name).

Managing these manually is error-prone and repetitive. Teams end up with copied-and-pasted YAML that drifts out of sync.

What is Helm?

Helm is the package manager for Kubernetes. Think of it like apt (Debian), brew (macOS), or npm — but instead of software packages, it manages Kubernetes application bundles.

Helm is maintained by the CNCF and is the most widely-used way to install third-party software (Prometheus, cert-manager, nginx-ingress) onto a cluster.

Helm Compilation & Deployment Flow

                                        +-------------------+
                                        |  Chart Templates  |
                                        +---------+---------+
                                                  |
                                                  v
+-------------------+                   +---------+---------+
|   Custom Values   | ----------------> |    Helm Client    |
| (--set / values)  |                   | (Go template engine|
+-------------------+                   |  & Sprig library) |
                                        +---------+---------+
                                                  | (compiles & renders templates)
                                                  v
                                        +-------------------+
                                        | Renders YAML/JSON |
                                        | (Kubernetes API   |
                                        |  Manifest Bundle) |
                                        +---------+---------+
                                                  |
                                                  | (3-way merge patch / HTTP POST)
                                                  v
                                      +-----------------------+
                                      | Kubernetes API Server |
                                      +-----------+-----------+
                                                  |
                                    +-------------+-------------+
                                    |                           |
                                    v                           v
                           +--------+--------+         +--------+--------+
                           |  Target Namespace |       | Release Secrets |
                           |  (e.g., Pods,   |       | (gzip+base64    |
                           |   SVCs, etc.)   |       |  JSON metadata) |
                           +-----------------+         +-----------------+

Core Concepts

Helm Template Engine & Deep-Dive Compilation

Charts use Go templates to inject values into YAML:

# templates/deployment.yaml
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
replicas: {{ .Values.replicaCount }}
name: {{ .Release.Name }}-app

Under the hood, Helm compile and render phases run entirely client-side:

1. Values Merging: Helm compiles values from the chart's defaults, any sub-charts (parent-child scopes), values files passed via -f, and command-line overrides (--set). This produces a single unified nested dictionary.
2. Template Expansion: Helm runs Go's standard text/template engine supplemented with custom helper functions from the Sprig library (e.g. toYaml, indent, nindent, default).
3. Manifest Compilation: Renders are converted to a combined YAML stream.
4. Three-Way Merge Patching: During upgrades, Helm client does not simply overwrite resources. It performs a three-way merge patch comparing:

- The *last release state* (stored in the cluster Release Secret)

- The *live state* in the cluster (to preserve out-of-band changes like dynamic node selections or replicas adjusted by HPAs)

- The *proposed target state*

1. State Storage: The output release state is serialized, gzipped, base64 encoded, and stored in a Kubernetes Secret of type helm.sh/release.v1 named sh.helm.release.v1..v in the installation namespace. Optimistic concurrency control (via resourceVersion on the Secret) guarantees concurrent updates are rejected by the API server to prevent race conditions.

Key Commands

helm repo add <name> <url>     # Add a chart repository
helm repo update               # Refresh cached chart index
helm search repo <keyword>     # Find charts in added repos
helm show values <chart>       # Inspect default values
helm install <release> <chart> # Install a chart as a named release
helm upgrade <release> <chart> # Upgrade an existing release
helm rollback <release> <rev>  # Roll back to a previous revision
helm uninstall <release>       # Remove a release from the cluster
helm list                      # Show all installed releases
helm history <release>         # Show revision history for a release

Helm v3 vs v2

Helm v3 (current, released 2019) removed Tiller — a server-side component that ran inside the cluster with cluster-admin privileges. Tiller was a significant security risk because any pod that could reach it could issue arbitrary API calls.

Helm v3 uses your kubeconfig directly (client-side only), so permissions are limited to what your own account can do.

When to Use Helm

• Third-party software (Prometheus, nginx-ingress, cert-manager, ArgoCD): always use Helm — charts encode operational knowledge.
• Your own apps: Helm works but adds template complexity. Many teams prefer Kustomize (next module) for first-party apps.