The Helm Team is proud to announce the first stable release of Helm 3.
Helm 3 is the latest major release of the CLI tool. Helm 3 builds upon the success of Helm 2, continuing to meet the needs of the evolving ecosystem.
Helm 2.15.0 was released last week. The 2.15.0 release of Helm introduces several improvements to helm test. Several commands - helm search, helm repo list, and helm install - received the --output flag for machine-readable output.
In addition to these new features (and many more!), many bugs and edge cases in Helm continue to fixed by members of the community. Several parts of the codebase have been refactored for easier maintainability, usability, and better testing.
As Helm moves towards Helm 3's first release, Helm 2 is now transitioning into "maintenance mode". Helm 2.15.0 will be the final feature release for Helm 2.
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:
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.