What is Helm?

Transcript:

The final module in this foundation section is going to cover Helm. In the previous section, we used Helm a couple of times to install various tools, such as the NGINX Ingress Controller. But in those cases, I kind of glossed over the details.

So I want to spend a little bit of time getting you familiar with Helm, how to use it, and what Helm charts look like so that we'll be able to use them effectively moving forward. There could be an entire course on Helm.

I'm going to cover it relatively quickly here and just touch on the most important features you need to know in order to use the tool.

Helm has become the de facto standard for distributing software that's going to run on Kubernetes. Many open source projects or third-party tools that you run in your cluster—the way you will install them is via a Helm chart.

It's kind of a combination of a package manager and a templating engine. If you're familiar with NPM and the Node.js ecosystem, or maybe your package manager for Linux, or Brew for macOS, it allows you to take a set of resources that you would deploy, bundle them up, and store them in a repository somewhere that other people can consume.

It also has templating built in, which allows you to use a single Helm chart and specify a configuration that will be relevant for a particular environment. So you can use the same chart and container images across different environments.

The primary use cases are:

• Application deployment (installing third-party tools into your cluster)
• Environment management (configuring applications across different environments using the same underlying resource)

There is a command-line tool called Helm that you will use to interact with Helm charts. We're going to look at the install, upgrade, and rollback commands.

The diagram here on the right shows how all the different pieces of a Helm chart come together. At the top level, you have a repository. This can either be a Helm repository or an OCI (Open Container Initiative) repository. You can store Helm charts in either of those.

Within that will be one or more Helm charts. The Helm chart itself is structured with some metadata as well as templates.

Those templates are where the Kubernetes resource definitions are going to live. This will be things like deployments, services, config maps, etc.

In the metadata, there's a values.yaml file. This is the interface with which you can configure and customize your templates. You're going to specify a set of values in that values file or pass them in at runtime, and those will get templated into your templates, hence the name, and rendered out as Kubernetes manifests.

When we install a chart, it's going to create an object called a release within our cluster. That release will have the rendered version of those templates and deploy them into our cluster.

Now, the templating, when you first look at it, seems pretty simple. Here we've got a pod, and we're substituting in whatever version is specified in the values.yaml file. So here you would use nginx, and the tag is going to be whatever version is specified.

Seems simple enough.

However, these templates can get gnarly pretty quickly.

This example, pulled from the MySQL Helm chart, shows how confusing it can get. With all those curly braces, it quickly becomes hard to interpret what's going on.

Some sections are only included conditionally, others use templated values. The customization interface that chart authors are defining can get complex because they need to account for all the different deployment scenarios that end users might want to have. This complexity is one of the biggest challenges in working with Helm.

There are a number of features within Helm, and I'm going to cover four that are most important in terms of templating.

• Metadata: Referencing metadata within your templates. You can reference the chart object, the release object, or the values object. For example, under App Version, you can reference Chart.AppVersion.
• Variables: Variables are important to keep your templates clean. On the left-hand side, I'm defining a variable called envShort, which will shorten my environment name. Then within my templates, I can reference that variable.
• Control flow: Helm supports conditionals—you can have values only render under certain conditions. For example, checking if the environment is production or whether a feature is enabled.
• Loops: You can loop over values using the range function. Here, I'm looping over values in the configData field within my values.yaml and adding keys to the config map.

Using these four concepts, you'll be able to handle most templating scenarios and make sense of most Helm charts.

Finally, we'll pull out a few examples and run through them in our clusters to get some hands-on experience with Helm charts—both consuming a third-party chart and authoring simple charts of our own.