Upgrading Helm v2 to Helm v3 on Windows

7 min readJan 3, 2020

Some changes you must know about before getting started.

After a 60 day break from working on all things #DevOps, I wanted to jump back in by refreshing my local environment. While spinning things up, I noticed Helm v3 was released back in November 2019.

After an internet search, I found this:

Some of my takeaways are…

  • Tiller has been removed. This is huge because as you saw in a previous post, managing RBAC permissions can get a bit out of hand. From the Helm website listed above:

With role-based access controls (RBAC) enabled by default in Kubernetes 1.6, locking down Tiller for use in a production scenario became more difficult to manage

  • A 3-way strategic merge patch has been implemented over the former 2-way. This means Helm will keep track of the original manifest, the live state, and the new manifest. This will alleviate a sticky situation when you try to rollback after making a live change.

In Helm 2, it would generate a patch, comparing the old manifest against the new manifest. Because this is a rollback, it’s the same manifest. Helm would determine that there is nothing to change because there is no difference between the old manifest and the new manifest.

  • Release names are now scoped to the namespace the release is deployed in, whereas before you would have to basically ask the tiller service.

#1 Tiller was removed so it made sense for the release names get tracked at the namespace level.

#2 With the moving the release names to the namespace level, you can now have the same release name in multiple namespaces.

  • Secrets are now the default storage driver, as opposed to the previous ConfigMaps.
  • Helm import path changes for Golang projects from k8s.io/helmto helm.sh/helm/v3.
  • Chart apiVersion bumped to v2 in Chart.yaml file.

Please review all the changes and my summary doesn’t list every single change.

Assessing the current state of things

As you are getting started, it would be good to dig up your documentation or take some quick notes about the state of your environment.

Some items to take note of are your Chart and requirement.yaml files, as well as tiller because you will be modifying these.

Back things ups, twice even, and pair program. Start with your Helm configuration path. Mine defaulted to $HOME\.helm

Check out your list of releases.

helm list --tiller-namespace <tiller namespace>
Using an older version of helm to verify my releases

Get your repos in order.

helm repo list
more useful information

How to migrate to V3

The rest of this article describes work that is destructive and is meant for testing purposes only.

We will need to complete the following:

  • Migration of Helm v2 configuration. This essentially is updating the helm executable and configuration to Helm v3.
  • Migration of Helm v2 releases. This is updating your releases to v3, along with your charts and requirements.yml files.
  • Clean up Helm v2 configuration, release data and Tiller deployment.

As with everything that changes, be sure to backup EVERYTHING!

Step 0. Install Helm v3

Upgrade helm. Don’t worry, you can always download v2 and use your old manifests if you need to.

choco upgrade kubernetes-helm 
upgrade helm

Step 1. Migration of Helm v2 Config

Install the helm 2to3 plugin

Turns out the team at Helm has built us a plugin to get us going.

helm plugin install https://github.com/helm/helm-2to3
An error


After installing, you might receive an error. I’m going to verify things are actually broken by trying these 2 commands.

helm plugin list
Looks like it’s installed
helm 2to3 move config --dry-run
Looks like I don’t have the right files, probably because of a failed installation

Because a lot of these tools are set up for Linux or Mac, or even a bash shell, things don’t always work out on Windows. To resolve the issue, download the Windows files from here:


Extract the 2to3.exe file to:

C:\Users\<your user name>\AppData\Local\Temp\helm\plugins\https-github.com-helm-helm-2to3\bin\

Please note, you might have to create that bin parent folder. You can also customize this path by setting certain environment variables.

After you place the file inside the directory, try it again

helm 2to3 move config --dry-run

If things look good and you are ready to take the plunge, do it for real.

helm 2to3 move config

As you run these commands, take a look at the console. You will see the various directories helm needs along with some other useful information.

helm version

Check your plugins

Ensure all your plugins work. Remove and reinstall your plugins as a first step measure, and if they still don’t work, check the code repository to see if there are any updates.

I don’t have any plugins except the 2to3 plugin, but that was set up for v2.

Remove your local repositories

It is also recommended to remove and re-add your local repositories.

helm repo list
helm repo remove <repository NAME>
Removing my repositories
helm repo add <repository NAME> <URL>

You don’t need to add the helm local server because helm serve has been removed.

After you re-add all of your repositories it will be time to update.

helm repo update

So far so good!

Step 2. Migration of Helm v2 Releases

This step is so that when you run the new helm v3, you can see all your deployed releases and not rely on tiller anymore.

helm list --namespace <any namespace where you have a release>
Empty list

Since we have only upgraded helm and not the releases, nothing shows up.

helm 2to3 convert --dry-run <release NAME> --tiller-ns <tiller namespace>
Converting your releases to helm v3

When you feel you are ready, let’s do it for real.

helm 2to3 convert <release NAME> --tiller-ns <tiller namespace>

Let’s see if your release shows up now.

helm list --namespace <any namespace where you have a release>
My Spinnaker release now shows up

Repeat for all of your releases.

Update your charts

The best thing about this upgrade is you don’t have to edit your existing charts right away. Helm v3 still understands the original v1 api format but it is recommended to consolidate your requirements.yaml file into your Chart.yaml and upgrade to v2 of the api.

Chart.yml using the v1 api
requirements.yaml using the v1 api
Chart.yaml updated to the v2 api with dependencies included

Step 3. Clean up the Helm v2 configuration

When everything is up and running and you are ready to remove your helm v2 instance, please proceed.

helm 2to3 cleanup --dry-run -tiller-ns <tiller namespace>
That seems correct to me

For real this time.

helm 2to3 cleanup -tiller-ns <tiller namespace>
Successfully removed my tiller instance

I also created a namespace specifically just for tiller so I had to get rid of that as well.

kubectl delete ns airwave-tiller

You know what else? So is this story because you are done! Welcome to helm v3.

A quick tip, you can type in helm to see the various env variables used to customize your installation.

Thanks for reading and keep at it!