9 Nov 2015

Introducing Helm, The Kubernetes Package Manager

Tags: Helm, Kubernetes

We at Deis are really excited about Kubernetes. In fact, we're hard at work building Deis v2 on top of a Kubernetes base. During this integration, we developed a tool that we think seasoned Kubernetes users will enjoy, and newcomers can use as an onramp for running containerized applications. And today, we're thrilled to announce this new tool.

We call it Helm, and it's the first package manager for Kubernetes.

Inspired by Homebrew, apt, and npm, Helm is a tool for working with Kubernetes-powered applications. It works like this:

  • A Helm package is bundled up as a chart.
  • The charts are collected together in a repository that you can search. Helm uses git under the hood for storing and organizing chart data.
  • Using the helm tool, you can find, customize, manage and install these charts.

Helm makes it easy run apps and services inside Kubernetes.

Helm's Goals

We built Helm to help with two things.

First, we want to make it simple to share information about running common apps and services inside of Kubernetes. When we all share our charts, the Kubernetes community at large learns how best to work with Kubernetes. We share information and discover great ways of doing things. And we also make it easier for newcomers to get going. Helm is about growing Kubernetes.

Second, we want to make it easier for teams to manage their Kubernetes manifest files. So we created a tool that eases the process of collaborating on and keeping track of your team's charts. Start with widely available charts, customize them to your team's needs, and then store them in your own version control. Helm is about helping teams.

Kubernetes is a powerful platform. We want to make it easy to manage the apps and services you deploy.

Let's See It!

Assuming we've already got a Kubernetes cluster running and a correctly configured kubectl, working with Helm is a piece of cake. Follow the installation instruction (there's only one!) on helm.sh, and you're ready to get started.

Helm configures itself. The first time you run Helm, it will automatically generate all the necessary directories and configuration files:

$ helm update
---> Cloning into '/Users/mattbutcher/.helm/cache/charts'...
---> Updating cache from https://github.com/deis/charts
---> Done

Helm makes it easy to find the chart you're looking for.

helm search alpine
    alpine (alpine-pod 0.0.1) - Simple pod running Alpine Linux.

And once you've found it, Helm gives you a quick way to run that chart:

helm install alpine
---> No chart named "alpine" in your workspace. Fetching now.
---> Running `kubectl create -f` ...
---> Done
# Alpine

This Chart provides a Pod running Alpine Linux.

The helm install command actually does two things. First, it copies the original chart into our local workspace. We call that fetching. Then it takes that local copy and pushes it into Kubernetes. In a moment I'll explain why we have that local copy.

Helm handles the packages up through initial installation, but kubectl is still the way to go for working with your cluster:

kubectl get pods
alpine    1/1       Running   0          22s

We have an Alpine pod running! We can just as easily remove it with helm uninstall alpine.

Helm simplifies the process of testing a chart. This is all well and good... but is it how we as seasoned DevOps engineers really plan on working? Probably not. We want more control, and Helm provides it.

Helm is designed for real-world usage.

Real World Helm

Instead of installing default charts, we often want to begin with a reliable and tested chart, modify it to our needs, and then deploy it. Helm makes that easy to do. Helm provides a workspace where we can start with existing charts and modify them to our needs.

Helm can fetch a chart into our workspace. Let's start with a simple Redis server:

helm fetch redis-standalone myredis
---> Fetched chart into workspace /Users/mattbutcher/.helm/workspace/charts/myredis
---> Done

Helm has made us a working copy of the redis-standalone chart. It has put that copy into our local workspace under the name myredis. (We could have left off the custom name, in which case our copy would be named redis-standalone).

Charts are neatly organized and compact. Our Redis chart looks like this:

$ cd /Users/mattbutcher/.helm/workspace/charts/myredis
$ tree
├── Chart.yaml
├── README.md
└── manifests
    └── redis-rc.yaml

There is only one Kubernetes manifest for redis-standalone: manifests/redis-rc.yaml.

Helm fetch shows us where that chart is, and we could point our favorite editor to that location. Or we could use helm edit myredis and edit the chart to our hearts' content.

Once we're done, we can then install that file into Kubernetes:

$ helm install myredis

Of course, there's nothing magical about Helm's manifest files. You could just as easily use kubectl create -f to load the manifest into Kubernetes. Think of Helm as a complementary Kubernetes tool that paves a predictable, collaborative, version-maintained path for your DevOps team.

The Helm Workspace is your playground. Not only can you modify existing charts, but you can build your own there. You can add version control and track your workspace as its own repository. And we even give you the tools for creating and submitting charts!

DIY Charts

You've tried some charts. You've customized a few. And now you're ready to build your own. Helm makes that part easy, too.

$ helm create diy
---> Created chart in /Users/mattbutcher/.helm/workspace/charts/diy

Now you have a new chart named diy. You could go to that directory and edit it. Or you could use helm edit diy. Test it with helm install or kubectl. When you're done, you can even copy it back to the main Helm repo:

$ helm publish diy

Want to submit it upstream to the official Helm Charts repo? Please do! We look forward to your pull requests! Just like Homebrew (our inspiration!) Helm needs you.


We set out to build a tool that is an onramp to Kubernetes. We wanted to make it easier for the Kubernetes newcomer to run production-grade workloads. We hoped to build something that seasoned developers will not only use, but contribute to. And we wanted to make it easier for teams to work together on Kubernetes-oriented projects. We think Helm is the right way to do it.

Helm is ready for you to try out. But we're not done yet. We've got some good things going, like making it easy for you to point Helm at your own chart repos. We are improving Helm's interactions, and growing Helm's ability to interact with Kubernetes (but still stay out of your way). There is more to come.

But what we're really excited about is the chart repository. Helm needs high-quality charts for everything from Apache to Zookeeper. We're inviting you to jump in and help out. See you on GitHub!

-- The Deis Team