Tag: Annoucement
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.

  • Developer Call: Thursday, 9:30 Pacific via Zoom

Major Fixes

  • Several fixes were made to helm delete and helm rollback
  • Documentation has been refreshed
  • Three minor features were added:
    • The --kube-context global flag was added to allow you to explicitly set the Kubernetes context.
    • Tiller now has gRPC tracing for debugging Tiller. This is disabled by default.
    • The helm repo add command now fetches the repository.
  • The Linux builds are now static, and can run in Alpine Linux

For the complete list of changes view the GitHub Release tag.

Binary Downloads

Binary downloads of the Beta.1 Helm client can be found at the following links:

What's Next?

The developers are now working on fixing bugs, improving stability, and building some great docs.

Beta releases will continue until the community feels that Helm is ready for production use. So grab the helm and join the community as we approach a stable 2.0.0 release!

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.

Binary Downloads

Binary downloads of the Alpha.5 Helm client can be found at the following links:

The big changes

Introducing helm rollback: A command for reverting a release to a previous version. It can even undelete releases that were deleted.

Helm and Tiller now are version-aware. They can better indicate whether they are compatible. You will get compatibility errors running helm alpha.4 and tiller alpha.5, for example.

Chart developers, we added a tool to help you manage chart dependencies. Check out helm dependency install and the new requirements.yaml file.

Repositories have been overhauled. To make it easier to find, install, and manage charts, we changed the format of index.yaml. If you run a chart repo, you should re-generate the index file!

Finally, we have worked hard to make some UX improvements:

  • The kubernetes-charts directory was renamed stable. Hooray for brevity.
  • helm update was changed to helm repo update
  • helm history is a new command to make it easy to see the history of a release.
  • helm search was rewritten to make it more usable
    • helm search with no term will return all charts
    • helm search stable/ will return all charts in the repository named stable
  • We dropped the requirement that you install with an explicit version number.
    • helm install stable/mariadb now installs the latest mariadb chart from the stable repository.
    • helm install stable/mariadb --version 0.1.0 now installs version 0.1.0 (rather than the latest)
    • The same syntax is true for helm inspect, helm upgrade, and helm fetch
    • Commands that generate listing (search, list, etc.) now use the table layout by default.

Changes for chart developers

In addition to the new helm dependency * tools, we have made a few small changes in the templates. Two new functions were added:

  • uuidv4 generates a random UUIDv4
  • toYaml encodes a value into YAML

Getting Started with 2.0.0-Alpha.5

The best way to get started is to head over to the Quick Start Guide. Or for more alternative installations, see the Installation Guide.

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

$ export HELM_OS=darwin && wget https://storage.googleapis.com/kubernetes-helm/helm-v2.0.0-alpha.5-$HELM_OS-amd64.tar.gz && tar -zxvf helm-v2.0.0-alpha.5-$HELM_OS-amd64.tar.gz && cd $HELM_OS-amd64

For Linux

$ export HELM_OS=linux && wget https://storage.googleapis.com/kubernetes-helm/helm-v2.0.0-alpha.5-$HELM_OS-amd64.tar.gz && tar -zxvf helm-v2.0.0-alpha.5-$HELM_OS-amd64.tar.gz && cd $HELM_OS-amd64

What's Next?

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.

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: