As I have started working more with Kubernetes lately I have found it very valuable to see what a manifest looks like before deploying it. Helm can basically be used as a quick and dirty way to see what a rendered Helm template looks like. This provides the security advantages of not running tiller in your production cluster if you choose to deploy the rendered templates locally.
Helm has been sort of a subject for contention for awhile now. Security folks REALLY don’t like running the server side component because it basically allows root access into your cluster, unless it is managed a specific way, which tends to add much more complexity to the cluster. There are plans in Helm 3 to remove the server side component as well as offering some more flexible configuration options that don’t rely on the Go templating, but that functionality not ready yet so I find rendering and deploying a nice middle ground for now.
At the same time, Helm does have some nice selling points which make it a nice option for certain situations. I’d say the main draw to Helm is that it is ridiculously easy to set up and use, which is especially nice for things like local development or testing or just trying to figure out how things work in Kubernetes. The other thing that Helm does that is difficult to do otherwise, is it manages deployments and versions and environments, although there have been a number of users that have had issues with these features.
Also check out Kustomize. If you aren’t familiar, it is basically a tool for managing per environment customizations for yaml manifests and configurations. You can get pretty far by rendering templates and overlaying kustomize on top of other configurations for managing different environments, etc.
Render a template (client side)
The first step to getting a working rendered template is to install the Helm client side component. There are installation instruction for various different platforms here.
brew install kubernetes-helm # (on OSX)
You will also need to grab some charts to test with.
git clone [email protected]:kubernetes/charts.git cd charts/stable/metallb helm template --namespace test --name test .
Below is an example with customized variables.
helm template --namespace test --name test --set controller.resources.limits.cpu=100m .
You can dump the rendered template to a file if you want to look at it or change anything.
helm template --namespace test --name test --set controller.resources.limits.cpu=100m . > helm-test.yaml
You can even deploy these rendered templates directly if you want to.
helm template --namespace test --name test --set controller.resources.limits.cpu=100m . | kubectl -f -
Render a template (server side)
Make sure tiller is running in the cluster first. If you haven’t set up Helm on the server side before you basically set up tiller to run in the cluster. Again, I would not recommend doing this on anything outside of a throw away or testing environment. After the helm client has been installed you can use it to spin up tiller in the cluster.
helm init
Below is a basic example using the metallb chart.
helm install --namespace test --name test stable/metallb --dry-run --debug
Again, you can use customized variables.
helm install --namespace test --name test stable/metallb --set controller.resources.limits.cpu=100m --dry-run --debug
You may notice some extra configurations at the very beginning of the output. This is basically just showing default values that get applied as well as things that have been customized by the user. It is a quick way to see what kinds of things can be changed in the Helm chart.
Conclusion
Helm offers many other commands and options so I definitely recommend playing around with it and exploring the other things it can do.
I like to use both of these methods, but for now I just prefer to run a local tiller instance in a throwaway cluster (Docker for Mac) and pull in charts from the upstream repositories without having to git clone charts if I’m just looking at how the Kubernetes manifest configuration works. You can’t really use the server side rendering though to actually deploy the manifests because it sticks a bunch of other information into the command output.
All in all the Helm templating is pretty powerful and combining it with something like kustomize should get you to around 90% of where you need to be, unless you are managing much more complex and complicated configurations. The only thing that this method doesn’t lend itself very well to is managing releases and other metadata. Otherwise it is a great way to manage configurations.
