Hello readers, In this blog, I’ll be covering the differences between the two versions of Helm, i.e. Helm2 and Helm3. The internal implementation of Helm3 has changed considerably from Helm2. If you want to know about what helm is, you can refer to my previous blog on Helm: Package Manager for Kubernetes.

Going forward, let’s start with the differences:

Tiller is Removed

The most apparent change is the removal of Tiller. The server-side component, Tiller, is now removed.

Why was it required?

Tiller was the server-side component which is used to maintain the state of helm release. It also stores all the release information in a config-map for every release in the same namespace where tiller is running. This config-map is used by helm whenever we try to upgrade a particular release, where helm compares the new manifest with the already present configs.

Why was tiller removed then?

Tiller is used by Helm to deploy the Kubernetes object. Previously, when Helm 2 was released, Kubernetes does not support RBAC policies, hence by default, Helm takes the maximum permission to make changes in Kubernetes. This can cause security issues in the cluster if Helm has not been properly deployed. But after Kubernetes 1.6, RBAC is enabled by default, so there is no need for Helm to keep track of who is allowed to installs what, as the same job can now be done natively by Kubernetes and that’s why in Helm 3 tiller was removed completely. For knowing about possible security issues and how they can be solved, you can refer to this blog by bitnami.

Improved Chart Upgrade Strategy: Three-way strategic merge patch

Helm 3 changed the upgrade strategy from two-way to three-way strategic merge patch. Let us see what they mean.

Helm 2 Upgrade Strategy

Helm 2 used a two-way strategic merge patch. Let’s understand this is a simple way. When you deploy a release, it stores a config-map which contains the release configs. Now whenever you upgrade that charge, it compares the newly supplied manifest with the existing manifest. This sounds good, but here exist one problem.

So what’s the issue in two-way strategic merge?

The issue is that it does not consider the manual changes we have done using kubectl edit and when we upgrade the chart, it revert back those manual changes.

How is this resolved in Helm 3?

In Helm 3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch. So when we try to upgrade any existing chart, it also considers our manual changes.

#devops #tech blogs #devops #helm #helm2 #helm3 #kubernetes