I recently completed a webinar on deploying Kubernetes applications with Helm. The webinar is the first of a two-part series on the Kubernetes ecosystem. It builds on the two introductory Kubernetes webinars that we hosted earlier this year: Hands on Kubernetes and Ecosystem & Production Operations.

In this post, I’ll be recapping this week’s webinar on Kubernetes and Helm.

What is Helm?

Helm is a package manager for Kubernetes applications. Helm packages all of the different Kubernetes resources (such as deployments, services, and ingress) into a chart, which may be hosted in a repository. Users can pull down charts and install them on any number of Kubernetes clusters. Helm’s approach scales from monoliths to complex micro service applications. Here are some of Helm’s main features:

  • Find and use popular software packaged as Kubernetes charts
  • Distribute your own applications (either private or FOSS)
  • A defined structure for managing Kubernetes resource manifests
  • Preconfigured installations
  • Parameterized installations by overriding defaults
  • Automatic revision history for all releases
  • Seamless upgrades and rollbacks between chart versions
  • Hooks for chart authors to manage the life cycle
  • Support for running tests after installing a chart

If you’ve used a package manager like apt, yum, brew, or portage before, you will be familiar with these features. Helm recently graduated from the Kubernetes incubator, which gives it more official standing in the Kubernetes community.

Helm itself uses a client-server model. The helm command (the client) talks to the tiller  (the server). The Helm client may interact with any number of different tiller services. In practice, there is a single tiller service running one Kubernetes cluster. This helps teams collaborate. It also means that Helm may run anywhere, such as on your CI servers or on your own computer. Tiller does the work to coordinate with Kubernetes and get the chart installed.

Installed charts are called “releases” because they may be installed multiple times. Consider a chart for something like Redis. You may need to install the Redis chart twice, each for different applications, as well as with different values. Let’s see how this works by going through the common workflow for chart authors and users.

Deploying Kubernetes Applications with Helm: Workflow

Let’s assume that most Helm users are chart authors rather than chart consumers. This is a bit different compared to how we tend to interact with our package managers. We may use brew or apt hundreds of times, but how many of us have actually created a brew or deb package? I’m guessing the answer is not much. Odds are, you’ll be a chart author and consumer since Helm targets engineers/teams looking to deploy their applications. To do this, you need to create a chart. To get started, you will need to initialize your cluster:

This command creates your ~/.helm  and deploys (via a Kubernetes Deployment ) tiller  to your Kubernetes cluster. Now, you’re ready to author and install charts. Helm automatically adds the stable charts repository. The charts repository contains “official” charts for various applications. It’s one of the most activated repositories on the Kubernetes github, and it’s an excellent reference for chart authors. You can use helm search to see what charts are available in the configure repositories. Naturally, you may create your own repository for your team’s charts.

Here is a snippet for charts that is available out of the box:

Let’s say that we wanted to install the Redis chart. We can do this via helm install . Here are some examples:

You can check all of the charts with helm ls .

This is a snapshot of my development environment. You can see the releases (in the NAME column) and various metadata. Specifically, you can see REVISION, STATUS, and CHART. Chart includes the name and version. With this information, we can:

  • Rollback to a specified revision of a given release. This is the helm rollback command. Here, you specify a --revision and release name.
  • Upgrade a release to the latest chart version or a specified version. This is the helm upgrade  command. Compared to other package managers, Helm allows releases to “upgrade” to completely different charts. You can upgrade the funny-starfish release to a completely different chart. This is a quirky feature, but you never know when it may be useful!
  • Delete a release. This is similar to uninstall. You may also purge a release. Normally, deleting reserves the release name so it may not be used in the future. Purging frees up the release name so that it may be reused.

The workflow becomes much more powerful when you author your own charts.

Deploying Kubernetes Applications with Helm: Authoring Charts

A chart contains Chart.yml that describes the chart (this includes the name, description, and version information that we saw in helm search earlier), and one or more Kubernetes manifest templates (deployment, pod, service, etc.). A chart also commonly contains an optional third item, values.yml. This file declares the default values used at the time of installation. These may be overridden at installation via the --set or -f flags. You may create new templates with  helm create .

You can see that Helm generated the directory structure. This boilerplate chart deploys nginx.  The template directory contains all of the manifest files. Let’s take a close look at one of the yaml templates.

There’s a lot going on in this template. First, all files are passed through Helm’s template engine. Helm users go to the template library. It is a logicless template language with a simple control flow (if and loops). Variables are denoted by {{ }}. There are also calls to {{ .Values }}. These refer to the final computed values (the defaults in Values.yml and overrides on the CLI).

There is also a call to a toYAML helper. This is particularly useful because you may keep data in values.yaml that matches the expected manifest format. This makes it easy to dump large portions of YAML into the final manifest. Line 5 calls the template helper with the fullname “partial.” This generates a unique name to avoid any duplicate names in Kubernetes resources (remember that one chart may be installed multiple times). We can edit these files until everything is correct. Next, it’s time to test.

This is a two-step process that begins with  helm lint and ends with helm install --dry-run . helm lint checks your semantics. helm install --dry-run is the real deal. The --dry-run mode sends the generated YML to the Kubernetes API for validation, but nothing is created. You will also need to combine --dry-run with --debug. --debug prints the generated YML. This is critical for debugging complex charts because YML is a whitespace sensitive language, which makes it easy to make a mistake or assume that something else has been generated.

The next step is to publish your chart to a repository. Helm chart repositories are simple web servers that serve an index.yaml file. The file declares the charts (and their version, description, etc) along with download URLs for each. You can use Google Cloud Platform buckets or S3 buckets to host your chart repository.

Publishing your chart involves three commands. The first command is  helm package to generate a tar archive, followed by  helm repo index to download an existing index.yml and merge it with the local chart. Then, it requires a command outside of Helm to upload the new index.yaml to the chart repository, and finally helm repo add to add your shiny new repo. This process is also covered in the official Chart Repository documentation.

Deploying Kubernetes Applications with Helm: Wrap Up

Helm is becoming increasingly important and common for Kubernetes end users, and it’s a powerful tool for your Kubernetes tool belt. You can watch the full webinar on Deploying Applications on Helm.

Here are also some links to help you use Helm:

Also, don’t hesitate to join #helm on the Kubernetes slack team.

Coming up next, I’ll be hosting the second webinar in this series on Kops.