Grokking Helm

I’ve recently had to brush up on Kubernetes rapidly and that’s meant figuring out how Helm works. This has not been helped by the recent release of Helm 3 but I think I’ve got a handle on what Helm is and thought I’d share my thoughts.

I see yaml, it’s everywhere

To me one of the great things about Kubernetes is the way it encourages you to build your infrastructure as code. At least it would be great if you didn’t have massive amounts of code duplication. That seems to be where Helm comes in.

At its core Helm is a templating engine for Kubernetes configuration alongside some nifty tooling allowing you to manage the applications you deploy with it. I’ve often seen it described as a package manager for Kubernetes and I can see why but it’s helped me to think of it more as a templating engine with some nifty release management tools built on top.

Charting a course

Most guides to Helm start with installing the application and deploying a chart but this isn’t a guide to Helm so I'm going to run through what a chart is instead.

Kubernetes objects as I said earlier are nearly always just some yaml files describing the relevant Kubernetes object. A Helm Chart just takes these yaml files and uses Go templating to interpolate relevant variables such as environment specific configuration into the file. There is some Chart specific configuration that is unsuprisingly yaml in the form of a Chart.yaml file and then your variable declaration files so you can configure the parts of your deployment the way you want them.

This all looks something like the following:

.
├── Chart.yaml
├── README.md
├── prod_values.yaml
├── templates
│   ├── config_map.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

The variable declaration files are where the magic happens, you can use them to manage your deployments over time with git history, CD pipelines or the tooling that is built into helm. So you could have a variable declaration file called as in the example structure above “prod_values.yaml” where you have all of your production configuration and as new versions of your application are deployed git history will track the changes you have been making.

This post hasn’t really been about how to use Helm as there are ample guides around on how to do that, if you’d like to see one from me drop me a message on twitter and I’ll write it up. Instead what I’ve tried to do is explain how I understood what Helm was doing, how it fit into the Kubernetes ecosystem and why I would want to use it for deployments, I hope it’s helpful to somebody.