Advanced Helm Chart Handling and Installation

Last updated: March 11, 2024

1. Introduction

The Helm package manager is a way to handle, organize, and duplicate deployments within a Kubernetes environment. A Helm chart is the basic packaging unit. Like other packages, charts have versions. They differ by deployment environment and features. Sometimes, we might want to install certain chart versions and avoid others. Further, charts don’t always fulfill all the expectations for a certain deployment. Knowing how to handle such situations can be vital during administration.

In this tutorial, we explore advanced Helm chart installation and handling. First, to ease our efforts, we show how to enable autocompletion for Helm. After that, we briefly talk about the main chart installation sources. Next, we demonstrate ways to enumerate charts that are available within them, along with additional information. Finally, we turn to chart installation, focusing on stability, customization, and versioning.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15 and Helm 3.14. Unless otherwise specified, it should work in most POSIX-compliant environments.

2. Helm Completion

Due to Helm’s complexity, let’s begin by making navigation around the tool and its options easier.

Like many other contemporary tools, Helm provides a completion subcommand, which can generate autocompletion lists for different shells:

  • bash
  • fish
  • zsh
  • powershell

Let’s demonstrate this with Bash:

$ source <(helm completion bash)

Effectively, the helm completion bash command within the <() process substitution syntax generates a script. Once we source that script, it provides autocomplete suggestions for command lines that begin with helm:

