Introduction
Helm is an open‑source package manager designed to simplify the deployment and configuration of applications on Kubernetes clusters. It provides a templating mechanism that allows users to define application manifests as reusable packages called charts, which can be versioned, shared, and distributed. Helm abstracts the complexity of Kubernetes YAML manifests, enabling developers, operators, and DevOps teams to install, upgrade, rollback, and manage application lifecycles with a single command.
The tool was first released in 2015 by the Cloud Native Computing Foundation (CNCF) and has since become a cornerstone of the Kubernetes ecosystem. Helm’s influence is evident in the proliferation of community‑maintained charts for popular software such as databases, message queues, and web servers. By providing a higher‑level abstraction over raw Kubernetes manifests, Helm bridges the gap between declarative infrastructure and application packaging.
History and Background
Helm’s genesis can be traced to the need for a standard packaging system within the Kubernetes community. Early in Kubernetes’ history, users manually composed YAML files for each application deployment, which was error‑prone and difficult to maintain. A consensus emerged that a package manager similar to apt or yum was necessary, leading to the creation of Helm.
Version 2 of Helm introduced a client‑server architecture that included the Tiller server component, which performed chart installation inside the cluster. Tiller allowed the Helm client to delegate tasks such as templating and manifest rendering to the cluster, but it introduced security and operational overhead, as Tiller required cluster‑level permissions.
Helm 3, released in 2019, removed Tiller entirely, shifting all templating logic to the client side. This change simplified security by eliminating the need for a privileged in‑cluster component and reduced the attack surface. Helm 3 also overhauled chart versioning and introduced new APIs for chart dependencies, hooks, and values management.
Since its initial release, Helm has gained widespread adoption in both cloud‑native and enterprise Kubernetes environments. The Helm project is hosted on GitHub under the organization helm, and it is a graduated project within the CNCF.
Core Architecture
Client‑Server Model
Helm operates primarily as a client‑side application that communicates with the Kubernetes API server via standard REST calls. In Helm 2, this model included the Tiller server, which lived inside the cluster and performed templating and state tracking. In Helm 3, the client itself performs templating, rendering all manifests locally before sending them to the API server. This approach reduces cluster privileges required by Helm and aligns Helm’s security posture with Kubernetes’ principle of least privilege.
Chart Structure
Charts are the fundamental distribution unit in Helm. A chart is a directory containing a collection of Kubernetes manifests, configuration files, and templates. The directory follows a canonical layout:
Chart.yaml– metadata about the chart, including name, version, and maintainers.values.yaml– default configuration values that are substituted into templates.templates/– a directory containing Go template files that generate Kubernetes YAML.charts/– optional subcharts that are packaged and bundled with the main chart.templates/_helpers.tpl– reusable template snippets.
During installation, Helm processes the templates with the supplied values to produce a final set of Kubernetes resources. These resources are then applied to the cluster via the API server.
Repository Model
Helm repositories are HTTP(S)-accessible locations that host packaged charts. Each repository contains an index.yaml file, which indexes all charts and versions available. Clients interact with repositories through commands such as helm repo add and helm repo update. Popular repository hosts include Artifact Hub, the community chart repository at helm.sh/stable, and self‑hosted solutions like ChartMuseum.
Key Concepts
- Release – A Helm release is an instance of a chart deployed on a cluster. Releases are tracked and versioned, enabling rollback and upgrade operations.
- Values – Key‑value pairs supplied to a chart’s templates. Values can be overridden via the
--setflag or by providing a custom values file. - Dependencies – Charts can depend on other charts. Dependencies are declared in the chart’s
Chart.yamland automatically fetched when installing the parent chart. - Hooks – Lifecycle events that trigger pre‑ or post‑install, upgrade, or delete operations. Hooks can be used for tasks such as database migrations or resource cleanup.
- Templates – Helm leverages Go’s text/template engine, supplemented with the Sprig library, to provide powerful templating features.
Helm Commands and CLI
The Helm command line interface (CLI) is the primary interaction point for users. The CLI offers a comprehensive set of subcommands grouped by functionality:
helm install– Deploys a chart as a new release.helm upgrade– Applies changes to an existing release.helm rollback– Reverts a release to a previous revision.helm uninstall– Removes a release and its resources.helm list– Displays all releases in the cluster.helm repo add– Adds a chart repository to the client configuration.helm repo update– Refreshes local repository indices.helm show– Inspects chart content, templates, and values.helm package– Packages a chart directory into a.tgzarchive.helm template– Renders chart templates locally without installing.
Helm Charts
Charts are the core building blocks of Helm. They enable packaging of application code, configuration, and Kubernetes manifests into a single distributable unit. A chart typically follows semantic versioning, allowing consumers to specify precise chart releases.
Chart Dependencies
Chart dependencies allow modularization and reuse. In Helm 2, dependencies were declared in a requirements.yaml file; Helm 3 replaced this with a dependencies section inside Chart.yaml. When a chart is installed, Helm automatically downloads the required subcharts and resolves any transitive dependencies.
Hooks and Lifecycle Events
Hooks provide a mechanism for running custom code at specific points in a release’s lifecycle. Common hook types include:
pre-install– Runs before resources are installed.- post-install
- pre-upgrade
- post-upgrade
- pre-delete
- post-delete
Hooks are defined using annotations in manifest files, such as helm.sh/hook: pre-install. They are useful for tasks like database migrations, configuration file generation, or orchestrating external services.
Value Override Mechanisms
Helm offers multiple ways to customize chart behavior:
- Inline overrides via
--set key=value. - Override files specified with
-f custom-values.yaml. - Named value files in
values.yamlthat can be overridden by specifying the file name. - Using
--set-stringand--set-filefor string and file inputs, respectively.
Helm and Kubernetes Ecosystem
Helm integrates tightly with Kubernetes by leveraging the API server for resource creation and management. Its templating engine supports the full spectrum of Kubernetes objects, including Deployments, Services, ConfigMaps, Secrets, and Custom Resource Definitions (CRDs).
Because Helm operates declaratively, it complements Kubernetes operators and Custom Resource Definitions. Operators can expose a higher‑level abstraction that internally uses Helm to manage complex deployments. This pattern is exemplified by the Helm Operator, which allows operators to manage Helm releases as CRDs.
Helm also supports Helmfile, a declarative configuration language that orchestrates multiple releases and provides dependency resolution across charts. Helmfile is particularly useful for managing microservice architectures where each service is packaged as a Helm chart.
Helm Security and Governance
Security in Helm revolves around several key aspects:
- Role‑Based Access Control (RBAC) – In Helm 3, the client communicates directly with the API server, so RBAC policies must allow the Helm user to create, update, and delete resources. Helm can be configured to use a specific service account for cluster operations.
- Chart Signing and Verification – Helm supports chart signing using public‑key cryptography. Signatures are stored in the chart’s metadata and verified before installation, ensuring chart provenance.
- Secret Management – Helm values files can contain sensitive data, but they are transmitted in clear text over the API. Operators should use Sealed Secrets or Sealed Secrets to securely store secrets in Git repositories.
- Upgrade Safety – Helm provides built‑in rollback capabilities, enabling operators to revert a release if an upgrade fails. Additionally, Helm’s
--dry-runflag allows users to preview changes before applying them.
Helm in CI/CD Pipelines
Helm is widely integrated into continuous integration and continuous delivery (CI/CD) workflows. Common patterns include:
- Template Validation – Using
helm lintto check chart syntax andhelm templateto render templates before deployment. - Automated Release Creation – CI jobs build chart packages, push them to a repository, and tag releases with Git commit hashes.
- Infrastructure as Code (IaC) Delivery – Helm releases can be promoted across environments using tools like GitLab CI or Jenkins.
- GitOps Deployment – GitOps tools such as Flux and Argo CD watch chart repositories or Helm releases defined in Git, ensuring that cluster state matches repository definitions.
By embedding Helm within CI/CD pipelines, teams achieve repeatable, auditable, and versioned application deployments.
Helm Ecosystem and Community
The Helm ecosystem comprises a vibrant community that contributes charts, tools, and documentation. Key community resources include:
- Artifact Hub – A central catalog of Helm charts, operators, and other artifacts. Users can search for charts by name, keywords, or maintainers.
- ChartMuseum – An open‑source Helm chart repository server that can be self‑hosted or deployed as a container image.
- Helm Charts Repository – A curated collection of stable and incubating charts hosted at github.com/helm/charts.
- Helm SDK – A Go library that allows developers to embed Helm functionality into custom applications.
- Helmfile – A tool for managing collections of Helm releases declaratively.
- Helm Operator – An operator that exposes Helm releases as Kubernetes CRDs.
Workshops, training sessions, and conferences such as Kubernetes SIGs provide educational opportunities for new and experienced Helm users.
Alternatives to Helm
While Helm is the dominant package manager for Kubernetes, several alternatives exist:
- kustomize – A native Kubernetes tool for customizing YAML manifests. Unlike Helm, kustomize does not use a templating engine but relies on overlays.
- Argo CD – Beyond being a GitOps tool, Argo CD can deploy raw Kubernetes manifests and supports application templating.
- Flux – A GitOps operator that manages Helm releases and plain manifests directly from Git.
- Kustomize‑based Operators – Operators that use kustomize patches to manage resource deployments.
Choosing between these tools depends on the team’s workflow, governance requirements, and familiarity with declarative configurations.
Future Directions
Helm continues to evolve, with forthcoming enhancements focusing on performance, developer experience, and security:
- Enhanced hook execution models to support sidecar injection and asynchronous operations.
- Improved integration with OpenTelemetry for observability.
- Streamlined Chart Signing workflows that integrate with CI/CD signing services.
- Better value management tools that support dynamic configuration loading.
Conclusion
Helm simplifies Kubernetes application delivery by packaging complex configurations and manifests into reusable charts. Its robust CLI, comprehensive repository model, and tight integration with CI/CD pipelines make it indispensable for modern cloud‑native deployments. By adhering to Helm’s best practices - semantic versioning, chart signing, RBAC compliance, and secret management - organizations can achieve secure, repeatable, and observable Kubernetes operations.
No comments yet. Be the first to comment!