Helm guide

What Helm does in production

Installing a production app on Kubernetes often means Deployments, Services, ConfigMaps, Secrets, Ingress, RBAC, and more. Helm packages those into a chart — a directory of templated YAML plus a default values.yaml. One command installs or upgrades the whole stack with consistent naming and labels.

Core concepts

• Chart — package of templates + values + metadata (Chart.yaml)
• Release — a named instance of a chart running in a cluster (e.g. nginx-ingress)
• Revision — numbered snapshot of each upgrade (used for rollback)
• Values — parameters that customize the chart (replicas, image tag, resources)
• Repository — HTTP or OCI registry hosting charts for helm search

Helm 3 (current model)

Helm 3 talks directly to the Kubernetes API — no cluster-side Tiller. Releases are stored as Secrets (default) or ConfigMaps in the release namespace. Commands use your kubeconfig context like kubectl.

How install and upgrade work

1. Render — Helm merges values.yaml, user overrides, and chart templates into manifests
2. Apply — resources are created or patched in the cluster (server-side apply)
3. Record — release metadata and revision are stored for history/rollback
4. Hooks — optional pre/post install Jobs or tests run at defined points

Always review rendered output before production: helm template or helm install --dry-run.

Chart structure

• Chart.yaml — chart name, version, dependencies
• values.yaml — default configuration
• templates/ — Kubernetes manifests with Go templating (.Values, .Release)
• templates/NOTES.txt — post-install hints shown to the user

Templates reference values with dot notation — e.g. .Values.replicaCount and .Values.image.tag — wrapped in Go template delimiters in actual chart files.

Customizing with values

Override defaults without editing the chart:

• -f my-values.yaml — file overrides (can pass multiple; later wins)
• --set key=val — inline overrides (--set replicaCount=3)
• --set-file — inject file contents into a value

Keep environment-specific values in separate files: values-staging.yaml, values-prod.yaml.

Repositories and OCI

Add classic HTTP repos: helm repo add bitnami https://charts.bitnami.com/bitnami, then helm search repo KEYWORD. Modern charts also publish to OCI registries (container registries): install with helm install RELEASE oci://registry.example.com/charts/mychart --version 1.2.3.

Dependencies and subcharts

Charts can depend on other charts (e.g. app chart depends on PostgreSQL subchart). Declared in Chart.yaml dependencies; run helm dependency update to vendor them under charts/. Parent values pass into subcharts under a namespaced key.

Hooks and tests

Hooks — annotate resources with helm.sh/hook for pre-install, post-upgrade, etc. Used for migrations or CRD setup. Failed hooks block the release until resolved.

Tests — helm test RELEASE runs hook-weighted test pods defined in the chart.

Relationship to kubectl

Helm manages Kubernetes objects; it does not replace cluster debugging. After helm install, use kubectl get pods, describe, and stern (krew) for logs — see the Kubernetes lab.

Learning resources

• Helm documentation — helm.sh/docs
• Charts guide — helm.sh — charts
• Values files — helm.sh — values
• Artifact Hub — artifacthub.io (discover public charts)