Helm package manager featured image

Introduction to Helm: Package Manager for Kubernetes

Kubernetes is a popular and powerful container-orchestration system. Deploying applications to it, however, can be quite complex. That’s because a single application setup could entail generating several interdependent Kubernetes resources. Those can include deployments, pods, services, and replica sets. Each of these requires a YAML manifest file to be written.

To ease the process of packaging, configuring, and deploying applications and services by operators and developers to the Kubernetes cluster, a package manager named Helm has been put together. Helm is a part of a non-profit venture known as the Cloud Native Computing Foundation. The Foundation supports Kubernetes-centric open-sourced projects. Helm is, in fact, itself an official Kubernetes project.

This tutorial will take a look at Helm and its methods of simplifying application deployment to Kubernetes. For those who want to first take a deep dive into the Kubernetes ecosystem, take a look at our Getting to Know Kubernetes tutorial.

Helm: an Overview

Operating systems and programming languages, by and large, have package managers that assist with the software’s installation and maintenance. You might be familiar with some of these packages like Python’s pip or Debian’s apt.

Much like other package managers, Helm is able to:

  • Perform software installations and upgrades.
  • Install dependencies automatically.
  • Configure deployments of software.
  • Retrieve software packages from repositories.

It is capable of providing the above functionality via the use of several components including:

  • A helm command line (directs users to Helm functionality).
  • Use of tiller, a companion server component that traverses through Kubernetes clusters listening for helm sourced commands, and upon receiving them, addresses the configuration and deployment of the cluster’s software releases.
  • Use of charts (a Helm packaging format).
  • Utilization of a repository of officially curated charts prepackaged for popular open-source projects.

Let’s take a look at some of the formatted charts.

Use of Charts

Charts is the term used for Helm packages consisting of YAML configuration files and templates. They are all rendered into Kubernetes manifest files. The following is the very basic chart directory structure:

helm directory structure

Each directory and file is associated with particular functionality:

  • charts/: While it is more effective to use requirements.yaml for linking dependencies dynamically, manually managed chart dependencies can be placed into the charts directory.
  • templates/: Contained in this directory are config files (from the command line and values.yaml) combined with template files (using the GO language’s template format), all rendered into Kubernetes manifests.
  • Chart.yaml: This is a (YAML type) file containing metadata about the chart, including the name, version, relevant website, keyword, and maintainer information.
  • LICENCE: A license (plaintext) for the chart.
  • Values.yaml: A file containing the chart’s default configuration values.
  • Requirements.yaml: A file containing the chart’s dependencies.
  • README.md: A file with information for the chart users.

The chart can be installed via the helm command either from a .tar.gz packaged version of the directory’s structure or from a local directory. The chart packages can be downloaded and installed from repos (chart repositories) as well. Next, let’s familiarize ourselves with chart repositories.

Use of Chart Repositories

Index.yaml files and .tar.gz packaged charts are found in a Helm chart repo. This is just a simple HTTP site. Index.yaml files can be created from packaged charts using the subcommands that exist under the helm command and can be served by any static site host including GitHub Pages, any web server, or object storage service.

Preconfigured in Helm is a stable, a default repository of charts that can be found in GitHub’s helm and charge Git repository. The repository points to a Google Storage bucket at http://kubernetes-charts.storage.googleapis.com.

The helm repo add command can also help to add on other popular repositories. Some of the charts that are not covered in the stable repository can be found at Bitnami Helm Charts, while other charts from the official incubator repository that are not stable-ready can also be added on. The incubator usage instructions can be found on GitHub’s official Helm charts page.

Regardless of where the chart came from (a repo or a locally developed one), it will need to be configured to the particular setup type. Let’s consider these configurations.

Use of Chart Configurations

The values.yaml file usually contains default configuration values for a chart. While some apps may deploy with default values, some will need to be reconfigured for the user’s specific needs. The chart’s author determines which values are eligible for configuration. Some may be passed through the underlying container for app-specific configurations, while others are utilized for Kubernetes primitives configs. Here is a sample of such values:

values.yaml file

The helm inspect values chart name command can be used to dump all of the chart’s configurable values via the Kubernetes Service resource. They can also be overwritten with the helm install command from your own YAML file, or using the --set flag on the command line to set up options individually. Of course, these values only need to be specified if you wish to deviate from the defaults.

The release of a helm chart with a particular configuration is dubbed as a release, the next logical topic we will address.

Helm Releases

When the chart is installed, Helm combines the chart’s templates with user-specified configurations and value.yaml contains defaults, rendering them via Kubernetes manifests, deployed by the Kubernetes API. This sets up a particular chart’s configuration and deployment, also known as a release. The concept of releases is important because a developer may wish to release the same app multiple times in a cluster, such as MySQL which may have varied configurations based on the release.

Different instances of a chart might need to be upgraded individually, such as in an instance where one application is ready for a MySQL updated server, while another one is not. Helm affords the ability to conduct these upgrades individually.

Upgrades to another release can be made for varying reasons. For instance, you may want to stay current with the latest available releases or because you may wish to update the release’s configuration. Regardless, there is a new revision created with every release. This means that with Helm, if there is an issue, it permits you to roll back to a configuration of a prior release easily.

Chart Creation

When no pre-configured charts exist for the software being deployed, you may need to develop your own version. Using the helm create chart-name, Helm can output a scaffold of a chart directory, creating a folder with files and directories (see the Use of Charts section above).

After those are created, the chart’s metadata should be filled out in Chart.yaml and the Kubernetes files should be moved to the templates directory. Next, relevant config variables need to be extracted into the values.yaml from your manifests, and then, using the templating system included back in the manifest templates.

Helm has a wide array of subcommands that assist in the packaging, testing and serving your charts. You can find more information about these subcommands in Helm’s official chart development documentation.

Conclusion

This guide provided an overview of the Kubernetes package manager, Helm. We provided a review of Helm’s architecture, the helm and tiller components, reviewed Helm chart formats, and explored repositories for charts. We also explained how Helm charts are configured and how those configurations can vary based on chart releases on Kubernetes clusters. Lastly, we reviewed how a chart can be created when no suitable chart for an application need exists.

To find additional information, you can check out the official Helm documentation. You can also take a look at the official helm/charts Git repository on GitHub that contains Helm’s official charts.

Furthermore, take a look at our other tutorials focusing on Docker and Kubernetes that you can find on our blog:

Happy Computing!