One of the most important parts of upgrading to a new major release of Helm is the migration of data. This is especially true of Helm v2 to v3 considering the architectural changes between the releases. This is where the helm-2to3 plugin comes in.

It helps with this migration by supporting:

• Migration of Helm v2 configuration.
• Migration of Helm v2 releases.
• Clean up Helm v2 configuration, release data and Tiller deployment.

Setting up Helm v3

As we do not want to override Helm v2 CLI binary, we need to perform an additional step to ensure that both CLI versions can co-exist until we are ready to remove Helm v2 CLI and all it's related data:

Helm v3 development has hit a new milestone with the release of the first beta. This is an especially important milestone because it is the end of the effort to refactor Helm v3. The last of the intended breaking changes has landed. From this point on, Helm v3 is focused on bug fixes, stability, and preparing it for a stable release.

If you are interested in Helm v3 now is a great time to test it out. If you find issues please file an issue if one has not already been filed.

The Helm Client has long been available to download from Google Cloud Storage at the bucket https://kubernetes-helm.storage.googleapis.com. This bucket in Google Cloud has been used by Helm since before Kubernetes was part of the CNCF. The first release hosted on this bucket was Helm v2.0.0-alpha.5!

Google has long been gracious in providing funding for this location. Since Helm started using it, Helm (as part of Kubernetes) moved into the CNCF, and then moved out from under the Kubernetes umbrella, becoming a sister project to Kubernetes within the CNCF.

This is the seventh and final part of our Helm 3 Preview: Charting Our Future blog series. Read our previous blog post on library charts here.

Helm 3.0.0-alpha.1 is the foundation upon which we'll begin to build the next version of Helm. The features shared over the last few weeks were some of the big promises we made for Helm 3. Many of those features are still in their early stages and that is OK; the idea of an alpha release is to test out an idea, gather feedback from early adopters, and validate those assumptions.

This is part 6 of 7 of our Helm 3 Preview: Charting Our Future blog series on library charts. You can find our previous blog post on the Helm chart dependencies here.

Helm 3 supports a class of chart called a "library chart". This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart's templates can only declare define elements. Globally scoped non-define content is simply ignored. This allows users to re-use and share snippets of code that can be re-used across many charts, avoiding redundancy and keeping charts DRY.

This is part 5 of 7 of our Helm 3 Preview: Charting Our Future blog series about chart dependencies and some subtle differences between Helm 2 and Helm 3. (Check out our previous blog post on release management here.)

Charts that were packaged (with helm package) for use with Helm 2 can be installed with Helm 3, but the chart development workflow received an overhaul, so some changes are necessary to continue developing charts with Helm 3. One of the components that changed was the chart dependency management system.

This is part 4 of 7 of our Helm 3 Preview: Charting Our Future blog series on release management. (Check out our previous blog post on the Helm chart repositories here.

In Helm 3, an application's state is tracked in-cluster by a pair of objects:

• The release object: represents an instance of an application
• The release version secret: represents an application's desired state at a particular instance of time (the release of a new version, for example)

A helm install creates a release object and a release version secret. A helm upgrade requires an existing release object (which it may modify) and creates a new release version secret that contains the new values and rendered manifest.

This is part 3 of 7 of our Helm 3 Preview: Charting Our Future blog series, discussing chart repositories. (Check out our previous blog post on the gentle goodbye to Tiller here.)

At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index.yaml file and some packaged charts.

This is part 2 of 7 of our Helm 3 Preview: Charting Our Future blog series. (Check out our previous blog post on the history of Helm here.)

During the Helm 2 development cycle, we introduced Tiller as part of our integration with Google's Deployment Manager. Tiller played an important role for teams working on a shared cluster - it made it possible for multiple different operators to interact with the same set of releases.

On October 15th, 2015, the project now known as Helm was born. Only one year later, the Helm community joined the Kubernetes organization as Helm 2 was fast approaching. In June 2018, the Helm community joined the CNCF as an incubating project. Fast forward to today, and Helm 3 is nearing its first alpha release.

In this series of seven blog posts over the next four weeks, I'll provide some history on Helm's beginnings, illustrate how we got where we are today, showcase some of the new features available for the first alpha release of Helm 3, and explain how we move forward from here.