Chapter 4: Understanding Helm Charts

In the previous chapter, you learned how to use Helm from an end user perspective, leveraging it as a package manager to install applications to Kubernetes. Using Helm in this fashion did not require any Kubernetes expertise or any deep understanding of the application since all of the resources and logic were included as part of a Helm chart. The only concept you needed to be familiar with were the values that the chart provided in order to customize your installation.

We will now shift gears from using Helm charts to understanding how they work and are created.

To do so, we will cover the following topics:

• Understanding the YAML format
• Understanding chart templates
• Understanding chart definitions
• Life cycle management
• Documenting a Helm chart

Technical requirements

This section requires the helm binary to be installed on your local machine. The installation and configuration of this tool are covered in Chapter 2, Preparing a Kubernetes and Helm Environment.

Understanding the YAML format

YAML Ain't Markup Language (YAML) is a file format used to create human-readable configuration. It is the file format most commonly used to configure Kubernetes resources and is also the format used for many of the files in Helm charts.

YAML files follow a key-value format to declare configuration. Let's explore the YAML key-value construct.

Defining key-value pairs

One of the most basic examples of a YAML key-value pair is shown here:

name: LearnHelm

In the preceding example, the name key is given a LearnHelm value. In YAML, keys and values are separated by a colon (:). Characters written to the left of the colon represent the key, while characters written to the right of the colon represent the value.

Spacing matters in YAML format. The following line does not constitute a key-value pair:

name:LearnHelm

Notice that a space is missing between the colon and the LearnHelm string. This would result in a parsing error. A...

Understanding chart templates

The primary purpose of a Helm chart is to create and manage the Kubernetes resources that make up an application. This is accomplished through chart templates, with values serving as parameters to customize those templates. In this section, we will discuss how Helm templates and values function.

Helm charts must contain a templates/ directory that defines the Kubernetes resources to be deployed (although this directory is not strictly required if the chart declares dependencies). The contents under the templates/ directory are YAML files that are made up of Kubernetes resources. The contents of a templates/ directory may appear similar to the following:

templates/
  configmap.yaml
  deployment.yaml
  service.yaml

The configmap.yaml resource may then look as follows:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}
data:
  configuration.txt: |-
    {{ ...

Understanding chart definitions

The Chart.yaml file, also known as the chart definition, is a resource that declares different metadata about a Helm chart. This file is required and if it is not included in a chart's file structure, you'll receive the following error:

Error: validation: chart.metadata is required

In Chapter 3, Installing Your First Helm Chart, we explored the chart definition of Bitnami's WordPress chart by running the helm show chart command. Recall this chart definition by running this command again. We will assume that the Bitnami chart repository has already been added since this task was performed in Chapter 3, Installing Your First Helm Chart:

$ helm show chart bitnami/wordpress --version 8.1.0

Below lists the chart definition of the wordpress chart.

Figure 4.1 – The chart definition of the wordpress chart.

The chart definition, or the Chart.yaml file, can contain many different fields. Some of the fields...

Life cycle management

One of the primary benefits of Helm charts and their associated releases is the ability to manage complex applications on Kubernetes. A release undergoes multiple phases during its life span. To provide additional management capabilities around the life cycle of a release, Helm features a hooks mechanism so that actions can be undertaken at different points in time within a release cycle. In this section, we will explore the different phases of a release's life span and introduce how hooks can be used to provide capabilities for interacting not only with the release but also the entire Kubernetes environment.

In Chapter 3, Installing Your First Helm Chart, we encountered several phases that encompass the overall life span of a Helm release, including its installation, upgrade, removal, and rollback. Given that Helm charts can be complex, as they manage one or more applications that will be deployed to Kubernetes, there is often the need to perform additional...

Documenting a Helm chart

As with any other software that users interact with, a Helm chart should be properly documented so that users know how to interact with it. The Helm chart structure supports a README.md file for documenting usage, a LICENSE file for covering usage and distribution rights, and a templates/NOTES.txt file for generating usage instructions during chart installation.

The README.md File

README is a file commonly used in software development to describe the installation, usage, and other details of a product. A Helm chart's README file often contains the following details:

• Prerequisites: A common example of a prerequisite is creating a secret or a set of secrets to the Kubernetes cluster before a chart is installed. for the purpose of mounting to a Kubernetes deployment. Users can be made aware of this requirement by referencing the README file.
• Values: Charts often consist of many different values, each of which should be described in a table...

Packaging a Helm chart

While Helm charts follow a common file structure, they should be packaged in order to be easily distributed. Charts are packaged in tgz archives. While this archives can be manually created by using the tar bash utility or an archive manager, Helm provides the helm package command to simplify this task. The syntax of the helm package command is shown here:

$ helm package [CHART_NAME] [...] [flags]

The helm package command is run against a local chart directory. If this command is successful, it will generate a tgz archive with the following file format:

$CHART_NAME-$CHART_VERSION.tgz

The archive can then be distributed by pushing to a chart repository, which is a task that is explored further in Chapter 5, Building Your First Helm Chart.

The helm package command includes every file under a chart directory. While this is often the preferred behavior, it may not always be desired if the directory contains files that are not essential to Helm. One...

Summary

A Helm chart is a set of files, written primarily in the YAML format, that follows a certain file structure. The Chart.yaml file is used to set chart metadata and declare dependencies. The templates/ directory is used to contain Kubernetes YAML resources that are Go-templated, allowing them to be dynamically generated. Kubernetes resources defined under the templates/ directory can also contain certain hooks to configure stages in an application's life cycle. To provide documentation to users, charts can contain the README.md and templates/NOTES.txt files and can also contain the LICENSE file to declare chart usage and distribution rights. Finally, charts can contain a .helmignore file, which is used to omit declared files from the final packaged product.

In this chapter, you learned about the structure of a Helm chart and how to configure key chart components. With the knowledge from this chapter under your belt, you now have an understanding of the basic concepts...

Further reading

To learn more about the basics behind creating Helm charts, consult the Chart Template Guide page on the Helm documentation at https://helm.sh/docs/chart_template_guide/. The Charts section at https://helm.sh/docs/topics/charts/ also describes many of the topics discussed throughout this chapter, including chart file structure, dependencies, and the Chart.yaml file.

Questions

1. What is the file format that is most commonly used in Kubernetes and Helm?
2. What are the three required fields in the Chart.yaml file?
3. How can the values from a chart dependency be referenced or overridden?
4. Imagine you want to take a data snapshot of a database deployed with Helm. What can you do to ensure that a data snapshot is taken before upgrading the database to a newer version?
5. What files can you, as a chart developer, create to provide documentation and simplify the chart installation process for the end user?
6. What Helm templating construct can you take advantage of to generate repeating YAML portions?
7. How does the Chart.yaml file differ from the Chart.lock file?
8. What is the name of the annotation that defines a resource as a hook?
9. What is the purpose of functions and pipelines in chart templates? What are some common functions that can be used?