Kubernetes Series: Helm Charts Overview

Sylia CHIBOUB
Level Up Coding
Published in
10 min readMar 15, 2023

--

Introduction

This guide walks through the basic concepts of Helm needed to start deploying applications on a Kubernetes cluster. It covers the basic usage patterns of the helm client, including creating, installing, searching, updating, upgrading, rollingback and uninstalling Helm Charts.

General Concepts

According to Helm Documentation. Helm is a package manager for Kubernetes. [1]

A package manager is a collection of tools that automates the process of installing, updating, upgrading, configuring and removing software. It allows to easily install an application without having prior knowledge of its setup.

An application exists in multiple versions, it can run in multiple environments and in Kubernetes, an application is made of several files known as manifests such as : Deployments, Services, ConfigMaps, Ingress etc. Thus, Helm is used to facilitate the installation and management of Kubernetes applications. through the use of three concepts:

  • A Chart is a Helm package. It regroups all of the necessary manifests necessary to run an application within the Kubernetes Cluster. [1]
  • A Repository is the place where charts can be collected and shared. It is like the Docker Hub but for Kubernetes. It can be private or public. [1]
  • A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new release is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own release, which will in turn have its own release name [1]

With helm, application manifests are packaged into a single Chart. This Chart can be put into a Repository . Users can search that Repository to discover Charts to install (deploy) into their Kubernetes Cluster creating new Release for each installation.

Helm Installation

Helm can be installed in many ways. One of which is from script [3]

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Helm Usage

Once helm is installed , the following operations can be performed:

1. Create and Install a Helm Chart

The following command will create a Chart named postgres.

helm create $HOME/postgres

To install a Chart ( deploy the defined application into the Kubernetes Cluster) , use the helm install command. At its simplest, it takes two arguments: A release name that you pick, and the chart path you want to install.

# helm install [RELEASE_NAME] [CHART PATH]
helm install my-postgres postgres/

If you don’t want to specify a release name, Helm can generate one for you through the following command :

# helm install [CHART DIR] --generate-name 
helm install postgres/ --generate-name

A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing postgres would be stored in a $HOME/postgres/ directory. [2]

Inside of this directory, Helm will expect the underlying structure [2]:

postgres/
Chart.yaml # A YAML file containing information about the chart
values.yaml # The default configuration values for this chart
templates/ # A directory of templates that, when combined with values,
charts/ # A directory containing any charts upon which this chart depends.

The Chart.yaml File

The Chart.yaml file is required for a chart. It contains the following fields:

apiVersion: The chart API version (required)
name: The name of the chart (required)
description: A single-sentence description of this project (optional)
type: The type of the chart (i.e application) (optional)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
maintainers: # (optional)
- name: The maintainers name (required for each maintainer)
email: The maintainers email (optional for each maintainer)
url: A URL for the maintainer (optional for each maintainer)

Note : SemVemeans Semantic Versioning: v.major.minor.patch (i.e v1.25.6)

  • The apiVersion Field

The apiVersion field should be v2 for Helm charts that require at least Helm 3. Charts supporting previous Helm versions have an apiVersion set to v1 and are still installable by Helm 3.

  • The version Field

Every chart must have a version number. A version must follow the SemVer 2 standard. For example, an nginx chart whose version field is set to version: 1.2.3 will be named nginx-1.2.3.tgz .

  • The appVersion Field

Note that the appVersion field is not related to the version field. It is a way of specifying the version of the application. For example, the drupal chart may have an appVersion: "8.2.1", indicating that the version of Drupal included in the chart (by default) is 8.2.1. This field is informational, and has no impact on chart version calculations.

  • The kubeVersion Field

The optional kubeVersion field can define semver constraints on supported Kubernetes versions. Helm will validate the version constraints when installing the chart and fail if the cluster runs an unsupported Kubernetes version.

The values.yaml File and templates/ Folder

Helm Chart templates are written in the Go template language.

All template files are stored in a chart’s templates/ folder. When Helm renders the charts, it will pass every file in that directory through the template engine.

Files inside templates folder are Kubernetes Manifest Yaml Files. For example a service.yaml file.

# sevice.yaml 

apiVersion: v1
kind: Service
metadata:
name: {{ .Values.serviceName }}
namespace: {{ .Values.nameSpace }}
spec:
selector:
app: {{ .Values.appName }}
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 8080

