Why Kubernetes Needs Helm
Earlier this week, Deis released Helm—the package manager for Kubernetes. Conceptually similar to Homebrew, Helm makes it easy to install standard workloads on Kubernetes.<!--more-->
But... Kubernetes is a container platform, so why does it need a package manager?
Perhaps looking at OS-level package managers (like Homebrew, apt, yum/rpm, ports, and so on) will help explain the situation.
Why use apt, yum, or homebrew?
Let's take a typical scenario.
I'm sat at the terminal in the chilly server room. I tried the command again:
./configure && make. Page after page of information scrolled across the screen. Apache httpd was building. I flipped open my book to read a few pages while I waited. Several minutes later, I saw the
make command fail. I just wanted a stock Apache httpd server, but I couldn't figure the right combination of build flags, nor could I find and install all of the correct dependencies.
In frustration, I gave up and tried the radical approach: I switched operating systems.
Then when the time came to install Apache httpd, I simply typed
apt-get install apache. And hey presto! It worked. If I needed to make changes, I could head to the
/etc/httpd directory and configure away. But even prior to that I had a functioning web server. Apache httpd was working right out of the box.
Then and now
Fast forward a decade or so. I discovered Kubernetes.
Kubernetes is running in a three-node configuration, and I'm trying to deploy my first workload: a database. There are several container images to choose from on Docker Hub, and I've already consigned myself to an hour or two of trial and error as I figure out which container image is my best chance of getting something running.
But before I've even made it that far, I hit another roadblock.
I have to figure out how to write the configuration to run this image in Kubernetes.
I don't know whether I need a pod or a replication controller. I'm not totally clear on how to choose. There's something called a service that I sort of conceptually get, but don't know why I'd need it. Why would I want load balancing for a single DB? And what's this port mapping stuff for? And how am I supposed to get the database password into these secret things? Does the image support that? Do I need a volume? How am I going to connect my web app to all of this? I'm not even sure how to test whether it works. And does it matter whether I write in JSON or YAML? And... And... And...
I just want to get my database running!
Getting started should be easy
Kubernetes, like your typical desktop or server operating system, is useful becasuse it can run a wide variety of workloads. And thanks to Quay.io, Docker Hub, GCR, and the host of other Docker image repositories, we have no shortage of available workloads to experiment with.
So why not make it dead simple for people to use those workloads?
Thanks to apt and yum, we generally don't have to compile things anymore. Our Linux boxes just work. Most of the time, we don't even have to edit the configuration files. Thanks to Homebrew, OS X users can tap a wealth of open source tools without having to become Makefile gurus. I have 46 brew-installed packages on my system, and I've only done special configuration for three. The rest meet my needs with their default settings.
I would posit that Kubernetes workloads follow these same patterns. And so a well-defined package management tool can bring all of the advantages of an OS package manager to this container platform.
Kubernetes will benefit when a community of developers provides a vast repository of ready-made charts for running workloads on Kubernetes.
But, but, but...
Most people seem to understand the general idea.
But there's still some confusion about the problem a package manager is trying to solve.
- "How do I manage rolling deployments?"
- "How do I template things?"
- "Can this solve continuous deployment processes?"
- "Will this automatically run tests on deploy?"
These are interesting conversations to have. But ultimately, none of them have to do with package management.
We could dive into a detailed theoretical discussion, but evidence trumps abstraction.
From apt to yum to Homebrew, these tools do not address problems outside of package management. We could spread our net even wider and point out that CPAN, npm, gems, mix, composer, glide, Godeps, berkshelf, and a host of programming language package managers that also do not do these things.
Is it because these tools are "doing it wrong"? Nope. Package managers are solving a different problem set, and following an established formula for doing so:
- Well-informed practitioners build packages optimized for general use
- A distribution system makes those available for an entire user base
- Users can easily install these packages
- Users then take on the task of tailoring the packages to their needs (and they often use other tools to do so)
Will Kubernetes benefit from this? Tremendously. In fact, providing this functionality lowers the collective bar for bringing new users to the platform.
But what about all of those questions I just deemed outside of scope of a package manager? They are definitely important questions, and a wealth of new tools like Google's own Deployment Manager are here to help address them. Just like Chef, Puppet, and Ansible all use
apt-get, we anticipate that Helm will find its way into a supporting role for continuous integration and continous deployment tooling. But the primary objective of package management is still distinct.
It is tempting to add many bells and whistles to a package manager. It's easy to conflate package management with continuous integration, continous deployment, operations, and integrated testing. And it's tempting to search for silver bullet solutions that address a multitude of problems.
But ultimately, focus is good. We need an easy way to install a wide variety of established workloads on Kubernetes. The concept of the package manager is a battle-tested strategy for meeting this need. And that's a problem we're passionate about solving.