Core Concepts of Helm

Take a quick tour of Helm’s core features.

We'll cover the following

What is Helm?

On the official Helm website—https://helm.sh—there is a sentence which describes what it is:“The package manager for Kubernetes.”

It goes on to state that, “Helm is the best way to find, share, and use software built for Kubernetes.”

Helm is often referred to as a Kubernetes package manager because it was made for bundling a couple of Kubernetes resource files into a single package that can be easily deployed.

Press + to interact
Helm logo
Helm logo

The idea is very close to the traditional understanding of a package manager. They’re used to simplify installation, upgrade, and remove applications and libraries from the system. The following are a few examples of other package managers: 

  • apt: This is a command-line tool used in Linux systems to install applications.

  • winget: This tool is similar to the previous one, but for Windows.

  • brew: This is the same tool as the two previous ones, but for macOS.

  • npm: This is the default library manager for JavaScript.

  • pip: This is a library manager for Python.

  • maven: This is a package and dependency manager for Java applications.

In Helm, a package is called a chart. An example of a chart would be an ECK Operator which bundles all the necessary resources needed to run Elasticsearch, Kibana, and APM Server (which are components of a popular Elastic Stack used for logs analytics) together with a single command, as shown below:

Press + to interact
helm install elastic-operator eck-operator

If we didn’t have Helm and wanted to install an entire Elastic Stack on the Kubernetes cluster, it would require a considerable amount of work to have it running. Even if we succeeded, there would be no guarantee that it was done the best possible way keeping in mind security and resilience requirements.

You might ask yourself why is Kubernetes not enough? Or why is it popular if it’s hard to install anything other than a “Hello, World!” Application? These questions are all fair, but we must remember that the main goal of Kubernetes is to orchestrate containers and provide a common abstraction over different kinds of infrastructure. With Kubernetes, we don’t need to worry if our applications are running on one, two, or more servers. It was designed like an operating system to be highly flexible in its configuration. Thanks to that, other tools can be built on top of it. Nowadays, there are plenty of them and Helm is one of them.

The main aim of Helm is to reduce the complexity of Kubernetes resource management by providing its abstraction, which is far closer to an application level, which is far easier to understand for regular users. It allows for the installation of applications with a single command with a default configuration; it also enables the adjustment of the most important ones.

All of that is possible because chart developers are preparing templates—blueprints for all Kubernetes resource files—making editable only those parts that are important from the application-level point of view, like how many instances of services need to be deployed or what environment variables are injected into running containers. A chart takes the burden of managing Kubernetes’s specific API and allows it to focus on more high-level tasks.

These templates are written in the Helm template language, which is based on the Go template language and Sprig template functions. Each template file looks very similar to the Kubernetes resource definition which it is. Here is a simple example from a previous lesson for Deployment definition:

Press + to interact
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: 'nginx:{{ .Values.container.image.version | default "1.21" | quote }}'
        ports:
        - containerPort: 80

The only new thing here are the double curly brackets {{ }} and everything between them. Throughout the course, we’ll explain what all of these parts mean, but for now, the only thing we need to know is that the brackets act as a placeholder and tell Helm that a particular part is not static  and requires some actions to be performed.

In the above example, a version of a Docker image for the NGINX container is set to be dynamic. Its default value is 1.21 and can be overwritten if necessary.

There are two ways to override a default value during installation. We can either pass it with a --set option and then a key/value pair or with a --values/-f flag and location of a values.yaml file, which consists of one or more values to be overwritten.

Here is an example of how it can be achieved using the --set flag to downgrade an image version:

helm install nginx-app ./nginx-chart --set container.image.version=1.20
Command to install a Helm chart

Firstly, for the values.yaml approach a relevant file needs to be created, as shown below:

Press + to interact
container:
  image: 
    version: '1.20'

Then the command can be run, as follows:

Press + to interact
helm install nginx-app ./nginx-chart --values ./values.yaml

As a result of one of the preceding approaches, a new Helm release will be created.

A release is a version of all Kubernetes resources that are running together in a cluster and are the outcome of a single helm install or helm upgrade command. Each time we run one of these commands (e.g., to upgrade the number of instances of an application), a new release is created, but a history of the old one is preserved. Using Helm we can easily roll back the entire stack.

Key benefits of Helm

Let’s have a look at the key features of Helm:

  • Parameterized Kubernetes YAMLs: It enables the creation of a blueprint for Kubernetes resource files which can be reused across many applications to reduce the maintenance burden.

  • Reduces the complexity of installing an application on Kubernetes: It can be achieved using a single command.

  • Easy configuration of applications: Helm chart developers provide a high-level abstraction that makes it easy to work with the chart without knowing about the  Kubernetes API.

  • Keeps track of the history of revisions: We can roll back to the state at any point in time.

There are also other pros of using Helm, which are as follows:

  • Enables testing of Kubernetes resources: Helm provides an easy-to-use testing and linting command that makes sure that all Kubernetes YAML files are written in high quality.

  • Provides out-of-the-box Kubernetes solutions for many popular open-source solutions: Many Helm charts are available for free on Artifact Hub, so there is no need to build many solutions from scratch.

We hope that this lesson has provided you with an idea of what Helm is and, more importantly, how users can benefit from it.