What is Helm? Kubernetes deployments explained
Author: Domeny.ForSale editorial team Published
In brief: Helm is a package manager for Kubernetes: a tool that makes it easier to install, configure and update applications in a cluster. Instead of managing many separate files describing an application, you use a package called a chart and supply your own settings. Helm also helps track successive deployments, but it does not replace Kubernetes or guarantee that an update will be safe.
What problem does Helm solve?
Kubernetes is a system for running and managing applications in containers. A cluster, an environment made up of machines managed by Kubernetes, needs a description of what it should run. This description is usually written in manifests: YAML files defining resources, such as a Deployment that manages application instances or a Service that provides access to them.
A single application may need several or a dozen or more such resources. If you run it separately in test and production environments, some settings will be shared and others will differ: the number of instances, domain address, container image version or memory limits. Copying manifests manually makes consistency harder to maintain.
Helm lets you combine templates for these resources into a single package. It generates manifests from the templates and configuration, then passes them to Kubernetes. The idea is similar to an operating system’s package manager, although Helm manages cluster resources rather than programs installed on a laptop.
Chart, release and values: three key concepts
A chart is a Helm package containing templates for Kubernetes resources, default settings and package information. It can describe a single application or a set of related components. A chart can also have dependencies, meaning it uses other charts.
A release is a specific installation of a chart in a cluster, with its own name. You can install the same chart multiple times, for example as shop-test and shop-prod, with different settings. A release therefore does not simply mean an application version: it identifies a deployment managed by Helm.
Values are configuration values inserted into templates. A chart usually includes a default values.yaml file, and the user can supply an additional file with custom settings. The available parameter names depend on the particular chart; Helm does not prescribe a universal field for configuring every application.
Here is an example of a simple chart’s structure:
my-app/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml
The Chart.yaml file describes the package, values.yaml contains the default configuration, and the templates directory holds the templates. The chart version and application version are different things: changing how an application is deployed does not necessarily mean changing the program itself.
What does deployment with Helm look like?
Suppose a team maintains a shop application. It needs one instance in the test environment and three in production. The team can use one chart and two configuration files instead of creating two independent copies of the manifests.
If the chart provides a replicaCount parameter, the values-test.yaml file might contain:
replicaCount: 1
The following example assumes that you have Helm installed, access to a cluster and a local chart in the my-app directory. First, you can generate the manifests without installing the application:
helm template shop-test ./my-app -f values-test.yaml
This lets you inspect the output of the templates, but it does not yet confirm that the cluster will accept all the resources or that the application will work. To install or update the release, run:
helm upgrade --install shop-test ./my-app \
-f values-test.yaml --namespace test --create-namespace
A namespace is a logically separate space for resources within a cluster. The --install option allows installation if the release does not yet exist; otherwise, the command updates it. Before running the command, check your current Kubernetes context to avoid accidentally deploying the application to production.
Updates and the limits of rollback
Helm records the history of successive release revisions: changes to its deployment. The helm history shop-test -n test command displays this history, while helm rollback lets you return to an earlier revision.
A rollback is not a backup of the application or its data. Reverting resource configuration will not automatically undo database migrations, changes made in an external service or the effects of the program’s operation. Updates to applications that store data require a separate plan for backups and version compatibility.
Helm does not remove the need to understand Kubernetes either. Incorrect resource limits, missing permissions or an invalid container image can prevent an application from starting, whether the manifests were written manually or generated from a chart.
When should you choose Helm, and how do you assess an existing chart?
Helm is useful when you repeat deployments, maintain several environments or install an application made up of many resources. For a few simple manifests that rarely change, it may introduce an unnecessary templating layer. Kustomize can be an alternative: it adapts existing manifests rather than using Helm templates.
Before using an existing chart, check its origin, documentation, required Kubernetes versions, permissions and handling of persistent data. Review the generated manifests, especially resources that grant permissions and services that expose the application outside the cluster. Passwords entered in a values file do not become secure simply because you use Helm: do not store them in a regular code repository.
To get started, choose a test environment and one chart. Check the documentation for that specific chart version to confirm the available parameters, then test installation, updates and what happens to the data during a rollback.
See also: What is Brave?
Read also
