Helm v3: A tillerLess strategy

Published in

FAUN — Developer Community 🐾

7 min readJan 21, 2020

Helm (a tiller or wheel & any associated equipment for steering a ship or boat) is a package manager for Kubernetes. It was inspired by the Homebrew project & helps developers to easily package & distribute complex microservices that run on the Kubernetes platform.

Some history…

2015: Helm was first introduced at KubeCon (Kubernetes Developer Conference) by a company called Deis (acquired by Microsoft)
2016: During the same time, GCS was trying to solve a similar problem with Kubernetes Deployment Manager, so Helm was merged into the Kubernetes project in early 2016. The merging of these two projects resulted in Helm v2
2018: Seeing a quick raised in its popularity, Helm was later promoted to a fully-fledged CNCF project in 2018
2019: Helm v3 was released

Helm v2 introduced a server-side component called Tiller to manage charts. A Helm chart is a packaging format that contains all of the resource definitions necessary to run an application, tool, or service on Kubernetes.

Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.

Although it worked well for a while, the rapid evolution of Kubernetes meant that Helm had a lot of catching up to do. Helm v2 was inefficient in many ways: security, version dependencies & two-way merge strategy, etc., to name a few.

The Helm community took note of these drawbacks & released Helm v3; which primarily focuses on optimization (security & performance).

This article will help you understand the changes that went into Helm v3 & later we will discuss the steps to migrate a chart from Helm v2 to Helm v3.

What has changed in Helm v3?

Here are all the major changes introduced in Helm v3

DEPRECATION OF TILLER

Drawback
Tiller made it easy for multiple users to interact with the same set of releases when using a shared Kubernetes cluster.
Helm v2 followed a more permissive default security config which grants a user a broad range of permissions. Now, since role-based access controls (RBAC) has been enabled by default in Kubernetes, locking down tiller for use in production environments has become more difficult to manage.
Secondly, Tiller’s primary goal of storing the state information could be accomplished by directly interacting with the Kubernetes API server.
Enhancement
Keeping the above two points in mind, the decision we made in Helm v3 to completely remove Tiller. With Tiller gone, the security model for Helm is radically simplified

2. IMPROVED MERGE STRATEGY

Drawback
Helm v2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart’s manifest against the proposed chart’s manifest. It compared the differences between these two charts to determine what changes needed to be applied. If changes were applied to the cluster out-of-band (such as during a kubectl edit), those changes were not considered. This resulted in resources being unable to roll back to its previous state.
Enhancement
In Helm v3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, & the new manifest when generating a patch.

3. NAMESPACED RELEASE NAMES

Drawback
In Helm v2, the release information was stored in the same namespace as tiller. In the case where the name was used by a release, no other release could use the same name (even if it’s deployed to a different namespace).
Enhancement
In Helm v3, information about a particular release is now stored in the same namespace as the release itself.
With this greater alignment to native cluster namespaces, the helm list command no longer lists all releases by default. Instead, it will list only the releases in the namespace of your current Kubernetes context.

4. SECRETS AS THE DEFAULT STORAGE DRIVER

Drawback
Helm v2 uses Kubernetes ConfigMaps to store release information. Not a good data store if the release contains sensitive information.
Enhancement
In Helm v3, Kubernetes Secrets are used as the default storage driver.

5. CONSOLIDATION OF DEPENDENCIES

Drawback
In Helm v2, dependencies were listed in a separate file calledrequirements.yaml file
Enhancement
In Helm v3, the dependency is expressed the same way, but now within theChart.yamlfile.

6. SUPPORT FOR LIBRARY CHARTS

With Helm v3, a new class of charts called “library charts” has been introduced. These charts contain templates with define elements that can be re-used & shared across many other charts. They don’t have a release artifact & avoid redundancy & keeping charts DRY.

Library charts are declared in the dependencies directive in Chart.yaml, & are installed & managed like any other chart.

7. API VERSION BUMP FROM v1 TO v2

Due to points #5–6, Helm clients that understood v2’s packaging format now don’t understand these new features introduced in v3. Hence, the apiVersion in Chart.yaml is bumped from v1 to v2

