Helm
Master Helm: Kubernetes package management, chart development, and application deployment.
What is Helm?
Helm packages Kubernetes resource templates, default values, dependencies, and metadata into a versioned chart. Installing or upgrading a chart creates a named release: Helm's record of one rendered configuration and its revision history in a Kubernetes namespace.
Helm matters when one application shape must be configured and promoted repeatedly. Its core invariant is: the chart and ordered values must render an inspectable set of Kubernetes manifests before those manifests are allowed to change a cluster. Helm is not a workload controller, a database migration transaction, or a guarantee that the rendered application behaves correctly.
Keep four boundaries separate
Package
Chart
Versioned templates, defaults, dependencies, schema, and metadata form the reusable distribution unit.
Input
Values
Defaults, parent values, files, and command-line settings merge in precedence order before rendering.
Output
Manifest
Go templates produce ordinary Kubernetes YAML. Inspect this output rather than reviewing templates alone.
History
Release
A release tracks chart, values, namespace, and revisions. It does not own external data changed by hooks.
Render one explainable release
Loading lesson-owned values layers.
Validate both input and rendered output
Use values.schema.json to reject missing, mistyped, or out-of-range input before it reaches templates. Keep the public values surface small; every option becomes a contract that chart maintainers must evolve.
Then render the exact release inputs and validate the resulting resources:
- run
helm lintfor chart structure and conventions; - run
helm templatewith the production values and release context; - apply schema, policy, deprecated-API, and security checks to the rendered YAML;
- use Kubernetes server-side dry-run where cluster API discovery matters;
- diff the proposed manifests from the current release before approval;
- keep chart and image artifacts immutable and record their digests.
Template success proves only that text rendered. It does not prove that an image exists, a Service selects the intended Pods, a rollout reaches Ready, or a data change is safe.
Promote one chart version through environments
1 Build
Package immutable inputs
Pin dependencies and application artifacts; publish a new chart version instead of mutating an existing package.
2 Verify
Render the target context
Merge reviewed values, inspect manifests, and run policy and API validation against the destination.
3 Apply
Upgrade with a recovery contract
Choose wait, timeout, cleanup, and rollback behavior explicitly. Treat hooks as separately owned programs.
4 Release
Observe application evidence
Gate promotion on workload health and product signals, not only Helm command success.
Trace release and external state separately
Loading upgrade scenarios.
Loading outcomes
Design hooks and rollback for partial failure
- Hook Jobs block their lifecycle point until completion and can fail the release.
- Hook resources are not automatically managed like ordinary release resources; define deletion policy or TTL deliberately.
--waitwaits for supported resource readiness but does not automatically restore a failed revision.--atomicenables waiting and attempts to roll back release-managed changes after failure; verify the restored application afterward.- A schema migration, message publication, or cloud API call performed by a hook may be irreversible from Helm's perspective. Prefer expand/contract data changes and idempotent jobs with their own recovery evidence.
- CustomResourceDefinitions have lifecycle constraints. Review CRD installation and schema evolution separately from normal namespaced resources.
Avoid complexity that templates cannot govern
- Split a chart when components have independent ownership or release cadence; do not create one switch for every possible topology.
- Prefer clear helper templates over deeply nested conditionals and dynamic name construction.
- Keep secrets out of values files and command histories; integrate a controlled secret delivery path.
- Test upgrades from every supported prior version, including failed hooks, readiness timeout, and rollback compatibility.
- Use a GitOps controller when continuous drift reconciliation and audited promotion are required. Helm can supply the package and renderer without becoming the controller.