In this blog, we will briefly see the helm architecture.
Helm has multiple components we’ll be working with. So let’s take a look at its general structure, concepts, and the pieces we’ll be working with.
Helm Binary File (Helm Executable/Program)
The binary file is the executable file, the program that we use on our computers to instruct Helm to do its magic in our Kubernetes cluster. We use this in commands such as:
helm install my-wordpress-site bitnami/wordpress
With such a command, we are actually executing the file called helm. When this executes, it looks at what parameters we passed to it. So, in this case, it seems that we want to “install” something, call it my-wordpress-site and use the chart located at bitnami/wordpress.
Charts are a collection of files. And they contain all the instructions that Helm needs to know how to be able to create the collection of objects you need in your Kubernetes cluster. By using these charts and adding the objects according to the specific instructions in the charts, Helm, in a way, installs “apps” into your cluster. Of course, these are not apps in the conventional sense, like apps on your phone, but they’re often similar in scope: a collection of objects that work together to perform some kind of task.
In a Helm chart, we’ll often be interacting with a special file. You see, most of the time, we won’t need to build the charts ourselves. We have hundreds of them already available to download. But what we’ll almost always need to do, or want to do, is configure the package we install through that chart.
Consider the example above, using Helm to install a WordPress website, with a chart we downloaded from Bitnami. We can open the values.yaml file and configure some important parameters there. For example, we can choose the admin username for our website, the password, the blog name, and so on. Charts will come with many default values already preconfigured. But having this file around gives us a central location where we can quickly find and edit the settings that this app will get installed with, according to our likes and needs. When Helm uses the chart, it takes a look at the values we put there and configures the release with those parameters.
So we can consider values.yaml is like a settings file for the releases we install based on that chart.
When a chart is applied to your cluster, a release is created. We could ask ourselves, why the need for an additional item? Why can’t we just say we installed a chart to Kubernetes?
In the command
helm install my-wordpress-site bitnami/wordpress
We used the chart at bitnami/wordpress and named the release my-wordpress-site.
So why not just use a shorter command like
helm install bitnami/wordpress and be done with it? No release name. Well, one simple reason why it makes more sense to have releases based on charts is that we can install multiple releases based on the same chart. So we can launch a second WordPress website with a command such as:
helm install my-SECOND-wordpress-site bitnami/wordpress
And since they’re two different releases, they can be tracked separately and changed independently. Even though they’re based on the same chart, as releases, they are two entirely different entities.
This can be useful in a lot of scenarios. For example, you could have a release for a WordPress website that your customers use, and another release for a WordPress website that is only visible to your internal team of developers. There, they can experiment and add new features without breaking the main website. Since the two releases are based on the same chart, once they get something working correctly on the development website, they can transfer it to the main website, since it should work exactly the same, as the two websites are basically clones, built the same way.
Just like we can find all kinds of freely available projects on GitHub, we can find Helm charts in public repositories. For example, on the https://artifacthub.io/ repository, you will often find what you’re looking for, and sometimes, the charts are actually published by the actual developer of that project. You will see the Official or Verified Publisher badges in such cases, and it’s preferable you use those when available.
In the command we kept offering as an example above, bitnami is the repository name, and wordpress is the chart name so we end up with bitnami/wordpress to specify both the repository and chart we want to pull from an online source.
Metadata (Data about Data)
To keep track of what it did in our cluster, the releases installed, the charts used, revision states, and so on, Helm will need a place to save this data. Now it wouldn’t be too useful if it would save this on our local computer. If another person would need to work with our releases, through Helm, they would need a copy of our own data. So, instead, Helm does the smart thing and saves this metadata directly in our Kubernetes cluster, as Kubernetes secrets. This way, the data survives, as long as the Kubernetes cluster survives, and everyone from our team can access it, so they can do helm upgrades or whatever they need. So Helm will always know about everything it did in this cluster and will be able to keep track of every action, every step of the way since it always has its metadata available.
Want to learn more about Helm’s basic concepts and features? Check out this video.
Checkout the Helm for the Absolute Beginners course here
Checkout the Complete Kubernetes learning path here