As long as these files are templated, variable files (known as values) should be passed along with these templates files to the template engine for further variable substitution.

Values for the templates are supplied in three ways :

  • Chart developers may supply a file called values.yaml inside of a chart. This file can contain default values. This can be provided on the command line with helm install . This command will automatically look for values in values.yaml file.
# helm install release-name chart-dir or helm install chart-dir --generate-name

helm install my-postgres postgres/

# or

helm install postgres/ --generate-name
  • Chart users may supply a custom YAML file that contains values. This can be provided on the command line with helm install for example if the custom values file is values.prod.yaml . Then , it should be passed with helm install as follows :
# helm install -f custom-vars-file.yaml release-name chart-dir

helm install -f postgres/values.prod.yaml my-postgres postgres/

# or

helm install -f postgres/values.prod.yaml postgres/ --generate-name
  • Chart users may supply custom variables on command line using --set which specifies overrides of the custom values files such asvalues.prod.yaml and the default values.yamlfile.
# helm install -f custom-vars-file.yaml release-name chart-dir

helm install --set serviceName=test -f postgres/values.prod.yaml my-postgres postgres/

# or

helm install --set serviceName=test -f postgres/values.prod.yaml postgres/ --generate-name

When a user supplies custom values, these values will override the values in the chart’s values.yaml file. Let’s take an example:

# values.yaml
serviceName: postgres-svc
appName: postgres
nameSpace: default
# values.prod.yaml
appName: postgres-prod
nameSpace: prod

After running:

helm install -f postgres/values.prod.yaml my-postgres postgres/

The template engine will make the following subtitutions.

apiVersion: v1
kind: Service
metadata:
name: postgres-svc # from values.yaml
namespace: prod # from values.prod.yaml
spec:
selector:
app: postgres-prod # from values.prod.yaml
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 8080

To see what options are configurable on a chart (variables of the chart), use helm show values. This command inspects a chart (directory, file, or URL) and displays the contents of the values.yamlfile.

# helm show values [PATH TO CHART]
helm show values postgres/

When a user supplies --setin command line values will override the values in the chart’s values.yaml file. and the other custom values file such as values.prod.yaml Let’s take an example:

helm install --set serviceName=test -f postgres/values.prod.yaml  my-postgres postgres/ 

The template engine will make the following subtitutions.

apiVersion: v1
kind: Service
metadata:
name: test # from --set flag
namespace: prod # from values.prod.yaml
spec:
selector:
app: postgres-prod # from values.prod.yaml
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 8080

The charts/ directory

In Helm, one chart may depend on any number of other charts. These dependencies can be dynamically linked using the dependencies field in Chart.yaml or brought in to the charts/ directory and managed manually.

Helm Chart dependencies are out of the scope of this article, you can learn more in the Helm Official Documentation .

Once a chart is created and configured to match your needs, you can :

  • Validate your chart : examine a chart for possible issues
helm lint postgres/

# Output:
==> Linting postgres
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed
  • Package your chart: package a chart directory into a chart archive
helm package postgres/

# Output:
Successfully packaged chart and saved it to: $HOME/postgres-0.1.0.tgz
Note that 0.1.0 is the version: 0.1.0 specified in Chart.yaml
  • Install your chart: after a chart has been packaged, it can now be easily be installed (deployed into Kubernetes Cluster) by helm install:
helm install my-postgres $HOME/postgres-0.1.0.tgz

Note that, a Chart can be installed without been packaged as we have seen earlier

helm install my-postgres postgres/

2. Find, Install and Update a Helm Chart

Helm comes with a powerful search command. It can be used to search two different types of source: [4]

  • helm search hub searches the Artifact Hub, which lists helm charts from dozens of different repositories. [4]
  • helm search repo searches the repositories that you have added to your local helm client (with helm repo add). This search is done over local data, and no public network connection is needed. [4]

Let’s explore the helm search hub

# looks for prometheus Charts avaialble in the Public Artifact Hub
helm search hub -h
helm search hub prometheus
helm search hub prometheus -o yaml

# Output:

- app_version: v2.41.0
description: Prometheus is a monitoring system and time series database.
repository:
name: prometheus-community
url: https://prometheus-community.github.io/helm-charts
url: https://artifacthub.io/packages/helm/prometheus-community/prometheus

...
...

