What about Helm?

# So… what about Helm?

Running apt install apache2 or yum install nginx is something you are probably used to do when installing your favorite software on your Linux server, but what about your Kubernetes cluster? Wouldn’t it be cool to install your favorite software as easily as your package manager on Linux? Yes, that is what Helm does for you!

Helm is the package manager for Kubernetes. With Helm you can install, upgrade or delete packages on your cluster. It controls the whole lifecycle management of the packages on your Kubernetes cluster. It is flexible, because you can extend Helm easily by adding different repositories. This makes Helm a very flexible package manager!

# Why package management like Helm?

Package management makes it easy to distribute your applications. A package manager takes away the whole lifecycle of a package (install, updates, rollbacks, remove etc.). Helm helps you to install your Kubernetes packages so simple like a press on a button. Helm has a large library of packages which you can add as a repository to your Helm installation with over 15 thousand packages to install, see Artifact HUB. And of course you can add your own repositories.

# Helm components

# Helm Charts

A package in Helm is called a Chart. This is an archive of yaml files, which describe your Kubernetes resources like services, pods or deployments of your app.

# Helm CLI

The Helm CLI is a command-line interface to manage Helm Charts and Releases. With the Helm CLI you can easily manage your packages by installing, upgrading or removing packages on your Kubernetes Cluster. The Helm CLI uses your Kubectl configuration and credentials to interact with the cluster.

# Helm Releases

The Helm Releases are deployed instances of Helm charts. If you apply the same Helm chart with a new setting or configuration, you simply create a new release.

# Helm Repositories

A Helm Repository is a central place where you store your Helm charts. You can add different repositories to your Helm package manager to install Helm Charts from different sources.

# Values.yaml

This file contains variables to customize your Chart deployment. For example, to change the name of your application or the amount of replicas. You typically add or adjust the variables in this file before installation.

# Hooks

With hooks you can trigger actions during the release lifecycle. For example to initial a database or to create backup of a database before installing the new release of the package.

# How Helm works

First you have to install Helm to be able to use Helm CLI. After the installation of Helm you can use the CLI to do things with Helm.

To add a repo to helm:

1

helm repo add <name-of-repo> <repo url>

List your installed repos:

1

helm list repo

Install a helm chart:

1

helm install <your-release-name> <package-name>

Here is <your-release-name> your unique name to install the chart. For example, my-webshop or my-blog-post-about-dogs and <package-name> is the name of the package in the repository.

Important notice: You can easily overwrite the variables of your helm package by adding extra CLI flags to the helm command, e.g. helm install my-blog wordpress --set name=peter,replicasets=3. In case of many variables you put these into a values file, which you can use as follow: helm install my-blog wordpress -f custom-values.yaml

# Create your own chart

There are several ways to get started with Helm Templates. An easy way is to generate a Helm Chart, for example:

1

helm create my-blog

This command creates a local directory on the host you are working on. Congratulations… your very first custom Helm Chart! This Chart gives you a basic structure for templating with Helm. Let’s look inside the new directory (Helm Chart):

1
2


$ ls myblog/
charts  Chart.yaml  templates  values.yaml

The template directory contains your template files. The helm create command already gave you some examples. The Chart.yaml file contains metadata about your Chart, like a name, description, version, etc. The values.yaml file contains your variables which you can use in your template. For example, the replicaset parameter in your deployment file could be a variable which you like the user to change when they apply your Helm Chart.

Example of a template (in this case a service resource):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: v1
kind: Service
metadata:
  name: {{ include "myblog.fullname" . }}
  labels:
    {{- include "myblog.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "myblog.selectorLabels" . | nindent 4 }}

Templates in Helm can include the Go Template language and is therefore easy to extend and understand.

To avoid repeating the same things over and over in your template files, you can define blocks in the _helpers.tpl file. You can include these blocks in your template files, as shown in the example above. {{ include "myblog.fullname" . }} is an include from a defined block in the _helpers file. This is very powerful in templating your Helm Chart.

Variables from your values file are defined like: {{ .Values.service.type }}.

# Test your template

The command down here shows a simple way to test your template. It even loads your variables. This makes it very simple to verify your code. The extra flag --debug gives you some extra information, like line numbers and filenames, in case there is something wrong with your template. This makes it easier to troubleshoot.

1

helm template --debug myblog ./myblog

# Integrations

You can run Helm as a standalone package manager or integrate it in your cluster. For example, you can apply a Helm operator to your cluster. This helps you in automating deployments of helm charts.

Helm can also be applied in a GitOps environment. The most popular GitOps Agents are Ago CD and Flux CD, which both provide Helm support.

# Are there alternatives?

Yes, alternative solutions do exist, however Helm appears to be the most popular one. Other interesting products/alternatives are:

Every tool comes with its own pros and cons, there is no good or wrong. Always start with a market research and choose the right tool for your job. If you are unsure on what to choose for, Helm is always a good choice to start with.

# Finally

I hope this article gives you a glance of Helm and how it can help you. If you are interested in Helm, please visit the official website for more information. There is also a good starter course on Kodekloud. If you got stuck or if you would like some help in implementing Helm in your organization and cluster, please do not hesitate to contact me or Qstars IT for a consultation. We are always willing to help you with your journey into Helm.