Making the Move to Helm 3
With the release of Helm 3, the project is keen to have users migrate off Helm 2 as quickly as possible. The combination of productivity and usability improvements, improved security and backward compatibility in Helm 3 mean that migration will generally be straightforward.
“If you have Helm release on your Kubernetes cluster, you can convert them from Helm 2 to Helm 3 and just pick it up,” Lachlan Evenson, principal program manager on Azure Container Compute and release lead for Kubernetes 1.16 told the New Stack. “We even alias the existing operational verbs to the new verbs, so that people can have that seamless experience and migrate. The intent is that we get everybody over to Helm 3 as quickly as possible.”
There is one caveat to moving to Helm 3 if you use a Horizontal Pod AutoScaler; the new three-way merge that preserves sidecars when you use a Helm Chart to update a release also sets the number of replicas back to whatever is defined in the chart, so check that any charts you use that offer HPA don’t set the numbers of replicas. The previous behavior was a bug where Helm 2 differed from what Kubernetes itself would do, but in a way that turned out to be useful.
Plug-In and Go
There are two options for moving from Helm 2 to Helm 3. You can migrate everything from Helm 2 to 3 (and there’s a 2to3 plugin to help with that), which means Helm 3 takes over managing existing Helm 2 releases. You can think of that as live migration, IBM senior software engineer and Helm core maintainer Martin Hickey explained to us.
“This is where you’re looking at your cluster and saying ‘I want to move over to Helm 3 today but I don’t want to lose all my releases.’ The plugin moves the state information into the new state information location, which means pulling across any plugins you’ve installed, although there’s a few little exceptions to it. What the plugin does is it maps across those releases and stores them in the Helm 3 format, but it doesn’t touch your Kubernetes objects that have been deployed by that release. It works seamlessly. It also has a cleanup capability which will remove all the Helm 2 state for the release information, without touching the Kubernetes objects, and it will remove Tiller for you.”
If you use the cleanup option in the plugin, you won’t be able to go back to Helm 2, so make sure you take backups first and use the –dry-run flag to check the releases will be converted correctly.
The other option is the rather ominously-named ‘strangler pattern’ where you phase out Helm 2 gradually because the compatibility means that Helm 2 and Helm 3 can manage the same cluster without problems, as long as you put the Helm 3 binary in a different folder in your path or rename it to helm3.
“You have your Helm 2 and Helm 3 tree, managing the same cluster and over time, every new deployment you do, you use Helm 3 and over time you strangle or phase out the Helm 2 releases. Eventually, you come to the point where there are no longer any Helm 2 releases deployed and you’re on Helm 3,” Hickey explained.
“That works quite well because of the big architectural changes and the infrastructure changes we’ve done. Basically, your Helm state information and configuration information are in a separate directory structure for Helm 2 and the release data that’s stored in the cluster is stored differently, so they won’t walk the top of each over.”
Namespaces are different for releases managed by Helm 3 because they’re no longer in the default kube-system namespace, and if you were using Secrets for Helm 2 configuration (not the default option), they were also in the Tiller namespace but Helm 3 Secrets are stored in the user namespace, with the releases.
If you’re used to Helm 2 and you’re installing Helm 3 on a new system you don’t have to worry about migrations, but you do need to know that it doesn’t set up any repos by default. That’s part of a wider change to how you get charts.
The Future of Chart Distribution
To encourage organizations to move to Helm 3, Helm 2 is moving into maintenance mode, with Helm 2.15 as the final feature release. Bug fixes will continue for six months and security patches will continue for a full year after the Helm 3 release date (ending Nov. 13, 2020). The GitHub charts repo is being deprecated on the same timeline.
That’s partly about moving off Google Cloud storage that’s no longer appropriate for a Cloud Native Computing Foundation project (and not available in China), and partly about moving away from a centralized store for charts (that doesn’t actually include all charts) to a federation model.
Instead, charts are now accessible through Helm Hub, which is now easier to search (and if you want to make your own internal charts easier to find you can run your own Helm Hub). The stable and incubator chart repos were never really intended to become the single source for charts and they will be delisted from Helm Hub on May 13, 2020, when Helm 2 starts getting just security fixes.
“The Helm Hub exists to enable the federated model of charts now, and Helm 3 can search Helm Hub for charts and load them,” Codecademy Senior DevOps Engineer and Helm project maintainer Scott Rigby told us.
As the number of charts grows, more chart maintainers may want to publish their charts to a Helm repo hosted on GitHub pages; there’s already been some experimentation automating that with GitHub Actions. The Chart Releaser tool will support using GitHub Actions to turn GitHub repos into Helm Chart repos soon; it’s has been waiting on GitHub Actions being generally available, Rigby said.
In the longer term, the work done to have Docker registries support Cloud Native Application Bundles (CNAB) will also allow OCI registries to serve Helm chart.
“For Helm 2, if you want to store charts you would store them in a Helm repo; that’s an HTTP, HTTPS web server that would serve up the tarballs,” Evenson explained. The community didn’t want another repo to maintain, especially one with older authentication mechanisms. The OCI distribution specification v2 includes multiple media types, including Helm charts, which is a better match for the Helm 3 security posture.
“We have the leverage of all the security plugins and authorization models in that tooling, not just the basic authentication we had with Helm 2. We want to make it a secure experience, and as a side effect it’s now integrated into all your other tooling. You can now store your own charts in the same space so it’s just a nice integrated experience. We have great container repos: how about we store our other artifacts in there.”
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature image by Erda Estremera on Unsplash.