If you know about Kubernetes, then you must have heard about Helm charts too. In a Kubernetes cluster, we can install services using YAML files using which we create various Kubernetes resources like a Service, Deployment, StatefulSet, ClusterRole, DaemonSet, and what not. In the YAML files, we have a lot of configurations like Port number for services, Kubernetes service resource usage configuration, name of the resource, docker image URL, docker image Tag, etc., and these configurations are used while starting an application in Kubernetes cluster.
Using the default YAML for starting application has two issues(maybe more):
All the configurations are specified within the YAML files and to change anything for example the version of the application installed or the resource limit for the pod, we will have to update the YAML file.
The second problem is, if we have to specify dependency amongst applications in the Kubernetes cluster, there is no way of doing that.
Another problem is if you are working on an application incrementally and for including new configurations you have been changing the YAML file in phases, but in YAML there is no proper way of maintaining the versions.
Because of all of these reasons, and a lack of a central repository of YAML for running applications in the Kubernetes cluster has led to a lot of different, non-standard approaches being followed by developers around the world.
But wait, we have Helm now!
Helm is a package manager for Kubernetes which can be used to install and upgrade applications using Helm charts. Now, if you don't know what a package manager is, then let's take an example.
Consider that there is a software developer Bob who is experienced with the MySQL database and knows how to install it on the Linux operating system along with configuring the MySQL service. Now if Bob has to share all his knowledge of installing and configuring the MySQL service with someone who has no idea about MySQL, then he must package all his knowledge into some sort of program which the other person can run and it installs MySQL and configures it too, well this is exactly what a package manager does.
Helm charts can be used to install or upgrade any application in Kubernetes along with installing all the dependencies of the application if any. The Helm charts can be found in the Helm Hub, which is a registry of Helm charts.
I came across Helm when I was working with the EFK stack for logging in Kubernetes and had to provide a solution for a smooth installation of all the applications. Although we could have used simple YAML files, but maintaining those YAML files and providing some sort of abstraction so that not everyone can edit the YAML files was a bit tricky.
But using Helm, all this seems pretty easy, because the Helm chart uses YAML templates for application configuration with separate values.yaml file to store all the values which are injected into the template YAML at the time of installation.
And we can have multiple files as templates and a single file holding the values, and this complete setup is called a Helm chart.
As you can see in the image above, without Helm, we simply have multiple YAML files with all the configuration values inside it and we can use the command
kubectl apply to apply those YAML files and create the resources.
But with Helm, we have some templates, which in turn accepts a few values and that values can be provided in a separate values.yaml file, and once all this is packaged into a Helm chart, anyone can use it using the
helm install command and providing custom values to the configurations via an external values files or as an argument to the
helm install command and those values are used while creating the Kubernetes application.
When we have such Helm projects which can be used to install applications, we can easily link them with each other. Yes, in Helm we can provide dependencies too, for example, if you have an application A which is dependent on application B, we can specify in the chart of application A, that application B is required, and helm will automatically install application B when anyone tries to install application A.
So the dependency management is also sorted with Helm. Although Helm is capable of doing a lot more, for introduction, knowing this much is more than enough. I wouldn't overwhelm you with a lot of information.
Following are a few things that Helm can do:
Create new charts from scratch.
Package charts into chart archive (tgz) files.
Interact with chart repositories(like Helm Hub or Google Helm repository) where charts are stored.
Install and uninstall charts into an existing Kubernetes cluster.
Manage the release cycle of charts that have been installed with Helm
In the upcoming tutorials, we will learn how to setup Helm in Windows or Linux or Mac operating system and will also create a simple Helm project and run it in the Kubernetes cluster.
Well with this now you know what Helm is and why you should explore it more. If you see more related tutorials in the suggestions somewhere on this page, don't hesitate to open them and go through them. And if you have any confusion, please do post in the comment section below and I will be more than happy to get into a discussion.