Helm 3: Top Five Improvements
Check out some of the changes that have been made in the latest Helm release, from getting rid of Tiller to small but crucial command changes.
Join the DZone community and get the full member experience.Join For Free
Helm is a package manager for Kubernetes. One month ago, the third major version was released and quite a few interesting changes took place. In this blog post, let me walk you through the five which I find the most crucial.
1. No Tiller
Helm finally got rid of its server component, Tiller. Now, it’s completely agentless. Tiller was this small application running on Kubernetes that listened for Helm commands and handled the real work of setting up Kubernetes resources.
This change is definitely the biggest improvement in Helm 3. Why was Tiller an issue? First of all, Helm should be perceived only as a templating mechanism over Kubernetes configurations. So why the heck would you need some agent running on your server?!?
Tiller was also an issue because it required
cluster-admin ClusterRole for its creation. So, let’s say you want to run your Helm application on a Kubernetes cluster started in Google Cloud Platform. You start a new GKE cluster, you want to initialize Helm with
helm init, and boom…it fails. That happens because, by default, you don’t have admin rights assigned to your
kubectl context. Now you need to search for the magic command that assigns you admin rights and then, at this point, you already start wondering if Helm was really such a good choice.
You may also enjoy: Steering the Wheel of Your App Deployment With Helm
Tiller was also an issue because it used different access rights than what you had configured in your
kubectl context. Therefore, you might have been able to create an application using Helm which you’d not be allowed to create with the use of
kubectl. That smells like a security hole.
Luckily, when the whole Tiller is gone, Helm is a client-only tool. That fact has three important consequences:
- Helm uses the same access rights as defined in your
- You don’t initialize Helm with
- Release names are now scoped to the namespace
Helm 3 is what it should always have been: just a tool to perform operations on Kubernetes API. So now, if you can do something with the pure
kubectl command, you are also allowed to do it with
2. Distributed Repositories and Helm Hub
Helm command can install charts from remote repositories. Before Helm 3, it always used the predefined central repository, but you could also add other repositories. From now on, Helm moved its repository model from centralized to distributed. That means two critical changes:
- The predefined central repository was removed
- Helm Hub (platform for discovering distributed chart repositories) was added to
To understand it better, let me give you an example. Before Helm 3, if you wanted to install a Hazelcast cluster, you could execute the following command.
Now, it wouldn’t work. You cannot install anything without adding a remote repository first. That’s because there is no longer one central and predefined repository. In order to install a Hazelcast cluster, you need first to add its repository and then install the chart.
The good news is that the Helm command is now able to look for charts directly in Helm Hub. For example, if you wanted to find in which repository you can find Hazelcast, you could do it by executing the following command.
The command above lists all distributed repositories registered in Helm Hub which contains “hazelcast” in the chart name.
Let me ask you an interesting question. Is removing a central repository progressive or regressive? There are two perspectives. The first one is what it all means for chart maintainers. For example, we maintain Hazelcast Helm charts and each change meant propagating the same change to the central repository. This additional effort resulted in a fact that a lot of Helm charts were not well-maintained in the central repository. The situation is similar to what we all experience with the Ubuntu/Debian package repositories. You can use the default repository, but it usually contains old package versions.
The second viewpoint is the perspective of chart’s users. For them, it’s actually slightly more difficult to install a chart now, but on the other hand, they can be sure that they install the up-to-date chart from the main repository.
3. JSON Schema Validation
Starting from Helm 3, chart maintainer can define JSON Schema for input values. This is an important improvement, because so far you could put anything you wanted in
values.yaml and the installation may have ended up with incorrect results or some hard-to-read error messages.
For example, let’s say you’d give a string instead of a number for the
port parameter. Then, you’d receive the following error.
You have to admit it’s hard to analyze it to understand the issue.
What’s more, Helm 3 added by default the validation against OpenAPI for Kubernetes objects, which means that requests sent to Kubernetes API are checked if they are really correct. This is a great benefit, especially for chart maintainers. We already discovered and fixed an issue we had in our Hazelcast Helm chart.
4. Helm Test
Helm test was slightly improved. Slightly, but it may actually encourage maintainers to write Helm tests and users to execute the
helm test command after every chart installation. The thing is that before Helm 3, testing was somehow weird.
- A test was executed as a
Pod(as if it was supposed to be running all the time!); now you can define it as a
Job(which makes much more sense)
- Test Pods were not automatically removed (unless you used the magic flag
--cleanup), so by default, without any tricks, you couldn’t execute
helm testmore than once for the given release; luckily, test resources (Pods, Jobs) are now automatically removed
I know that, after all, you could live with the old testing style and just use Pods and always execute
helm test --cleanup, but you have to admit, these are all nice improvements!
5. Command-line Syntax
Last but not least, Helm command syntax changed a little bit. From the good side, in my opinion, all changes are for better. From the bad side, they are not backward-compatible, so now when writing steps of how to install something using Helm, you always need to explicitly mention if the given command is for Helm 2 or for Helm 3!
For example, starting with
helm install. Now, the release name is a mandatory parameter, while in Helm 2 you could skip it and the name would be auto-generated. To achieve the same in Helm 3, you need to add the parameter
--generate-name. So, the standard installation using Helm 2 looked as follows:
While in Helm 3, you need to execute the following.
The change is small, the change is for better, but the change is also non-backward compatible.
The other very good change is that to delete your Helm release, you don’t have to add the
--purge parameter. Simple
helm uninstall <release-name> deletes all related resources.
There were some more minor changes. Some commands were renamed (and luckily aliased with old names), some others were removed (like
helm init which is not needed anymore). You can read about all Helm command syntax changes here.
Well done Helm! Version 3 brings the Helm tool to the next level. As a user, I love that Helm is now the client-only tool. As a chart maintainer, I love Helm Hub and the distributed-first repository approach. Keep on going and I hope we’ll see more interesting changes in the future!
Published at DZone with permission of Rafał Leszko. See the original article here.
Opinions expressed by DZone contributors are their own.