Is Helm used just for templating Kubernetes YAML files?

Published in April 2019

Welcome to Bite-sized Kubernetes learning — a regular column on the most interesting questions that we see online and during our workshops answered by a Kubernetes expert.

Today's answers are curated by Daniele Polencic. Daniele is an instructor and software engineer at Learnk8s.

If you wish to have your question featured on the next episode, please get in touch via email or you can tweet us at @learnk8s.

Did you miss the previous episodes? You can find them here.

Is Helm used just for templating Kubernetes YAML files?

TL;DR: Helm is used for templating, sharing charts and managing releases. If you're looking just for templating, you should check out kustomize.

When you start using Kubernetes in different environments, you might see yourself copy-pasting the same YAML resources over and over.

A better strategy is to create and use dynamic templates as you've done for HTML pages — for example.

All the variables that can change are replaced with placeholders.

Before submitting them to the cluster, you could use the template engine of choice to customise them with the correct value.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      env:
        - name: ENV
          value: {{ .Values.env_name }}

While there're a lot of tools to template Kubernetes YAML files, Helm caught a lot of attention very early on and established itself as the market leader.

Helm is a convenient templating engine: it uses the Go templating engine and the helpers from the Sprig library.

You can compile and deploy the pod.yaml resource above with:

helm template . \
  -x templates/pod.yaml \
  --set env_name=production
---
# Source: helm-chart/templates/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      env:
        - name: ENV
          value: production

But the reason for such a quick uptake isn't for the templating alone.

A collection of templated resources in Helm is called a chart.

Charts are similar to archives, and you can share them with your colleagues or upload them to a registry.

Charts became such a ubiquitous tool to share collections of YAML files and that helped Helm raise in popularity.

Have a look at all the available charts on the public registry.

Please note that you can use helm search <keyword> to search for a specific chart on the official registry.

helm search mysql
NAME                              DESCRIPTION
stable/mysql                      Fast, reliable, scalable, and easy to use open-source rel...
stable/mysqldump                  A Helm chart to help backup MySQL databases using mysqldump
stable/prometheus-mysql-exporter  A Helm chart for prometheus mysql exporter with cloudsqlp...
stable/percona                    free, fully compatible, enhanced, open source drop-in rep...
stable/percona-xtradb-cluster     free, fully compatible, enhanced, open source drop-in rep...
stable/phpmyadmin                 phpMyAdmin is an mysql administration frontend
stable/gcloud-sqlproxy            DEPRECATED Google Cloud SQL Proxy
stable/mariadb                    Fast, reliable, scalable, and easy to use open-source rel...

Companies started sharing packages internally in their teams, and that led to private registries.

You have a public registry with packages contributed by the community and private registry for internal use.

Tools such as Artifactory or Azure Container Registry are popular options when it comes to using a registry to store your private charts.

If you wish to host your private registry Chartmuseum is a solid choice.

But templating and sharing charts are not the only tasks that Helm can handle.

Helm is deployed into parts: a client-side binary and a server, which is deployed inside your cluster as a controller.

The server component is usually referred to as the Tiller.

Every time you install a chart or upgrade your definitions, the client sends the YAML resources to the Tiller.

The Tiller templates the YAML files and stores a copy of them for future reference.

Keeping track of all releases is handy.

You can roll back when you notice that the current deployment doesn't behave the way you expect.

Helm helps you manage the lifecycle of your releases.

From creating to updating and deleting charts, Helm makes sure there's always an audit trail, and you can inspect the current and past state.

To summarise, Helm is:

• a templating engine for your YAML files
• a convenient way for packaging collections of YAML files and distributing them in public and private registry
• a release manager capable of rolling back deployments

Is Helm the only option?

Other tools to kustomize your YAML

Two recent events threaten Helm's popularity.

First, Helm 3 was announced in June 2018 as a radical departure from the previous version.

It doesn't feature a Tiller anymore: having a component that has admin-like access to create resources in the cluster was also a security concern.

What if a malicious user can get hold of the Tiller?

They could end up with unlimited access to creating and deleting resources inside the cluster.

However, removing the tiller is posing new challenges on how to manage releases and rollbacks.

Also, Helm 3 offers a novel approach to templating resources.

You can use Go templates like in Helm 2, but you can also leverage Lua to write resources as code.

Here's an example of a Pod written in Lua:

local pods = require("mylib.pods");
function create_alpine_pod(_)
  myPod = pods.new("alpine:3.7", _)
  myPod.spec.restartPolicy = "Always"
  -- set any other properties
  _.Manifests.add(myPod)
end

Lua is meant to solve nasty hacks such as the need to indent lines in the Go templates.

The other noteworthy event is a competing templating engine was merged in the official kubectl client: kustomize.

Kustomize lets you customise your YAML files by applying patches and overlays to your existing resources.

You can think of Kustomize as a way to define exceptions on your YAML files without touching the original file.

Let's have a look at an example for a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-pod
    image: nginx

And a kustomization.yaml like:

commonLabels:
  env: production
resources:
- pod.yaml

When you run kubectl apply -k . the following resource is submitted to the cluster:

apiVersion: v1
kind: Pod
metadata:
  labels:
    env: production
  name: my-pod
spec:
  containers:
  - image: nginx
    name: my-pod

You can use kustomize as an independent binary, but having it bundled in kubectl is convenient.

It also demonstrates the commitment of the SIG-machinery to provide a reliable alternative to Helm.

With Helm 3 still in the making and kustomize being merged in kubectl, it looks like the war for a Kubernetes templating engine has just started.

That's all folks

Still, have questions about Helm and what it can do?

Let us know in an email or ask us with a tweet.

A special thank you goes to Mike Bright that reviewed the content of this article.

If you enjoyed this article, you might find the following articles interesting:

• How do you visualise dependencies in your Kubernetes YAML files? When you have a large number of resources in your Kubernetes cluster, you might lose track of all relationships between them. Learn how to visualise your dependencies.
• Boosting your kubectl productivity. If you work with Kubernetes, then kubectl is probably one of your most-used tools. Whenever you spend a lot of time working with a specific tool, it is worth to get to know it very well and learn how to use it efficiently.