Deploying applications to Kubernetes can be complex as you may be required to create multiple interdependent resources. This blog explains how Helm can help software professionals to package, configure and deploy applications onto Kubernetes.
Helm is an open source package manager for Kubernetes. Most software development processes need a package manager which can simplify installation and maintenance. However, with increase in the number of components in an infrastructure, managing clusters in Kubernetes can become very complicated. This is where Helm comes into the picture as it wraps up all the components in a single package. It also helps automate software installation, configure software deployments and fetch relevant data. Let's take an example of an app that needs:
Now, every object of the application requires a separate 'yaml' file. To create these objects, we need to run the 'kubectl' command. Complications may arise in situations where a bug is introduced or we need to modify the value of secrets. In these situations, we need to rollback, which requires revisiting every file individually to keep them in a particular order.
This problem can be solved by creating one huge file and defining all the object resources in it. By doing this, we can avoid frequent rollbacks. But think in terms of the need to modify values in a large file. For example, what if we need to modify the persistent volume size from 10GB to 100GB?. Given the size of the file, we would need to make sure we are making changes in the right place, and also not introduce any new bugs.
Let's take the example of rpm. An application consists of configuration files, binary files, etc. Rather than placing all these files in an individual directory of our system, we can run one rpm command, which will take care of installing all configuration and binary files in an appropriate directory. Helm takes a similar approach to solve this problem in the previous scenario.
It wraps together all the necessary components (deployments, services, secrets, persistent volume) in a single package. Whenever we need to install these resources, we just need to trigger the requirement in Helm to install a package, and it will install all the corresponding resources. Also, we only need to modify a single file (values.yaml) to update all the resources that are packaged using Helm.
To install Helm on all the supported platforms, check the following documentation.
Helm uses a command-line utility on your local system to perform Helm actions like install, upgrade, or rollback charts. Let us first understand what is a chart? Helm bundles all your related manifests into a chart, such as deployments, services, and pods. This chart contains all of Helm's instructions to create a Kubernetes object in your cluster.
When you install a chart, a release is created. Within each release, you can have multiple revisions. This chart is then passed to Helm, and it connects to Kubernetes API using kubeconfig (~/.kube/config) to create Kubernetes objects. Now, the next question is where does Helm store the metadata information (such as the installed release, the chart used, revision state), and the answer to that question is inside your Kubernetes cluster in the form of a secret.
The way we can find docker images in a DockerHub, we can also find the Helm chart in a repository called ArtifactHUB.
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/2c6b5a2e4deb9e83e2b6845eea19e69b.js</p>
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/584ba5ea8ab1651a23ff5adf447e8ef4.js</p>
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/95c676eee2e9d3cda0e3314f13b8e55b.js</p>
NOTE: After you have installed the chart, you will also get some useful information like how to use this chart.
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/0977d8c337cfe9b7f18130b36a8a334d.js</p>
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/65652ab417daf7b892e901f2fc6852ec.js"</p>
Previously, we installed the chart using the default value. But that may not be your requirement all the time. Hence, you may also pull the chart and then modify 'values.yaml' file according to your requirements.
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/34060bb6ca3e23e14d1a71a41d0af4ca.js</p>
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/3aa8f5cc247639f9dd445821fd7a503e.js</p>
So far you have learned how to install an existing chart from ArtifactHUB and modify the values in those charts. In the next section, we will learn how to build our chart from scratch.
In previous steps you have installed or modified a chart created by someone else, which is fine in most scenarios. But in cases where you have a custom application, or you need to customize your chart, you will be required to create your own custom chart.
The easiest way to get started with charts is by using ‘helm create’ command. This will create a chart structure for you.
apiVersion: When Helm3 was introduced, it came as a field 'apiVersion' to differentiate between Helm v2 vs. Helm v3 chart. For example, Helm v3 has field dependencies not present in Helm v2. So the general rule now is, all the charts built for Helm2 have the field set to v1 and for Helm3 it is v2.
appVersion: This is the version of the application that's inside your chart. For example, if you are installing MySQL, it is the version of the MySQL database. This field is for informational purposes only.
version: The version field holds the value of a chart's version which is independent of the app's version that you have deployed. This is independent of the version of the app you have deployed. This field helps you to keep track of the changes in the chart.
name: This field represents the name of the chart.
description: This field holds the description of your chart.
type: There are two types of charts: applications (default) and library. The application chart is used to build applications, whereas the library chart is used to provide utilities that help build charts.
templates: It’s the most critical directory and contains Kubernetes resource definitions, for example; deployments, services, etc.
NOTE: We are trying to expose the deployment which doesn’t exist. Let’s create it temporarily as we want to create it via Helm.
This is all we need at this stage. Our Helm chart is ready to go. But before that, let's verify the files we created in the earlier steps, for example, 'deployments.yaml'. As you can see in deployments, all the values are static, for example, name: nginx, replicas: 1, or image, name: nginx.
By now you must be eager to run your first Helm chart but before doing that, check if your chart is working as expected. There are three ways of doing that:
<p> CODE: https://gist.github.com/ShubhanjanMedhi-dev/f3c84462ed6db7ee667fbc1debd5de19.js</p>
Once the chart is ready, we can share it with other team members or even globally, to promote collaboration. Developers on a global scale can help enhance the chart and fix bugs. In the next section, we will learn how to package a chart.
We have our chart ready, but if you want to share it with the rest of the team or the rest of the world, you need to package it.
Now that we have packaged our chart, it’s time to upload it to online repositories like GitHub or a bucket in S3, etc. These are the steps we need to follow:
In this blog, we have learned the basics of Helm and how to create a Helm chart. Helm is a powerful tool, and it greatly simplifies how package management works with Kubernetes.
Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil.