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
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:
helmcommand line (directs users to Helm functionality).
- Use of
tiller, a companion server component that traverses through Kubernetes clusters listening for
helmsourced 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.
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:
Each directory and file is associated with particular functionality:
- charts/: While it is more effective to use
requirements.yamlfor 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
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
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:
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.
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.
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.
This guide provided an overview of the Kubernetes package manager, Helm. We provided a review of Helm’s architecture, the
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.
Furthermore, take a look at our other tutorials focusing on Docker and Kubernetes that you can find on our blog:
- Getting to Know Kubernetes
- How To Create a Kubernetes Cluster Using Kubeadm on Ubuntu 18.04
- Clean Up Docker Resources – Images, Containers, and Volumes
- How to install & operate Docker on Ubuntu in the public cloud
- Introduction to Helm: Package Manager for Kubernetes - December 13, 2021
- Programming with Python 3: How To Go About Constructing Classes and Defining Objects? - November 4, 2021
- Installing and Using Composer on Ubuntu 18.04 - September 30, 2021