$ helm [Tab]
completion  (generate autocompletion scripts for the specified shell)
create      (create a new chart with the given name)
dependency  (manage a chart's dependencies)
env         (helm client environment information)
get         (download extended information of a named release)
help        (Help about any command)
history     (fetch release history)
install     (install a chart)
lint        (examine a chart for possible issues)
list        (list releases)
package     (package a chart directory into a chart archive)
plugin      (install, list, or uninstall Helm plugins)
pull        (download a chart from a repository and (optionally) unpack it in local directory)
push        (push a chart to remote)
registry    (login to or logout from a registry)
repo        (add, list, remove, update, and index chart repositories)
rollback    (roll back a release to a previous revision)
search      (search for a keyword in charts)
show        (show information of a chart)
status      (display the status of the named release)
template    (locally render templates)
test        (run tests for a release)
uninstall   (uninstall a release)
upgrade     (upgrade a release)
verify      (verify that a chart at the given path has been signed and is valid)
version     (print the client version information)

This can be very convenient, especially beyond the subcommand level:

$ helm search [Tab]
hub   (search for charts in the Artifact Hub or your own hub instance)
repo  (search repositories for a keyword in charts)

Further, we can check flags and their functions:

$ helm search hub --[Tab]
[...]
--list-repo-url                  (print charts repository URL)
--max-col-width                  (maximum column width for output table)
--namespace                      (namespace scope for this request)
--output                         (prints the output in the specified format. Allowed values: table, …)
--qps                            (queries per second used when communicating with the Kubernetes API…)
--repository-config              (path to the file containing repository names and URLs)

Thus, we have a rudimentary help at the push of a button.

3. Artifact Hub and Repositories

The Artifact Hub is a central location for Helm charts. Currently, it serves both as the default repository and a Web application for publishing, finding, and installing packages for Kubernetes. The Artifact Hub replaces and aims to continue replacing scattered repositories around the Internet with one centralized system.

While private Helm repositories are still available, a single location for charts helps by providing a unified look and database.

This way, a default Helm setup directly enables access to multiple charts:

$ helm search hub | wc --lines
12254

As we can see, the hub is currently a list of thousands of charts.

Knowing how to search for charts and generally navigate around the database can save a lot of time during deployments.

4. Full List of Charts and Versions

One of the most comprehensive ways to browse the available charts from the Artifact Hub or a given repository is the search subcommand.

In particular, we can get a list of charts in all configured [repo]sitories:

$ helm search repo --versions --max-col-width 100 --output=table
NAME                                         CHART VERSION  APP VERSION  DESCRIPTION
banzaicloud-stable/acquia-docs               1.0.1          1.0.1        Acquia docs
banzaicloud-stable/acquia-docs               1.0.0          1.0.0        Acquia docs
banzaicloud-stable/anchore-policy-validator  0.8.3          0.5.6        [...]
banzaicloud-stable/anchore-policy-validator  0.8.2          0.5.5        [...]
[...]

Here, we see several flags:

  • –versions ensures we see all available versions of a given chart
  • –max-col-width sets the width of a line before truncation (as 100 characters)
  • –output specifies the output format (as the default table)

However, the –versions flag doesn’t work if we use hub instead of repo.

Still, when searching the hub, we can request the –list-repo-url:

$ helm search hub --list-repo-url --max-col-width 100 --output=table
URL                                                              CHART VERSION  APP VERSION  DESCRIPTION  REPO URL
https://artifacthub.io/packages/helm/mya/12factor                24.1.2                      [...]        https://mya.sh
https://artifacthub.io/packages/helm/gabibbo97/389ds             0.1.0          fedora-32    [...]        https://gabibbo97.github.io/charts/
https://artifacthub.io/packages/helm/four-allportal/4allportal   20.0.1         3.10.38      [...]        https://4allportal.github.io/helm-charts
[...]

Then, we can use the REPO URL to add the repository and list the available chart versions.

5. Helm Chart Installation

Since Helm is a Kubernetes package manager, installing is synonymous with deploying in most cases. This makes the process potentially more involved than adding a Linux package, for instance.

When it comes to chart installation, the install subcommand is the standard:

$ helm install [NAME] [CHART] [flags]

Notably, the order of the arguments is important.

5.1. Name

Each installation needs a name. This way, we can identify different deployments of the same chart.

Although we can specify NAME as the first command argument, we can also –generate-name (-g). This way, the install subcommand creates a unique name and doesn’t expect a name as its first argument.

5.2. Sources

Although we usually indicate a repository and chart name, the installation source can be one of several types:

  • chart reference like <REPO_NAME>/<CHART_NAME>
  • path to a chart package file like a .tgz or .tar.gz
  • path to a chart package content directory
  • universal resource locator (URL) like https://gerganov.com/charts/<CHART_NAME>-<CHART_VERSION>.tgz or just https://gerganov.com/charts (after –repo) and <CHART_NAME>
  • Oracle Cloud Infrastructure (OCI) specification like oci://gerganov.com/charts/<CHART_NAME>

This provides flexibility. For example, we don’t need to configure a whole repository for a single chart.

5.3. Customization

The install subcommand provides options for overriding chart information:

  • –set: overwrite values
  • –set-string: overwrite string values
  • –set-literal: overwrite literal string values
  • –set-json: overwrite values in JSON format
  • –set-file: indicate files for each overwritten value
  • –values (-f): indicate YAML file or URL for overwriting values

By leveraging these options, we can customize the installation.

5.4. Atomization

Often, charts deploy multiple services that depend on each other. If one doesn’t install properly, we might end up with a non-functional environment.

Because of this, we often leverage the –atomic flag in production settings:

$ helm install [...] --atomic

Atomic installations ensure that either everything installs as expected or no traces remain of the attempt. This way, we can be certain that the final result is a consistent environment.

The –atomic flag implies –wait. This makes the installation process –wait for –timeout or until all resulting objects such as pods, persistent volume claims, services, and similar are up. This way, a release is only successful upon full deployment.

5.5. Hooks

Similar to package managers that run scripts for some installations, Helm runs the hooks present in charts it deploys. However, this isn’t always desirable.

For instance, when we want to create a given object or resource during the first installation, attempting to recreate it might fail. In such situations, we can employ the –no-hooks flag to avoid any side effects from hook procedures.

5.6. Dry Run

Due to the complexity of some charts, knowing what and how they would install before actually attempting an installation can be beneficial.

Because of this, Helm provides the –dry-run option:

$ helm install --dry-run [...]

When performing a –dry-run installation, nothing is installed and cluster connections are skipped by default. Alternatively, we can assign server to the option to test connecting to the cluster as well.

Let’s see an example:

$ helm install --dry-run satellite banzaicloud-stable/satellite
NAME: satellite
LAST DEPLOYED: Sun Mar  3 03:03:24 2024
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
HOOKS:
MANIFEST:
---
# Source: satellite/templates/service.yaml
[...]

In essence, we see each involved definition file and potential errors.

5.7. Install Specific Version

By default, Helm installs the latest version of charts.

However, the install subcommand also provides a way to pick a specific chart version for installation:

$ helm install --version ^6.6.6 [...]

In this case, we indicate that we want to install the first version ^ at or above 6.6.6.

Let’s see the option in action. First, we check the available versions of the chart in question:

$ helm search repo satellite --versions
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
banzaicloud-stable/satellite    0.0.4                           A Helm chart for satellite
banzaicloud-stable/satellite    0.0.3                           A Helm chart for satellite
banzaicloud-stable/satellite    0.0.2                           A Helm chart for satellite

After that, we install version 0.0.3:

$ helm install banzaicloud-stable/satellite --generate-name --version 0.0.3
NAME: satellite-1709716660
LAST DEPLOYED: Sun Mar  3 03:03:24 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Let’s confirm the result by listing all releases:

$ helm list
NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS        CHART           APP VERSION
satellite-1709716660    default         1               2024-03-03 03:03:24.036660758 -0500 EST deployed      satellite-0.0.3

As expected, CHART is satellite-0.0.3 instead of the latest satellite-0.0.4.

6. Summary

In this article, we went through some advanced options for Helm chart installation and handling.

In conclusion, although charts are usually made as convenient as possible, customization and install process augmentation are possible and often desirable.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.