The World Of Helm

Illustrated guides to become better engineers

Helm is like a package manager for Kubernetes. It allows us to better define and manage Kubernetes resources by providing templating capabilities and installing resources from remote sources. It also caters to the upgrading and rollback of infrastructure.

I suggest reading the article, going over the Helm docs, and trying out projects. If Kubernetes is unfamiliar to you, please read this article.

This post is aimed at giving an overview of what Helm is, it’s features, how it operates, and why Helmfile is useful.

Overview

When we talk about Helm, we are talking about something which updates Kubernetes through something called charts.

Helm can create any Kubernetes resource in a specific order, with Namespace being first and APIService as last priority. It can also pull specified images.

Helm is referred to as the package manager for Kubernetes.

Components

A Helm client has several functions.

It interacts with the Helm library.

The library caters for releases.

Basics

A Helm chart uses configs. We’ll dive into charts later on!

release: Whenever you install a chart, a release is created. Helm combines a chart and a config to create a release.

repository: A repository contains a collection of charts from where you can install charts remotely.

Since charts are only text files, you can spin up your own repo. Any HTTP server which can serve yaml can gtz archives can be used.

Helm also has the concept of registries to get access to multiple repos with auth.

Chart

A chart defines K8s resources. Templates use Go templating. Helm provides virtually all functions of the sprig library.

A chart is a folder having several components.

Template files having the .yaml extension produces YAML output. .tpl files don’t generate any output.

Charts includes in the charts directory are called sub-charts.

The defined directive {{define …}} makes it such that the chart is available to charts and subcharts. That’s namespacing is important.

Custom Resource Definitions defined are available to templates then sent to K8s.

Helm never deletes or reinstall CRDs, they have to be manually taken care of.

A compressed chart archive is called a package.

Library Charts

You can define library charts under dependencies in your chart.yaml by typically providing a local file path. A library chart is really like a chart, with the exception that values.yaml is missing.

The idea behind is to be able to just {{include “libary-name.template“}} a template and it works. We define the template names in the template folder and add them. This uses the concept of named template.

Plugins

Helm provides a plugins interface. A plugin is a folder with plugin.yaml. Plugins can be used to check for the os for example and run the .sh executable for example.

The plugins directory is defined using the $HELM_PLUGINS environment variable.

Behaviour

Helm only orders the creation of resources. It then exits. You can check whether the resources have finished installation or not.

Charts can be installed using these methods.

Installing a chart will create a resource.

Installing the same chart twice will create the resource twice.

Releases can be rolled back if wanted.

Hook

Hooks provide a way to do custom actions midway. Like creating a backup before installing something.

Here’s the typical lifecycle for installation.

The test hook is applied using helm test <name>.

Helmfile

In the real world, you’d probably want to use helmfile.

Helmfile allows you to simply manage different charts. In the same repo you can release a set of features by applying a helmfile. Or, you can apply only certain features found within the file by using labels.

You can also have different values by using Go templates for dev, staging and prod by changing the values file path.

Conclusion

Now you can find some tutos about helm and helmfile and start deploying stuffs.