HELM 101: An Introduction to Package Manager for Kubernetes

HELM is an open-source package manager for Kubernates, a powerful container orchestration platform for modern applications. It is officially owned by Kubernetes and managed by the Cloud Native Computing Foundation (CNCF). This ensued from Google handing over maintenance of Kubernetes to CNCF in 2018 (link). CNCF, a part of the Linux Foundation is a forum that oversees the complete Cloud-Native Software ecosystem. Kubernetes has a lot of components like pods, services, replicasets and deployments each requiring their own manifest files. This makes managing the complete lifecycle of an application cumbersome. Helm, like any other package manager, eases out management, up-gradation, and dependency resolution of Kubernetes resources.

Helm has a server component – ‘Tiller’, which is deployed in the same Kubernetes cluster as other deployments. Tiller essentially listens and acts on the commands administered through the ‘Helm’ CLI tool and convert those to Kubernetes manifests. Helm packages are managed through an abstraction called ‘Charts’. There is an official chart repository maintained by the Helm Community which hosts packages for the commonly used applications. Other than the already existing charts, users have the flexibility to create new charts for their unique use-case and push them to a public/private repository.

A typical helm chart consists of templates, values.yaml, and chart.yaml. Chart.yaml consists of all the metadata related to the deployment like an owner, email, version, etc. Values.yaml have all the default configurations needed for the application to function. The fields in values.yaml can be overridden to custom values based on the requirements. A simple use case for this is the deployment of an application in a tiered environment like development, staging, and production with different configurations and keys. The template file uses the Golang templating format to assemble the configurations from values.yaml or command line and convert the complete configuration into a Kubernetes manifest. Helm manages the installation of a chart through the notion of ‘Releases’. A combination of deployment, configuration, and the defaults in values.yaml creates a unique release. A single chart can be used to create multiple releases based on varied configurations. A specific use case for this is a messaging queue or a broker. If we need to deploy a cluster of brokers such that it follows the conception of ‘High Availability’, we may deploy 1 queue as active and another queue as a mirror of the active queue. Another use case would be having 2-3 queues out of which 1 is used for writing data and, the others are used for reading the mirrored data. In-case the application is read-heavy rather than write-heavy, this configuration can benefit application performance.

In this introductory article, we touched upon the basics of Helm and its components. We also looked into the typical hierarchy of a helm chart and a few of the use-cases to support the objective of the element.

Note: This is very basic introduction to Helm. For more detailed information on the internal architecture, commands and components, refer the official helm documentation.