Helm is the best way to find, share, and use software built for Kubernetes.
Helm is widely known as “the package manager for Kubernetes“. Although it presents itself like this, its scope goes way beyond that of a simple package manager. However, let’s start at the beginning.
Helm is an open-source project which was originally created by DeisLabsand donated to CNCF, which now maintains it. The original goal of Helm was to provide users with a better way to manage all the Kubernetes YAML files we create on Kubernetes projects.
The path Helm took to solve this issue was to create Helm Charts. Each chart is a bundle with one or more Kubernetes manifests – a chart can have child charts and dependent charts as well.
This means that Helm installs the whole dependency tree of a project if you run the install command for the top-level chart. You just a single command to install your entire application, instead of listing the files to install via kubectl.
Charts allow you to version your manifest files too, just like we do with Node.js or any other package. This lets you install specific chart versions, which means keeping specific configurations for your infrastructure in the form of code.
Helm also keeps a release history of all deployed charts, so you can go back to a previous release if something went wrong.
Helm supports Kubernetes natively, which means you don’t have to write any complex syntax files or anything to start using Helm. Just drop your template files into a new chart and you’re good to go.
But why should we use it? Managing application manifests can be easily done with a few combinations of commands.
Helm really shines where Kubernetes didn’t go. For instance, templating. The scope of the Kubernetes project is to deal with your containers for you, not your template files.
This makes it overly difficult to create truly generic files to be used across a large team or a large organization with many different parameters that need to be set for each file.
And also, how do you version sensitive information using Git when template files are plain text?
The answer: Go templates. Helm allows you to add variables and use functions inside your template files. This makes it perfect for scalable applications that’ll eventually need to have their parameters changed.
It’s pretty easy to create a chart in Helm. First, you need to have Helm installed. Then, just type in helm create and it will create a directory filled with files and other directories. Those files are required for Helm to create a chart.
Let’s take a closer look at what this file tree looks like and what the files are within it:
Ok, you created your chart, now what? Do we have to download the entire repository to install those charts? No! Helm has a public library for the most used charts, which kind of works like Docker Hub.
You can also create your own chart repository and host it online. Helm drinks from the same fountain as HomeBrew, or Linux. You can tap these repositories to download charts contained in them.
Since a chart repository is basically an index.yaml file served from a static web server, you can pretty much create a chart repository out of anywhere.
Take Zaqar, for example – it’s hosted on GitHub Pages and is accessible through my domain. When Helm looks for an index.yaml file it’s actually looking for the list of available versions of that chart, their SHA256 digests, and the location of the packaged .tgz file to download the chart itself. This is pretty much what NPM does under the hood (overly simplified).
This means we don’t need to have your repository cloned forever, and our charts can be private as well. We only need to create a chart repository.
We can even use hosted services like Azure CR to do the job, or we can have a full solution called Chart Museum, which allows us to store your charts and provides us with a neat UI.
Information Source – https://www.freecodecamp.org/news/what-is-a-helm-chart-tutorial-for-kubernetes-beginners/
