Tag: Annoucement
17 Nov 2016 in Helm, Annoucement

Helm 2.0 stable release!

Kubernetes Helm, the package manager for Kubernetes, has released the 2.0.0 version of software. Helm 2 gives teams the tools to collaborate when creating, installing, and managing applications inside of Kubernetes.

With Helm you can…

  • Find pre-packaged software (charts) to install and use
  • Easily create and host your own packages
  • Install packages into any Kubernetes cluster
  • Query the cluster to see what packages are installed and running
  • Update, delete, rollback, or view the history of installed packages

Helm includes two components: The Helm CLI tool, and an in-cluster release manager named Tiller. The Tiller component is responsible for tracking and managing installed packages.

Helm was the missing piece that enabled us to deploy our healthcare application to Kubernetes in a HIPAA-compliant way. It's also made our development/acceptance infrastructure much easier to manage. -- Sean Knox, Director of Engineering, Able Health

Read More
21 Oct 2016 in Helm, Annoucement

Helm Beta.1: Fixes, fixes, everywhere...

The Helm community has cut the first beta release for 2.0.0! Helm is now feature complete and the community is focusing on fixing bugs, general stability, and documentation.

If you haven't checked out Helm, now is a great time to jump in and help the team batten down the hatches.

As always, the great Helm community can be found in the #helm channel on the Kubernetes Slack.

Read More
14 Oct 2016 in Helm, Annoucement

Happy 1st Birthday Helm!

The Story Behind Helm

Happy 1st Birthday, Helm!

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.

Read More
10 Oct 2016 in Helm, Annoucement

Alpha.5: Rollback, history, UX improvements, dependency management

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.

Read More
6 Sep 2016 in Helm, Annoucement

Helm Alpha.4: Persistent Storage, Improved Status, Provenance Files, and API Version Checking

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. ❤️

Getting Started

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:

$ helm init

This will configure your local Helm, and also install and configure the in-cluster Tiller component.

What's Next

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.

10 Aug 2016 in Helm, Annoucement

Helm Alpha.3: The biggest release yet!

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.

But that is not all!

Read More
24 Jun 2016 in Helm, Annoucement

Helm Alpha.2: Update all the things!

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
Read More
6 Jun 2016 in Deis Workflow, Annoucement

Deis Workflow Release Candidate (Hooray)

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.

As the "age old" adage goes, "it is always DNS".

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.

The updated documenatation is available here.

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.

Read More
26 May 2016 in Helm, Kubernetes, Annoucement

Helm 2 Reaches Alpha 1

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.

You are welcome to join! https://engineyard.zoom.us/j/366425549

Click Play

During the May Deis Community meeting I took a few moments to talk about the general direction and core values for the Helm project. Click play for my presentation: