Why A Package Manager?
Some of you may be wondering why Kubernetes needs a package manager. After all, can’t folks share their existing Kubernetes config files? Can’t those file be forked, modified, and be the foundation for custom ones? Of course they can. But, many people don’t operate that way.
The spirit of open source has lead to a world with easy sharing that’s up front and over time. For example, that’s why every modern programming language and platform has a package manager that deals with some elements of lifecycle, dependencies, and other issues. Because sharing is continuous and not just up front.
Kubernetes is a platform and Helm is its package manager.
When Helm first came about it was a simple client side package manager that made big waves. It turns out that sharing configuration for Kubernetes applications was a gap and Helm filled it well. The folks at Deis had solved a problem in a way people liked.
At the same time another project in this space was going on. It was the deployment manager by the Kubernetes folks. This was prior to Kubernetes moving to the Cloud Native Computing Foundation (CNCF) and the effort was driven by Google. Deployment manager and Helm were trying to solve similar and overlapping problems.
Instead of two projects in this space these two projects came together in Kubernetes Helm. The original Helm was renamed to Helm Classic and deployment manager was renamed Helm. Then work began on something new and better. That something better is Helm 2.
This milestone is about more than a second major release from lessons learned in the first version. It’s about people coming together. Folks from Deis, Google, CoreOS, Bitnami, skippbox, and others contributed to this release.
How To Use Helm
Rather than to write about how to get and use Helm myself, take a look at the excellent documentation on the Helm project.