Helm — Cheat Sheet

Tags: helm, kubernetes, devops, k8s, containers, cloud-native

Level: intermediate

TL;DR: Helm is the Kubernetes package manager that templates manifests into versioned, deployable charts and manages release lifecycles in-cluster.

Key concepts

A Chart is a packaged collection of Kubernetes manifest files evaluated with Go template syntax.

values.yaml defines default configuration parameters that can be overridden at runtime.

Helm 3 operates purely as a client-side binary without the server-side Tiller component.

A Release represents a specific deployed chart instance within a target namespace.

Helm stores release revision metadata as Kubernetes Secrets in the target namespace.

Chart dependencies are declared in Chart.yaml and downloaded into the charts/ directory.

Lifecycle hooks trigger resources like migration jobs before or after install, upgrade, or rollback.

Library charts provide shared templates and logic without deploying standalone Kubernetes workloads.

Helm natively supports packaging, pushing, and pulling charts to OCI-compliant container registries.

Typical questions and ready answers

Q: How does Helm 3 improve security compared to Helm 2?R: Helm 3 removed Tiller, eliminating a centralized cluster-admin component. It evaluates permissions directly through the user's kubeconfig context and enforces native Kubernetes RBAC.

Q: How do you structure configurations across development, staging, and production?R: I keep baseline defaults inside values.yaml and maintain separate files like values-staging.yaml and values-prod.yaml, supplying them via the -f flag during deployment pipelines.

Q: What is the difference between helm template and helm install --dry-run?R: helm template renders manifests entirely locally on the client. --dry-run connects to the Kubernetes API server to validate schemas and verify resource permissions.

Q: How does Helm handle failed releases and rollback strategies?R: Failed operations mark the revision as failed in the release Secret. I use helm rollback <release> <revision> to revert manifests back to the last known working state.

Pitfalls and common mistakes

Hardcoding static namespace fields inside templates overrides the CLI --namespace flag and hurts reusability.

Mixing imperative kubectl edit commands with declarative Helm updates causes release drift and overwritten configs.

Forgetting to quote string variables containing numeric IDs or booleans causes YAML type conversion bugs.

Omitting helm dependency update before building or deploying charts with external subchart references.

Using helm upgrade --force indiscriminately, which deletes and recreates pods instead of executing rolling updates.

Snippets and commands

# Lint chart syntax and render output locally
helm lint ./my-app
helm template my-release ./my-app -f values-prod.yaml

# Idempotent deploy or upgrade with custom values
helm upgrade --install my-app ./my-app \
  --namespace production \
  --create-namespace \
  -f values-prod.yaml \
  --set image.tag=v1.2.3

# Check deployment history and rollback
helm history my-app -n production
helm rollback my-app 2 -n production

# Package and publish to OCI registry
helm package ./my-app
helm push my-app-0.1.0.tgz oci://registry.example.com/charts

To review

[ ] Hook cleanup policies (helm.sh/hook-delete-policy) and hook weights.

[ ] Three-way merge patch mechanics during release upgrades.

[ ] Schema validation using values.schema.json.

[x] Basic templating functions (include, nindent, toYaml, required).

[x] Core release state management via in-cluster Secrets.

References

Helm Official Documentation (helm.sh/docs)

CNCF Artifact Hub and OCI Chart Specifications

Kubernetes Resource Management Best Practices

Jarvis Interviews
Jarvis