Helm Intro and Helm Cheatsheet
October 10, 2022 / 7 minute read
Below is an introduction to Helm! If you want to skip to the cheatsheet, you can download it here.
What is Helm
According to its own docs, Helm is "the" package manager for Kubernetes. What does this mean?
It's a way of keeping track of all your Kubernetes stuff!
Helm as I describe it is a mechanism for packaging and parameterizing standard
Kubernetes YAML files. It uses Go
most of this mechanism, and adds a layer of version / metadata tracking as
well. All of this packaged up into tarballs used by a client-side-only (as of
helm v3) CLI.
So basically: Helm = YAML + Go Templating + Versioning + Tar balls.
Why use it?
Why use it? There are lots of alternatives out there, and many purported "Helm replacements," but Helm has yet to give up its throne, and I have not found anything better for my own use cases... yet. So what are Helm's strengths?
I will do my best not to wax poetic. I am biased and a big fan of Helm. As a layer of abstraction between an application and Kubernetes, I think it is a fantastic asset.
In particular, I think this is because:
- No runtime dependency
- Client-side only utility
- Data stored server side for collaboration
- output represents native Kubernetes objects (i.e. interoperable with other tools)
helm templategives rapid feedback on iterating and testing
- plain text file output / diffs is very easy to parse
As a system administrator, it is nice because it offers:
- Version pinning for reproducibility
- Everything is open source tarballs, so dependencies are easy to track and introspect
- application vendors will ideally maintain their own chart and good NEWS files
When to use it?
So that's what it is, and why it is desirable. But when is it useful?
I find that helm particularly shines in a handful of situations:
- Managing an array of applications deployed on Kubernetes
- Packaging your own application for use by customers
- Encoding complex knowledge about "how to run an application" (to an extent, then you get to operators)
- To set up easy "roll-back" policies for applications that support the behavior
Occasionally a wrapper like ArgoCD, Flux , helmfile, or pulumi will be useful to manage your helm deployments too, so that you don't have to keep track of a bunch of CLI commands.
When not to use it?
Helm can definitely be overkill in some "hello world" or very simple deployment situations. Unfortunately, it also does not have a great answer for CRDs yet. Moreover, it is only useful for Kubernetes, so if you are unfamiliar with Kubernetes, it will have limited utility for you.
The other case where it may not be useful is in some internal applications. Maintaining a helm chart for an application can end up being a sizable amount of work, and they do not allow arbitrary inputs, so if you miss some key (i.e. "imagePullSecrets,") you can end up spending a lot of time key-chasing across your charts. I have heard of folks using Kustomize in such a situation, although another option is to use a meta chart (one chart for many apps) or Functions-as-a-Service (FaaS) framework like Serverless, OpenFaas, Knative, etc.
Also, helm charts do have a complexity ceiling. Go Templating provides lots of flexibility, but being DRY is hard, and there are many parts of the process that are not optimal from a software development point of view. As charts become more complex, an operator becomes increasingly beneficial as a mechanism to provide better software semantics to the application management process. However, the learning curve for operators can also be a bit steep.
Finally, helm charts unfortunately do not have hard-and-fast standards about how values are used across the ecosystem. As a result, you will often encounter wild variations in chart quality, value naming, and value behavior.
Let's get started on a hello world example! First, you need to install kubectl, install helm, and have a kubernetes cluster available. Once those things are taken care of, a hello world example of a helm deployment is pretty straightforward!
For this example, we will use my generic chart, useful for deploying simple services with standard configuration or helm needs.
We are also going to use this hello-world container.
First, add the repository that houses our example chart:
helm repo add colearendt https://colearendt.github.io/helm/
You can look at the values available for the chart:
helm show values colearendt/generic # I like to pipe it to a pager for search and such helm show values colearendt/generic | less
Then create a YAML file called my-values.yaml to hold values:
image: repository: paulbouwer/hello-kubernetes tag: "1.10" pod: port: 8080
Then template the output:
helm template hello-world colearendt/generic -f my-values.yaml
And install it into the Kubernetes cluster!
helm upgrade --install hello-world colearendt/generic -f my-values.yaml
Then you should be able to see the app deployed:
helm list kubectl get pods
And view the service in your web browser at http://localhost:8080:
kubectl port-forward svc/hello-world-generic 8080:80
If you want to clean up after yourself:
# delete the helm release helm delete hello-world # delete the repository reference helm repo remove colearendt
Unfortunately, I have not taken much time to dive into troubleshooting here! If you are hitting issues, please shoot me an email - I would love to have feedback on what to improve! Maybe someday I will take the time to set up comments 😅
So now you have a "Hello World" deployment under your belt. However, it also helps to keep in mind some best practices as you keep improving. Below is a handful of helm chart conventions that may be unfamiliar if you are new to the community:
- Make sure to pin helm chart versions with the
- Maintain a
NEWS.mdfile (or read the
NEWS.mdfile) to keep track of changes between versions
- Keep an eye out for "upgrading directions" in the
helm show valuesto see the default values (and comment strings associated). Ideally these are presented or discussed in a
sub-chartsif you can. It is tempting as a DRY software principle, but turns out to be a pretty advanced topic with lots of tricky edge cases. In particular, namespaces can be painful.
I took the time to arrange a "cheat sheet" of my favorite helm commands and the contexts in which they are useful. It was inspired by RStudio's array of excellent cheat sheets for the R community.
A hit-list of some of the most useful commands:
helm show values chartrepo/chartname
helm template releasename chartrepo/chartname
helm upgrade --install releasename chartrepo/chartname
helm repo add https://repourl
helm repo list
helm search repo
And the cheat-sheet itself can be downloaded here.
The helm project is an open source project. There is much that could be improved, and many applications that need helm charts or need improved helm charts. You can make a difference! If you are interested in learning more, check out the helm tag on this blog to see other writing on the topic, and start poking around on ArtifactHub, where lots of charts are centralized for easier searching!