In this post we are going to discuss a tool used with kubernetes called “helm”. In simple terms, helm is a package manager for kubernetes. Helm is kubernetes version of yum or apt. Helm deploys something called charts, which you can think of as a packaged application. It is a collection of all your versioned, pre configured application resources which can be deployed as one unit. You can then deploy another version of the chart with a different set of configuration.
Helm has two parts to it, the client(CLI) and the server(Tiller). The client lives on your local workstation and the server lives on the kubernetes cluster to execute what is needed. The idea is that you use the CLI to push the resources you need and tiller will make sure that state is in fact the case by creating/updating/deleting resources from the chart. To fully grasp helm, there are 3 concepts we need to get familiar with:
- Chart: A package of pre-configured Kubernetes resources.
- Release: A specific instance of a chart which has been deployed to the cluster using Helm.
- Repository: A group of published charts which can be made available to others.
Benefit of Using Helm
- Less Duplication: This is clearly the obvious one given once the chart is built once, it can be used over and over again and by anyone.
- Less Complexity: The fact that you can use the same chart for any environment reduces complexity of creating something for dev, test and prod. You can simply tune you chart and make sure it is ready to apply to any environment. And you get the benefit of using a production ready chart in dev.
- Less Learning Curve: This is another one that is key. K8s is hard to grasp if you are new to it, therefore what helm gives us is the benefit of allowing any developer to focus on app development as oppose to learning a new platform. All you have to do is define what you configs need to be. Again from out first point, less duplicity mean you can grab an existing chart and use it for your need without any issues.
Describing a Chart
Helm has a certain structure when you create a new chart. To create, run “helm create YOUR-CHART-NAME”. Once this is created, the directory structure should look like:
YOUR-CHART-NAME/ | |- .helmignore | |- Chart.yaml | |- values.yaml | |- charts/ | |- templates/
.helmignore: This holds all the files to ignore when packaging the chart. Similar to .gitignore if you are familiar with git.
Chart.yaml: This is where you put all the information about the chart you are packaging. So for example your version number etc. This is where you will put all those details.
Values.yaml: This is where you define all the values you want to inject into your templates. If you are familiar with terraform, think of this as helms variable.tf file.
Charts: This is where you store other charts that your chart depends on. You might be calling another chart that your chart need to function properly.
Templates: This folder is where you put the actual manifest you are deploying with the chart. For example you might be deploying an nginx deployment that needs a service, configmap and secrets. You will have your deployment.yaml, service.yaml, config.yaml and secrets.yaml all in the template dir. They will all get their values from values.yaml from above.
This process is pretty simple. You can install the binary version here. Unpack the helm binary and add it to your PATH and that should be all you need. You can also install it with package manager like homebrew. Once you have it installed, you can simply run “helm init” to install the tiller server into your k8s cluster.
In conclusion, helm is perfect if you want a structured way of deploying your apps into kubernetes. It is very handy in helping you focus more on your actual development as oppose learning the ins and outs of kubernetes. Take a look at the project here.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing email@example.com.