8. RENAMING COMMANDS

helm delete is re-named to helm uninstall
helm inspect is re-named to helm show
helm fetchis re-named to helm pull

How do I migrate from Helm v2 to v3?

The recommended data migration path is as follows:

Backup Helm v2 release data & configuration
Migrate Helm v2 configuration to v3
Migrate Helm v2 releases to v3
Validate that releases are managed by Helm v3
Cleanup Helm v2 data

The above migration process is automated by the Helm v3 2to3 plugin if you want to migrate all your charts from v2 to v3 at once. Let’s see below, one of the methods to perform the chart migration.

Migrate charts from v2 to v3 using Helm2To3 utility

Install Helm v3 for macOS (for other distros please use this link)

# DOWNLOAD HELMv3 TAR FILE
$ wget https://get.helm.sh/helm-v3.0.2-darwin-amd64.tar.gz# EXTRACT BINARY
$ tar -xvzf helm-v3.0.2-darwin-amd64.tar.gz# MOVE BINARY TO OS PATH
$ mv darwin-amd64/helm usr/local/bin/helm3# VERIFY INSTALLATION
$ helm3 version

Install helm-2to3 plugin

# INSTALL HELM PLUGIN
$ helm3 plugin install https://github.com/helm/helm-2to3# LIST INSTALLED PLUGINS
$ helm3 plugin list# RUN HELMv3 PLUGIN
$ helm3 2to3

Migrate Helm v2 configuration to v3

# RUN CONFIG MOVE IN DRY-RUN MODE
$ helm3 2to3 move config -h
$ helm3 2to3 move config --dry-run# MOVE HELMv2 CONFIG TO HELMv3
$ helm3 2to3 move config

Convert Helm v2 releases to v3

# RUN CONVERT IN DRY-RUN MODE
$ helm3 2to3 convert -h
$ helm3 2to3 convert <Release-Name> --dry-run# CONVERT HELMv2 RELEASE TO HELMv3
$ helm3 2to3 convert <Release-Name>

List Helm v2 & v3 releases (Note that the Helm v2 releases are not yet removed)

# LIST HELM v2 RELEASES
$ helm list -n <Release-Name># LIST HELM v3 RELEASES
$ helm3 list -n <Release-Name>

Clean up Helm v2 data

# RUN HELMv2 DATA CLEANUP IN DRY-RUN MODE
$ helm3 2to3 cleanup -h
$ helm3 2to3 cleanup --dry-run# CLEANUP HELMv2 DATA
$ helm3 2to3 cleanup# TO DELETE HELMv2 RELEASE DATA IMMEDIATELY AFTER CONVERSION
$ helm3 2to3 convert <Release-Name> --delete-v2-releases

NOTE: The cleanup command will remove the Helm v2 Configuration, Release Data, & Tiller Deployment. It cleans up all releases managed by Helm v2. It will not be possible to restore them if you haven’t made a backup of the releases. Helm v2 will not be usable afterwards.

What next?

Now that the migration to v3 has been complete, for any new charts (or existing charts in a repository like git) that you may want to manage using Helm v3, remember to follow the steps below

Change the apiVersion in Chart.yaml to v2
Move dependencies from requirements.yaml to Chart.yaml
Set alias for Helm v3 alias helm=helm3 OR remove Helm v2 binary
Use Helm v3 commands to install/upgrade/list/delete charts

# INSTALL
$ helm3 install <RELEASE-NAME> <CHART-LOCATION> \
             --namespace <NAMESPACE>
 
# UPGRADE
$ helm3 upgrade <RELEASE-NAME> <CHART-LOCATION> \
             --namespace <NAMESPACE>
 
# LIST
$ helm3 list --filter <RELEASE-NAME> \
             --namespace <NAMESPACE>
 
# DELETE
$ helm3 uninstall <RELEASE-NAME> \
             --namespace <NAMESPACE>

Although Helm v2 is going to stick around for a while, the support is going to end EOY 2020. There will be no more security patches & bug fixes for Helm v2 after this date. So plan early & make the move to Helm v3.