5 reasons to use Helm charts in Kubernetes

Kubernetes is a big platform to absorb. It has a rich resource & networking model. In many ways it is a miniature version of a fully fledge cloud provider, abstracting the underlying cloud provider.

That is my excuse for postponing addressing Helm for such a long time. Until today.

I’ll look at why you should use it to install third party solutions, but also to package and deploy your own custom built solutions.

Without further ado, let’s look at five (5) reasons why you want to use Helm charts in Kubernetes.

Easy way to install third party solutions

Helm is Kubernetes equivalent to Linux Apt-Get / Yum: a packaging tool.

This might sound a little odd: aren’t containers the packaging unit?

Containers are a wonderful at packaging runtime environments in order to run one or few processes in isolation.

A Kubernetes solution is typically composed of more than a container. For instance, it can be composed of:

It is therefore a no-brainer to use a packaging solution to manage all those resources as a single unit.

As with other packaging solution, Helm allows us to manage a package as one thing instead of its many parts we often won’t have the knowledge to manage.

Helm also allows to manage the lifetime of those components as a whole. Tracking which components to delete vs update during an upgrade is therefore trivial.

Managing multiple resources

Software engineering really consist of an handful of patterns. For instance, “Add a level of indirection” is responsible for a myriad of different solutions such as programming language, network protocols, etc. .

Another of those key patterns is composition. The power of composition cannot be overestimated. It is what allow us to handle complexity by breaking it down into smaller and smaller pieces until the individual piece can be reasoned about.

Helm gives us an intermediate level of components. A big cluster (i.e. ~100 nodes) can run hundreds of containers. If we only had two levels, i.e. the cluster and the hundreds of components, the workload would get out of hands quickly.

An Helm chart aggregates multiple Kubernetes resources. It can also depend on more charts so we can have a hierarchy of packages.

This gives us a macro view of a cluster. That is a level between the cluster itself and the single components running on it.

Atomically installing / upgrading / deleting multiple resources

Installing a complex solution would require us to deploy multiple resources.

This would likely require an install document to follow.

Upgrades would be even more challenging. Depending on the original and target version of the solution, we would have different operations to perform, e.g. deleting deprecated resources.

Finally, deleting a solution and making sure that no orphan resources are left behind can be challenging on a cluster running multiple solutions and hundreds of resources.

Helm charts allows us to manage the lifecycle of releases as units.


Helm allows us to version releases within a cluster.

We can therefore bind our CI / CD releases with Helm release revisions.

It is easy to see what versions of a charts are running on a cluster.

Parametrized deployments

Here is what we consider a killer feature for Dev Ops.

A typical task in Dev Ops is to reuse components to deploy to different environments. For instance, we would like to deploy the same containers in dev & production, but probably register them on different domain names and pointing to different external services (e.g. databases).

Kubernetes yaml specs files do not have a parameter concept. We can cobble one together, typically by doing token replacement. This has limitations and doesn’t scale very well.

Helm solves this issue beautifully with its template system and values file.

It becomes easy to reuse the same charts to deploy to different environment or even different solutions.


Here were 5 quick reasons on why you should use Helm with both third party and home-grown solutions.

Helm allows us to manage complex solutions as units. Those units (i.e. Helm Releases) can be parametrized and versioned. Their lifecycle can be managed as units.

This gives us the ability to scale operations on a cluster.

Update (07-11-2017): See Authoring a Helm Chart on Kubernetes / AKS – Getting started on how to author Helm Charts.

Leave a comment