Using Helm to Manage Kubernetes Deployments

Requirements:

• A Kubernetes cluster
• Kubectl
• Beginner understanding of Kubernetes

If you have read my previous posts in this blog, you will see that there are a lot of Kubernetes objects and configuration files that you will need to manage when operating an application in a Kubernetes cluster. This can become a lot to deal with. As deployment processes and configurations become more sophisticated, teams need strategies for managing the complexity. One tooling option for managing this complexity is called Helm.

Helm is a powerful tool that allows you to templatize your Kubernetes constructs and manage them all as one logical unit. This structure makes managing the collection of Kubernetes yaml files necessary for an application simpler and allows you to focus more effort on designing resilient deployment processes.

This post will give you some working knowledge of helm in a palatable manner. This is not intended to teach you about the architecture of helm or cover advanced use cases. It is meant only to be an introduction.

Helm advertises itself as the package manager for Kubernetes. Therefore, it draws inspiration from products like rpm and apt. With helm, you get a consistent packaging format that can be used to manage and distribute a collection of Kubernetes yaml files as one unit.

The consistent packaging format used in Helm is called a chart. A chart is a collection of files and folders organized in a specific structure that the helm cli can recognize and use.

Helm chart files

Above is an example of a helm chart. Below I will describe the files/folders in this helm chart one-by-one:

Chart.yaml

• This contains metadata about the helm chart, including its name, version, description, and names of its maintainers.

README.md

• The README.md is not exactly a required file for a helm chart, but these files are always useful to have in a chart for documentation.

templates

• The template folder contains all of the Kubernetes yaml templates that the helm package manager will apply to a cluster. More information on how these yamls are templatized will be included later.

values.yaml

• This file contains default values used to evaluate the templates at install time.

Helm uses templates rather than plain Kubernetes yaml files. This way, fields can be modified for different sorts of installations. Below is an example of a template.

Helm template for a Kubernetes deployment

At first glance, it looks very similar to a regular Kubernetes deployment yaml, but the fields for the pod version label and docker image are actually configurable values. These values are evaluated at install time based on values set in the values.yaml file inside the chart and the overrides provided by the client. This approach to templating may look familiar to Go developers, but it may look a little intimidating for everyone else. Fear not, the helm documentation has a very good page explaining how helm templating works with plenty of examples.

https://docs.helm.sh/chart_template_guide

Now that we’ve covered what a chart is, let’s look at how we use this construct to manage helm packages. The first thing we’ll need to do is install helm. Please follow the official guide to install the helm cli. To continue, you will also need a Kubernetes cluster to work with. If you need help getting a Kubernetes cluster running, consider taking a look at my previous post on the subject.

Helm uses the same Kubernetes config file that kubectl uses. Therefore, once you set up kubectl, you will be able to start using helm to manage some applications.

The next thing you will need to do is initialize helm. Helm has a Kubernetes side component called “Tiller” that is used to keep track of helm releases and manage changes. In order to initialize tiller, you will need to execute the following command from a terminal window.

helm init

When you execute this, you should see something similar to the image below.

Helm init

With tiller installed, we can start managing some deployments using helm. The first thing we’ll do is clone this repository where I have prepared a helm chart.

git clone https://github.com/bricerisingslalom/hello-k8s.git

Once cloned, please cd into the project directory. I have prepared a helm chart that we will use in the chart directory of the project. In order to install a helm package, all you will need to do is execute the following command.

helm install --name hello-helm chart

When you execute this, helm creates what is called a release. A helm release is an instance of an installed package by helm on a Kubernetes. The --name option allows you to give it a name and the chart argument is just the directory of the helm chart.

Once installed, you will be able to access the pod using the following url. In it, you will need to replace the K8S_NODE_IP and NODE_PORT strings with the appropriate values for your cluster.

http://K8S_NODE_IP:NODE_PORT/hello-k8s

When you go to that address, you should see the following page.

Hello Kubernetes page

If you need to find the correct node port for your Kubernetes service, you can retrieve this information through the helm cli. Simply execute the following command and you’ll see information about every Kubernetes construct helm has created for your release. If you are unsure about what a node port is, please take a look at the service section of my previous post.

helm status hello-helm

Now you have officially deployed your first application with helm! But helm can do more than just that. It can also upgrade and rollback applications as well. These will be useful features in any CICD pipeline you will build for your application. In order to try out upgrading an application, you just need to execute the following command.

helm upgrade hello-helm chart --set hellokubernetes.deployment.image=docker.io/bricerisingslalom/hello-k8s:more-exclamation

What this will do is upgrade the release with the new values that you provide it. In this example, we are changing the value that sets the docker image. We are going to use the image tagged “more-exclamation” from the hello-k8s docker repository. Doing so will perform a rolling update to the application deployment and afterward, we should see a new web page.

More excited hello Kubernetes page

If you don’t see the new web page, please clear your browser cache and try again.

Now we should have a webpage with more exclamation marks than the last one. This is not all helm can do though. It can also perform rollbacks as well. We can demonstrate with the following command.

helm rollback hello-helm 0

The arguments for this command are the release name and the revision number. The revision number is the number of the specific revision you wish to rollback to. A value of 0 here means that you wish to rollback to the most recent previous revision of the release. After running this, we should see the original web page that we started with.

So in a few short minutes, we have managed to deploy an application, upgrade it and roll it back all using a single tool. I hope this post has demonstrated that helm is a very powerful tool that can do a lot with very little effort. If you found this post helpful and are excited to learn more about how you can take advantage of helm, please let me know with some claps and comments!

As always, those interested in joining the conversion can do so at http://slack.k8s.io