On October 15th, 2015, the project now known as Helm was born. Only one year in, Kubernetes Helm is part of the CNCF, and is marching toward the v2.0.0 release. And in every sense of the word, it is now a community-driven project. But the circumstances behind the creation of Helm read like a script for a Silicon Valley tech comedy.
This is the final Helm alpha release for the 2.0.0 development cycle.
WARNING: This release is not backward compatible. We try hard to avoid compatibility breaks because we know it is an inconvenience to you. But we made a tough call: It is better to correct some of our design flaws now than force everyone to "live with them" for the entirety of the 2.0.0 lifecycle. We apologize for the inconvenience, and we don't plan on any other compatibility breaks between now and 2.0.0.
As always, we want to give a big ❤️ to the community, which has continued to find bugs, submit issues, fix things, and participate in conversations. If you'd like to be a part of the community, we invite you to join the Kubernetes Helm Slack channel, drop in on a Thursday Developer Call, and jump in on the GitHub issue queues.
Please let us know if you find any issues with those guides. We want Helm installation to be an easy and reliable process.
When upgrading to a new version of Tiller, we recommend using kubectl to delete the old one: kubectl delete deployment --namespace kube-system tiller-deploy. This will not delete your releases. From there, running helm init will update you to the latest.
For Mac OSX
We consider Alpha.5 to be feature complete. The developers are now working on fixing bugs, improving stability, and building some great docs. This is a great time to jump in.
Our next release will be v2.0.0-beta.1. And we will be rolling out betas until we feel like the tool is ready for production use.
Helm 2.0.0-alpha.4 is the penultimate Helm Alpha release. This new version introduces four major changes:
ConfigMap storage is now the default backend. When you create a release with Helm, the release data will be stored in config maps in the kube-system namespace. This means releases are now persistent.
helm status got a much-needed overhaul, and now provides lots of useful information about the details of a release.
The Tiller server now checks the apiVersion field of manifests before loading a chart into Kubernetes. Now, for example, a chart that uses PetSets will stop early if it detects that the Kubernetes installation does not support PetSets.
Helm can now cryptographically verify the integrity of a packaged chart using a provenance file. To this end, helm package now has a --sign flag, and several commands now have a --verify flag.
In addition to these, the Helm community has added numerous improvements and bug fixes, including:
Fixing a bug that prevented some installations of Alpha.3 from executing helm list
Limiting the length of a release name
Adding an icon: field to Chart.yaml
Improving helm lint and helm upgrade
During this cycle, the Kubernetes Helm community surpassed 50 code contributors, many of whom have contributed multiple PRs! We cannot thank you enough. ❤️
This is the second release of Helm that includes pre-built client binaries.
To get started, download the appropriate client from the release, unpack it, and then initialize Helm:
This will configure your local Helm, and also install and configure the in-cluster Tiller component.
The next release, Alpha.5, marks the last major feature release before we focus on stability. You can expect to see helm rollback implemented, along with better version support, and the addition of a dependencies: section in Chart.yaml.
After Alpha.5, the Helm team will focus on closing bugs and improving stability as we sail toward a Helm 2.0.0 final release.
Helm v2.0.0-Alpha.3 has many new features and improvements. It marks our biggest release yet. The Helm team owes a tremendous debt of gratitude to our outstanding community, which has been a source of ideas, issues, fixes, features, and encouragement. Thank you!
Alpha.3 also includes the first set of released binaries which means you no longer have to compile the project to start kicking the tires. Check out "Getting Involved" section for details.
The headliner features are:
A new helm upgrade command can upgrade releases in place. We suggest using Kubernetes Deployments for maximum impact.
A vastly improved helm status command shows you information about the current state of your releases.
Helm now has commands for getting information about a release using helm get, helm get values, helm get hooks, and helm get manifest.
By default, releases are still stored in memory. But they may now optionally be stored in Kubernetes ConfigMaps instead. In subsequent releases, ConfigMaps will become the default.
The new helm inspect command allows users to preview chart information before installing a chart: helm inspect kube-charts/alpine-0.1.0
Tiller now installs into the kube-system namespace, but can install charts into any namespace it has write access to.
Helm supports hooks for pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, and post-delete. With these, you can now attach Kubernetes jobs to release events.
This release marks the second of four planned Alpha releases. We have made a lot of progress (and a lot of changes) since Alpha.1. Here are the highlights:
helm lint has gotten a major overhaul. The core architecture is now considered stable, and the linter team is transitioning focus to (a) adding rules, and (b) integrating linting into the chart development workflow.
Helm's server-side Tiller component can now be installed into any namespace. Alpha.1 restricted Tiller to the helm namespace. Now Tiller is installed into the user's configured namespace (usually default) by default, but can be installed into any namespace.
Values files are now in YAML format (bye-bye TOML). We're experimenting with support for globally scoped variables.
Templates now support more functions (Sprig 2.3). We still have a few big changes coming to the template system, but the new docs/examples/nginx template provides a better example of how we envision template support.
helm install can now install directly from a chart repository.
Helm charts now support .helmignore files, which are similar to .gitignore files, providing a convenient way to tell Helm about files that should not be packaged into the chart.
Tiller has liveness and readiness probes for Kubernetes
The Deis Workflow team is as happy as a baby goat jumping off stuff during spring time. We just cut Release Candidate 2 of Deis Workflow!
While we are busy leaping off things in fits of glee, give Deis Workflow RC2 a shot.
We've been generally cleaning house and closing bugs. There are a few changes that we want to highlight for this release candidate.
Private Image Support
We shipped private image support in Workflow Beta 3. For RC2, instead of always pulling the remote images to the managed on-cluster registry, we now use ImagePullSecrets baked into Kubernetes. This means your private images will be pulled directly to the nodes. Usually good advice to go direct to the source concerning private matters, no?
New name for Release ENV vars
If your application is utilizing the DEIS_RELEASE environment variable you will need to update your application. In a bout of house cleaning, we've switched that over to WORKFLOW_RELEASE, it is Deis Workflow afterall. We've updated all our example apps as well, because bug free demos are always nice to see.
Ubuntu Slim, so thin!
Through the beta phase we repeatedly observed a number of DNS failures both on our end-to-end testing infrastructure and our development installs. Through a long and twisty maze of bugs, this boiled down to a bug in ulibc's DNS resolver.
For DNS stability, image security visability and other ilities, we've switched our base distribution to Ubuntu Slim. If Macho Man Randy Savage were still around, I'm sure he'd be glad for the change.
Upgrading to GA Release
The release of Helm Classic and RC2 have put in place the necessary functionality to provide an in-place upgrade story. The TL;DR version is that you will need Helm Classic 0.8.0 or later, a running Workflow RC2 cluster, a copy of your templated parameters and some cluster secrets. A quick un-install and re-install will bring your Workflow cluster up to stable when we ship our GA Release.
For the intrepid, you should be able to upgrade from beta4 to RC2 by manually applying a few Kubernetes annotations. Give it a shot! Your experience here is very welcome.
Upgrading from RC1 to RC2 should work as-documented.
Platform SSL Secret Changes
To mirror the secret format used by Ingress controllers in Kubernetes, we've changed the keys used for the platform SSL
certificate. Before upgrading, update the secret via kubectl --namespace=deis edit secret deis-router-platform-cert:
Copy the existing cert key to tls.crt
copy the existing key key (ahem) to tls.key
Once you have completed the upgrade to RC2 you may delete the cert and key keys (ahem).
That's not all!
Many bug fixes, small updates, little tweaks and tuning, our ride has been pimped and is ready for prime time.
Click through for the complete release notes for RC1 and RC2.
This release marks the first in the Helm 2 line. It is an unstable Alpha-quality release that supports the core functionality for the Helm 2 platform.
Helm 2 has two major components:
The Helm client, whose responsibility is to provide tooling for working with charts and uploading them to the server.
The Tiller server, whose responsibility is to manage releases into the Kubernetes cluster.
Additionally, Helm can fetch charts from remote repositories. A Helm 2 chart repository is simply an HTTP server capable of serving YAML and TGZ files.
As a developer preview, the Alpha 1 release does not have a binary build of its components. The quickest route to get started is to fetch the source, and then run make bootstrap build. To start using Helm, use helm init.
Stay in touch
To keep up with news on Helm, join the #Helm channel on the Kubernetes Slack channel, or join our weekly developer call every Thursday at 9:30-10:00 Pacific.