Helm 3 is finally released. We can say goodbye to Tiller, but Helm 3’s changes do not stop there. Let’s continue exploring the other changes.
1. Saying Goodbye to Tiller
Removing Tiller in Helm 3 was a good decision. But to understand why it is good, we first need to understand the background that produced Tiller. Tiller was Helm’s server-side component (running on the Kubernetes cluster), and its main purpose was to let multiple different operators work on the same cluster. When Helm 2 was being developed, Kubernetes had no role-based access control (RBAC), so Helm had to control by itself who could install applications and where. Once RBAC was enabled in Kubernetes 1.6, this became simple. Helm no longer had to duplicate what Kubernetes already did, so Helm 3 removed Tiller entirely.
Tiller served as the core that maintained Helm’s application information and state. Helm 3 can obtain the same information directly from the Kubernetes API Server and render Charts on the client side. For Kubernetes, this approach is simpler and more native.
After removing Tiller, Helm’s security model also became simpler (using RBAC to control Tiller’s permissions in a production environment is very hard to manage). Helm 3 uses kubeconfig for authentication. The cluster administrator can set whatever level of permission control is required for an application, while everything else stays the same.
2. Okay, Besides Tiller, What Else Changed?
As mentioned earlier, removing Tiller was a big deal, but it was not the only one. Let’s look at the others.
2.1 Three-Way Merge Patch Strategy
Helm 2 used a two-way merge patch strategy. That is, when you wanted to perform any helm operation, it compared the latest chart package with the desired chart package configuration. The difference between the two packages determined which resources in Kubernetes should be adjusted. Sounds good, right? But it did not account for manual modifications to the application (for example, using kubectl edit). This would leave the application unable to roll back to its previous state, because Helm 2 treated the latest chart package as the latest state, and the latest chart package itself had not changed (we had only changed the application’s state in the cluster), so Helm 2 ignored the rollback of that change.
The three-way merge patch can solve this problem. How does Helm 3 do it? It simply takes the live state of the application into account as well (using three-way instead of two-way: the old configuration, the live state, the new configuration). For example, suppose you deployed an application:
| |
The replica count of this application was set to 3. Now, someone accidentally runs kubectl edit or:
| |
Then someone on the team notices that very_important_app has unexpectedly gone down and tries to run:
| |
In Helm 2, this operation would compare the old configuration with the new configuration and then generate an update patch. Since the person who made the mistake only changed the application’s live state (the old configuration was not updated). Helm will do nothing on rollback. Because the old configuration and the new configuration are no different (both have 3 replicas). So Helm does not perform the rollback, and the replica count stays at 0. At this point, you start to panic a little…
On the other hand, in Helm 3, the update patch is generated using the old configuration, the live state, and the new configuration. Helm finds that the old configuration has 3 replicas, the live state is 0, and determines that the new configuration expects to change it back to 3, so it generates an update patch to roll back. At this point, you are a little less panicked…
A similar process happens when upgrading with Helm 3. For example, some controller-based application (or something like a service mesh) injects content into Kubernetes objects deployed by Helm. When upgrading in Helm 2, the injected content will be removed. In Helm 3, because the live state is taken into account, the injected content will be preserved. Suppose we want to install Istio on the cluster. Istio injects a Sidecar into every deployment. Deploy with Helm:
| |
After installing Istio, your container definition looks like this:
| |
If you upgrade using Helm 2, you will get the following result:
| |
The Istio Sidecar will be removed because it is not in the configuration. Helm 3, however, will generate an update patch based on the old configuration, the live state, and the new configuration. Helm 3 will update the image to 2.1.0, and the live state also contains some extra configuration. In the end, upgrading with Helm 3 gives you what you want:
| |
The three-way merge patch update makes Helm upgrades more controllable and safer.
2.2 Secrets as the Default Storage
Helm 2 used ConfigMaps to store application information. In Helm 3, this changed to Secrets (with the secret type helm.sh/release) as the default storage. This brings some advantages and greatly simplifies Helm’s functionality. Helm 2 had to go through a series of operations to retrieve (and apply) the configuration. The configuration was encrypted, packaged, and stored in some keys or a ConfigMap. Helm 3 stores the configuration directly in a Secret, with no need for complex operations β just extract, decode, and use. Another advantage is that application names do not have to be unique across the cluster. The Secrets containing application information are stored in the Namespace where the application is installed. Therefore, in different Namespaces, applications can have the same name.
2.3 JSON Schema Validation for Chart Information
You can use JSON Schema to enforce validation of the values in a chart. With this feature, you can ensure that the values provided by users meet the chart package’s requirements. This creates more opportunities for collaboration between OPS and DEV (the OPS team can give DEVs more freedom), and can give better error messages when users set values incorrectly.
2.4 An Application Name Is Now Required
If no application name is provided, Helm 2 would generate one randomly; in Helm 3, it will report an error (if you still want to use a random name, you can add the β generate-name flag).
2.5 Helm Serve Removed
Not many people used helm serve anyway (it was used to run a local Chart Repository on your machine for development). Now helm serve has been removed. But you can still install it as a plugin.
2.6 No More Automatic Namespace Creation
When creating an application in a Namespace that does not exist, Helm 2 would create the Namespace automatically. Helm 3 follows the conventions of other Kubernetes tools and returns an error if the Namespaces do not exist.
