Spotlight on Helm

As discussed in previous articles, Kubernetes is a very powerful container orchestration tool. It allows you to set up and maintain even the most complex group of containers and microservices across multiple clusters. The flexibility of Kubernetes is immense and there is virtually no environment you cannot set up using Kubernetes.

But while Kubernetes may be flexible and robust, it is not without its challenges. In fact, that same robustness can make Kubernetes overwhelming for some people. I know, because I felt the same way when I first started playing around with Kubernetes.

This is where Kubernetes Helm — or Helm, for short — comes in handy. Its purpose is to make the whole process of setting up the deployment of an application or an environment for multiple purposes easy. Many of the manual tasks can be fully automated, simplifying the use of Kubernetes like never before.

More About Helm

We typically rely on Kubernetes YAML files to configure Kubernetes clusters. The YAML files are there to describe everything from the way Pods need to be configured to how load balancing is done by the cluster. Unfortunately, setting up a new Kubernetes cluster means creating a .yaml file for that cluster. For many, this means copying and pasting configurations from another cluster and making manual adjustments to it.

That is exactly what Helm can help you with. Rather than having to configure a YAML file manually, you can simply call a Helm Chart — a Chart is the name for Helm’s package configuration — and let Helm do the rest for you. Yes, Helm is an actual package manager for your Kubernetes. It is similar to NPM in NodeJS and Maven in Java.

Helm Charts act as the template for Kubernetes clusters configurations. The template itself can be customized to mimic the setup parameters of the particular cluster. There is no need to make manual adjustments to variables such as hostname or provisions since Helm will take the correct variables and make the necessary adjustments.

To make it even better, there are a lot of Helm Charts that you can use out of the box. Do you need to add a MongoDB database to your setup? There's a Chart for that. Want to deploy a testing environment for your app? You can create a Chart to simplify that process too. Even the most complex Kubernetes setup can be charted (pun intended) into its own Helm Chart.

Pros and Cons of Using Helm Charts

The use of variables is certainly one of the major advantages of using Helm and Helm Charts. You can create a Chart by running the  helm create [chart name]  after installing Helm. A folder will be created, and you can start customizing the templates and values file (variables). These values or variables are then passed to the templates for the YAML files to be created. The deployment.yaml and services.yaml are the two files you want to focus on.

Helm Chart acts as a template for Kubernetes deployments, so you can create a template to suit your specific needs. Similar to how you can create multiple Pods for different versions of the microservice they host, you can also create different Charts for specific iterations and purposes.

There is also the fact that Helm Charts can be made incredibly flexible thanks to its use of values.yaml. You can take active steps towards moving most — if not all — of your variables to the values.yaml files and out of the template itself to allow for easier maintenance and more flexibility in updating the Charts.

The list of advantages goes on, but that doesn’t mean there are no disadvantages of using Helm Charts. For one, creating your first Helm Chart is rather complex the first time. Helm has a pretty steep learning curve and it can take some getting used to. Fortunately, there is extensive documentation from Helm to help you learn how to get things done.

Some Use Cases

We discussed how Helm Charts are handy for setting up Kubernetes clusters quickly. Once you can create your own Charts, you can also use Helm to help with deploying test environments and distributing pre-release versions of your application.

But why stop at pre-release versions? Helm Charts can also be used as a delivery method for production apps. You can, for instance, install WordPress on an empty cluster by running the correct Helm Chart for it; everything will be automated, and you will swiftly have a WordPress site up and running in seconds.

Since you can use values to define variables, Helm Charts can also be used for deploying the app onto different clusters or setups. Each variable can be adjusted on the fly as the Helm Chart is processed, allowing for greater flexibility in general.

Helm lends itself perfectly to the deployment of cloud-native apps. It completely reduces deployment complexity and lets developers focus more on other more important things. On top of that, Helm Charts also introduce standardized and reusable templates to the Kubernetes.

Using Helm

There are two sides of the Helm story. The client, called helm, is a command-line utility mainly responsible for sending the charts to be installed. The server-side (called Tiller) receives the templates sent by the helm-client and renders them to generate kubernetes manifest files which then are installed in the cluster. It also tracks release information, which allows the upgrade or roll-back a specific installation.

The tools available for Helm are just as interesting. Helmfile by roboll lets you deploy Helm Charts with ease. And Kubeapps simplifies the use of Helm Charts even more by adding a GUI and a functional dashboard for managing Helm and Kubernetes. For an extensive list of the great tools that work with Kubernetes and Helm, check out our

As always, the possibilities are endless, and it is up to you to utilize Helm and Helm Charts to your advantage. All I can say is that the steep learning curve is worth overcoming for all the benefits you get on the other side.

This post was originally published here.