Helm, like many other softwares, has been evolving through the years. Most of the time, developers try not to introduce any breaking changes with new versions of their tools, sometimes it’s better not to support the old ways of working and redesign things from scratch.

A famous example of that is Python, which to this day is used broadly in versions 2 and 3. This is partly because many useful libraries have not yet migrated to the latest version forcing developers to stick with an older version.

Helm is no exception. Even though it is a young technology, it has been redesigned a couple of times. Despite having a huge base of users, there was a decision to change its architecture and slightly modify an API to make it into a better product.

In this course, version 3 of Helm will be used, but please be aware that the previous one is still popular and can be found in many projects. Let’s look at the most important changes between these two versions.

Removal of Tiller

Tiller was an essential part of Helm right from the beginning. It was an application that was acting as a server, which was consumed by command-line clients. Usually, it was installed inside a Kubernetes cluster, but could be run locally as well.

Tiller was an entry point for each client (e.g., CI/CD pipeline, developers, etc.) that wanted to manage a cluster using Helm. Whenever a client wanted to upgrade a chart, get information about a release, or anything else, it communicated directly with a Tiller which then interacted with the Kubernetes API.

Its main purpose was to have a single place where information about all the previous Helm releases could be stored so that all the clients that were connected to the same cluster could have the same history of releases.

Get hands-on with 1400+ tech skills courses.