Introduction

Welcome to the fascinating world of Kubernetes, where managing, deploying, and scaling containerized applications becomes easier and more efficient. One of the key players in this domain is Helm, a powerful package manager for Kubernetes. Whether you're new to Kubernetes or looking to streamline your application deployment, understanding Helm is fundamental.

What is Helm?

Helm is the first and widely accepted package manager for Kubernetes. Kubernetes is said to be the Operating System of the Cloud. Any operating system needs a package manager. But why?

The need for a package manager

Let's say that you are running on Ubuntu Linux. As a web developer, you want to test your work, so you need a web server installed. You learned that Nginx is a robust and easy-to-use web server, so you want to install it.

But installation is only half of the story. What if you want to re-install or upgrade? What if you want to remove it (uninstall it) from the system?

Software gets installed to operating systems in the form of "packages". A package is just a number of files and directories stored in a specific directory structure and compressed in an archive.

The archive itself differs depending on the type of package. The simplest form is just a gzipped TAR archive (files ending in .tag.gz). However, there are also other forms like NPM files for Node.js application, Java JAR, and WAR (and even EAR) files, PHP phar files, Ruby gems and so on. The trick here lies in how the package manager understands the compressed file; how and where to place each file and directory and how to keep track of them across updates.

As Kubernetes gained a lot of traction in the past few years, more and more applications started migrating to Docker containers, there needed to be a unified way of installing, managing, upgrading, and uninstalling a Kubernetes application the same way as we do in an operating system like Windows, macOS, or Linux.

How Helm Works?

To understand how Helm works or even why it is needed, consider the following example.

Assuming that you want to install Apache Kafka, the well-known event broker into a Kubernetes cluster. How would you go about this? Without going into much detail about how Kafka works (since that's a topic of its own) you just need to know that it requires — at least — a StatefulSet, a Service, some secrets and ConfigMaps, some persistent volumes and persistent volume claims. It also ships with a helper application called Zookeeper, which requires its own share of Kubernetes manifests. Once Kafka is installed, you need to make sure that Zookeeper can communicate with it. Let's brainstorm the challenges that you have with this kind of deployment:

1. The configuration is considerably complex with many moving parts. Change the setting in one place and you have to cascade it everywhere else. This could easily become a living hell.
2. Kafka is a stateful application. It requires persistent storage that varies from one platform to the other. Are you going to deploy it on-prem? What if you decided to migrate to AWS? You will need to change the storage class and other storage aspects to adapt to the new environment.
3. Kafka uses Service Discovery to find out about the other brokers in its cluster. This adds extra overhead to correctly craft the services and DNS.
4. What if you want to install a new version of Kafka that happens to require changes in the configuration?

The list can go on and on. It's clear that plain Kubernetes manifests maybe just fine for deploying a sample Nginx application to show case some static HTML files. But for large and complex applications, they just fall short.

How Helm works

Helm solves the above challenges by converting plain Kubernetes manifests into "templates". Templates contain many placeholders for variables that can be configured in another file called values.yaml.

Templates, values.yaml, and other important files are all packaged into a single entity called a "chart". Remember Node.js NPMs, Ruby gems, and Java JARs? Well, Helm uses charts for the same purpose.

To make the picture clearer for you, the following is an excerpt of the Bitnami Helm Chart for Kafka:

spec:
  podManagementPolicy: {{ .Values.podManagementPolicy }}
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels: {{- include "common.labels.matchLabels" . | nindent 6 }}
      app.kubernetes.io/component: kafka
  serviceName: {{ printf "%s-headless" (include "common.names.fullname" .) | trunc 63 | trimSuffix "-" }}
  updateStrategy: {{- include "common.tplvalues.render" (dict "value" .Values.updateStrategy "context" $ ) | nindent 4 }}

Anything that lies between `{{` and `}}` are dynamic; they are grabbed or calculated when the chart is being applied to the cluster.

For example, `{{ .Values.podManagementPolicy }}` can be read as follows:

Get me the value of the variable titled podManagementPolicy. But where can we define this value so that the template can make use of it? Typically, in a file called values.yaml (I'm saying typically because you can give it a different name if you want to).

This is an excerpt from the values.yaml file where the podManagementPolicy is defined:

## @param podManagementPolicy StatefulSet controller supports relax its ordering guarantees while preserving its uniqueness and identity guarantees. There are two valid pod management policies: OrderedReady and Parallel
## ref: https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#pod-management-policy
##
podManagementPolicy: Parallel

If you're new to YAML, anything that starts with # is a comment. The comment here is explaining the possible values for the podManagementPolicy. Then, it is setting the default value that the template would use. You either use the default value or override it with your own.

Why use Helm?

You can work with Helm in one of two ways:

1. Create your own charts: this is where you package your own Kubernetes application into a chart and distribute it to your teammates or to the community.
2. Use a ready-made chart like the Apache Kafka chart from Bitnami that we've shown above.

The advantages of using Helm are many. But let's recap the most important of which:

1. Simplified Deployment: Helm charts package up all the necessary Kubernetes resources into a single unit that can be easily deployed or updated. This makes it easier to manage complex applications and services. Apache Kafka is a good example.

2. Parameterization: Helm charts can be parameterized with variables, which allows the same chart to be reused in different environments or for different deployments. This makes Helm charts more flexible than plain manifests. Think of having to deploy Kafka to dev, staging, and production. Also, to AWS and Azure where each one uses a different storage class.

3. Consistency: Helm helps to ensure deployments are done consistently across different environments. It can help reduce "works on my machine" issues. When the same tool is used on the developer's laptop as well as on the CI/CD pipeline, this problem should be mitigated.

4. Versioning and Release Management: Helm has built-in support for versioning and release management. You can roll back to a previous version of a release in case of issues with the current one. Rollbacks are an advanced feature of Helm, but it is quite powerful. When things go wrong, you not only rollback to the previous image version, but also everything that was part of the chart (ConfigMaps, Services, Ingresses, etc.)

5. Community Support: Helm has a large community and ecosystem, with many pre-built charts for common applications and middleware. This can save time and effort compared to creating and maintaining your own Kubernetes manifests.

6. Dependency Management: Helm charts can declare dependencies on other charts, making it easy to deploy complex applications with many components. Think of a web application that requires a MySQL database to run. A MySQL chart can be added a dependency to the application chart. Now, Helm will deploy MySQL first before deploying the application. Additionally, you can pass variables from the application chart to the database one and vice versa.

Conclusion

In this age of microservices and containerized applications, Helm serves as a critical tool, simplifying the complexities of managing Kubernetes applications. This guide serves as an introduction, but there is a lot more to explore and understand.

In our next article, we will guide you through the installation process and introduce you to Helm's basic commands. Stay tuned!

I hope you found this article about Helm valuable. If you'd like to delve deeper and become proficient in Helm, I highly recommend checking out my comprehensive course on Udemy: Helm — The Kubernetes Package Manager Hands-on course. It's structured for learners of all levels and is full of hands-on examples and insightful tips. Click here to start mastering Helm today!