Helm: the package manager for Kubernetes
Containers have revolutionized the way we create, develop and deploy applications. While managing large fleets of containers is difficult, Kubernetes handles it very well… but managing Kubernetes is hard. On top of that, composing multi-container applications is another card in a castle. Helm aims to solve this problem by providing package management for Kubernetes.
What is Helm?
Fundamentally Helm is a package manager… kind-of. It behaves just like any other package manager from the outside, but under the hood it interacts with Kubernetes (not a small feat). It enables you to install complex applications (such as a WordPress stack: WP+Web server+Database+Caching) with one click. Managing such applications also becomes easier since Helm tracks all applications deployed through it.
Helm uses “charts” to define applications. Charts use YAML, the same language used for Kubernetes manifests. Each time you deploy a new application, a new “release” is created, an application can be deployed multiple times thanks to releases. Releases can be upgraded or rolled back Charts are stored in repositories, much like software repositories.
Why would you need a package manager in Kubernetes?
There are many advantages in using Helm, first and foremost: abstraction. When you package an application you enable users to install applications with a simple command rather than sifting through complex Kubernetes manifests that may also contain dependencies. From a consumer standpoint it is, of course, easier to run a command as opposed to explore the manifests, set up dependencies run a tailored version for his environment and everything goes well. To sum it up:
- For developers: once an application is containerized, packaging through Helm allows to define dependencies and faster deployment cycles for the end-users.
- For administrators: applications deployed through Helm are tracked in an orderly way and follow the developers’ (assuming the developer created the chart) guidelines when deploying.
- For end-users: deploying a complex application becomes much easier and controlling the status of each applications is at one’s fingertips.
Helm architectures follows (in version 3.0 this is not the case, more in the next section) a client-server model. The executable (client) can be executed from anywhere (as long as you have the right credentials). On the other end there is Tiller, the server component that lives inside the Kubernetes cluster . Helm interfaces with Tiller which oversees applications deployed through it and enables new deployments by communicating with Kubernetes. The architecture is quite simple, but if you add RBAC (default on new Kubernetes cluster) and TLS, deploying Helm becomes more difficult.
The future: Helm 3.0
A new version is in active development. Mostly to address security concerns, version 3.0 aims to completely eliminate the need for Tiller. Currently, version 3.0 is in beta status, you can read more about this version here.
Helm 3.0 is out take a look at it here!
Latest posts by mark (see all)
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020