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.
Scope for Release Names are limited to Namespaces now
Release name scope is now limited to only that namespace where it is deployed. Previously, the release name should we unique across the cluster, but now it is limited to a particular namespace.
An example to make understanding better
Previous, if we want to deploy any service, say
mysql, we would be doing like this:
helm install stable/mysql --name mysql-develop --namespace develop
helm install stable/mysql --name mysql-qa --namespace qa
Now the same deployment can be achieved like this:
helm install stable/mysql --name mysql --namespace develop
helm install stable/mysql --name mysql --namespace qa
Secrets as default storage driver
Helm 2 used config-maps to store release information. In Helm 3, secrets are used instead as the default storage driver. Also, they are stored in the same namespace where the release is deployed. Previously, the release information was stored in the same namespace where tiller is deployed.
So what are the benefits of using secrets?
Helm 2 doesn’t store the release information directly, rather it performs a couple of encryption operations to store it in config-map. Also, at the time of retrieving those configs, helm has to re-perform those steps to decrypt that information. This whole process is simplied by having secrets in place. Helm 3 directly pull out the secrets, decrypt it and apply.
JSON Schema Chart Validation
A JSON Schema validation can now be forced upon chart values. It provides a schema which enforces a format over the values provided by the users. This helps in providing better error reporting if a user tries to use an incorrect set of values. This JSON Validation takes place when we run any of the following commands:
Release name is now required
Previously in Helm 2, the release name is provided by the flag
--name <release name> . In case the flag is not supplied, Helm automatically provides a random name to the chart.
But in Helm 3, release name is compulsory. It follows a format like:
helm install <chart-name> <release-name>. If no name is provided to a chart, it will throw an error. Eventually, you can also you
--generate-name if you want to auto-generate a random release-name for your chart.
Namespaces not created automatically
In Helm2, if you deploy a chart in a non-existing namespace, it will create the namespace automatically. This is not the case with Helm3. In Helm3, you need to create the namespace first in order to deploy a release in that namespace.
The Chart dependency management system moved from
Chart.lock. The dependencies, which earlier were provided in
requirement.yaml, are now provided in
serve command starts a local chart repository server that serves charts from a local directory. This has been removed in Helm3 version. If you still want to have a similar experience, you can have a look at ChartMuseum
As there are multiple enhancements in Helm3, the
apiVersion, which we specify in the
Chart.yaml file has bumped from
CLI Commands Renamed
Some CLI commands are also re-named in Helm3
helm delete is re-named to
helm uninstall. But
helm delete is still retained as an alias to
helm uninstall. Also, in Helm2 , we use the
--purge flag to remove the release configs also. In Helm3, this feature is enabled by default. To retain the previous behaviour, you can use the command
helm uninstall --keep-history.
helm inspect command is renamed to
helm fetch command is renamed to
I’ve covered mostly all the features that were introduced in Helm3. Still, If you have any doubts or queries, feel free to contact me at firstname.lastname@example.org.
Also, I would like to thank you for sticking to the end. If you like this blog, please do show your appreciation by giving thumbs-ups and share this blog and give me suggestions on how I can improve my future posts to suit your needs. Follow me to get updates on different technologies.