Let’s explore the helm search repo

helm search repo

#Output:

This command consists of multiple subcommands to interact with chart repositories.

It can be used to add, remove, list, and index chart repositories.

Usage:
helm repo [command]

Available Commands:
add add a chart repository
index generate an index file given a directory containing packaged charts
list list chart repositories
remove remove one or more chart repositories
update update information of available charts locally from chart repositories

Let’s add the prometheus-communitychart available on the public repo to our local repo for further manipulation

helm search repo

#Output: Error: no repositories configured
# Add a Chart repo to our local helm repo 

# helm repo add [CHART-NAME] [CHART-URL]

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

#Output: "prometheus-community" has been added to your repositories
# Check if the Chart has been added to our local repo

helm repo list

# Output:
NAME URL
prometheus-community https://prometheus-community.github.io/helm-charts
# Look for Charts available in repo 

helm search repo
# Look for only prometheus-community Charts available in repo 

helm search repo prometheus-community


#Output:

prometheus/alertmanager 0.26.0 v0.25.0 The Alertmanager handles alerts sent by client ...
prometheus/alertmanager-snmp-notifier 0.1.0 v1.4.0 The SNMP Notifier handles alerts coming from Pr...
prometheus/jiralert 1.2.0 v1.3.0 A Helm chart for Kubernetes to install jiralert
...
# get the latest information about charts from the respective chart repositories.

helm repo update
# get the latest information about only prometheus-community chart from the respective chart repositories.

helm repo update prometheus-community

Let’s perform some modifications on the prometheus-community chart


# Search of the prometheus-community Chart
helm search repo prometheus-community

# Select and Fetch a Helm Chart
helm fetch prometheus/prometheus

# Output: prometheus-19.7.2.tgz
# Select , Fetch and Untar a Helm Chart

helm fetch prometheus/prometheus --untar

# Output : prometheus Chart dir available locally
cd $HOME/prometheus

ls

# Edit Values.yaml

vim $HOME/prometheus/values.yaml

# Install a release of a Chart

helm install prom $HOME/prometheus
# List avaialable releases

helm list

# Uninstall the release

helm uninstall prom

# Remove the Chart from repo

helm repo remove prometheus

Note that helm sets an alternative location for storing cached files :$HOME/.cache/helm/

3. Upgrade a Release

When a new version of a chart is released, or when you want to change the configuration of your release, you can use the helm upgrade command.

An upgrade takes an existing release and upgrades it according to the information you provide. Because Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade. It will only update things that have changed since the last release.

For example, if we change the prometheus version in values.yaml file. The following should be performed to upgrade the currently ruuning release in the Kubernetes Cluster.

helm upgrade -f values.yaml prom prometheus/prometheus

We can use helm get values to see whether that new setting took effect.

# helm get values [RELEASE]

helm get values prom

4. Recovering a Release on Failure

Now, if something does not go as planned during a release, it is easy to roll back to a previous release using:

helm rollback [RELEASE] [REVISION]

For example, if the newely upgraded promtheus version doesn’t work properly, we can rollback to the previous one as follows

 helm rollback prom 1

The above rolls back our promrelease to its very first release version. A release version is an incremental revision. Every time an install, upgrade, or rollback happens, the revision number is incremented by 1. The first revision number is always 1. And we can use helm history [RELEASE] to see revision numbers for a certain release.

# helm history [RELEASE]
helm history prom

5. Uninstalling a Chart

When it is time to uninstall a release from the cluster, use the helm uninstall command:

# helm uninstall [RELEASE]
helm uninstall prom

If you wish to keep a deletion release record, use helm uninstall --keep-history

# helm uninstall --keep-history [RELEASE]
helm uninstall --keep-history prom

Using helm list --uninstalled will only show releases that were uninstalled with the --keep-history flag.

helm list --uninstalled

Using helm listwill only show currently deployed releases in the cluster

helm list

The helm list --all flag will show you all release records that Helm has retained, including records for failed or deleted items (if --keep-history was specified):

helm list --all

Conclusion

This chapter has covered the basic usage patterns of the helm client, including creating, installing, searching, updating, upgrading, rollingback and uninstalling Helm Charts.. It has also covered useful utility commands.

References

Level Up Coding

Thanks for being a part of our community! Before you go:

🚀👉 Join the Level Up talent collective and find an amazing job

--

--