liminfoHelm Reference
Free reference guide: Helm Reference
About Helm Reference
The Helm Reference is a searchable quick-reference covering all essential Helm 3 commands and chart authoring patterns. It organizes content into six practical categories — Charts, Templates, Values, Releases, Repositories, and Hooks — so Kubernetes engineers can locate the exact syntax they need without digging through official documentation. Every entry includes a realistic, copy-ready code example.
Chart authors and platform teams use this reference to recall template directives such as {{ include }}, {{- range }}, and toYaml | nindent, as well as release management commands like helm upgrade --install, helm rollback, and helm history. The reference also covers values override precedence (--set vs -f), Chart.yaml dependency declarations, and lifecycle hooks with hook-weight and hook-delete-policy annotations.
Content is organized to mirror the typical Helm workflow: start with chart creation and structure, proceed through templating and values management, manage releases and repositories, and finally automate with pre/post install and upgrade hooks. Whether you are packaging a new microservice or debugging a failed upgrade in a CI/CD pipeline, this reference provides the commands and YAML snippets you need at a glance.
Key Features
- Full coverage of Helm 3 CLI commands: create, lint, package, install, upgrade, rollback, uninstall, list, status
- Go template syntax: {{ .Values.key }}, {{ include }}, {{- if }}, {{- range }}, toYaml | nindent
- Values override precedence: values.yaml, -f custom files, --set flags with dot-notation and escape sequences
- Lifecycle hooks: pre-install, post-install, pre-upgrade, post-upgrade, test with hook-weight and delete-policy
- Repository management: helm repo add, update, search, list with Bitnami and Prometheus community examples
- Chart.yaml structure including apiVersion v2, dependencies with pinned semver versions, and appVersion field
- Debugging workflows: helm template local rendering, --debug flag, helm test with Pod hook annotations
- Release management: revision history, rollback to specific revision, --keep-history, --reuse-values patterns
Frequently Asked Questions
What is Helm and why is it used with Kubernetes?
Helm is the package manager for Kubernetes. It lets you define, install, and upgrade complex Kubernetes applications as versioned, reusable charts. Rather than applying dozens of raw YAML manifests, you run a single helm install command and Helm renders the templates with your environment-specific values and applies them to the cluster.
What is the difference between helm install and helm upgrade --install?
helm install creates a new release and fails if a release with that name already exists. helm upgrade --install is idempotent: it creates the release if it does not exist, or upgrades it if it does. The --install flag is widely used in CI/CD pipelines because it works regardless of whether the release has been deployed before.
How do I override values without editing values.yaml?
Use --set key=value for individual overrides on the command line, or -f myvalues.yaml to load an entire override file. Multiple -f files are merged left to right so later files win. You can combine both: helm upgrade my-release ./chart -f prod-values.yaml --set image.tag=v2.1.
What are Helm hooks and when should I use them?
Helm hooks are Kubernetes resources (typically Jobs or Pods) annotated with helm.sh/hook to run at specific points in the release lifecycle: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, and test. Common uses include database migrations before an upgrade, Slack notifications after install, and integration tests with helm test.
How does the toYaml | nindent template pattern work?
toYaml serializes a values.yaml subtree back to YAML string, and nindent N prepends a newline then indents every line by N spaces. This is essential when embedding block-style YAML structures (like resources, affinity, or env arrays) inside an indented template context. Without nindent the indentation would be wrong and the manifest would fail validation.
How do I debug template rendering errors?
Run helm template <release-name> <chart> to render manifests locally without connecting to a cluster. Add --debug to see the rendered output and any template errors. You can also pass --set or -f flags to test different value combinations. helm lint <chart> checks for structural issues in Chart.yaml and template syntax before packaging.
What is helm rollback and when does it help?
helm rollback <release> <revision> reverts a release to a previously deployed revision. Helm stores the full rendered manifest of every revision as a Kubernetes Secret, so rollback does not require re-rendering templates. Run helm history <release> to list all revisions with their status, then roll back to any specific one. The --wait flag makes helm rollback block until the rolled-back resources are ready.
How do Chart dependencies work in Helm?
Dependencies are declared in Chart.yaml under the dependencies field with name, version (semver range), and repository URL. Run helm dependency update to download them into the charts/ subdirectory as .tgz files. During install Helm renders parent and dependency templates together, and parent values.yaml can include a named section to pass values into each dependency.