Introduction to Helm for Kubernetes

This article was originally posted on the mogenius blog by Cameron Pavey.

Kubernetes is highly flexible in how it allows you to compose your applications, but this flexibility can mean that building and deploying applications with multiple components can be quite complex. Helm, a self-described “package manager for Kubernetes,” alleviates some of this complexity.‍

In this guide, you’ll learn all you need to know to get started with Helm, including its core components and features and what the Helm workflow looks like. Finally, you’ll see how Helm streamlines Kubernetes DevOps to equip your team for better efficiency.

What Is Helm?

Helm acts as a layer of abstraction on top of your typical Kubernetes workflow. Rather than manually applying manifests when you want to deploy or modify an application, you can use the Helm CLI client to create, find, install, modify, and uninstall charts. In Helm’s terminology, a chart is a collection of files that represents a Kubernetes application (called a release) by describing all the necessary related resources. The application that a chart describes can range from simple single-pod applications to more complex applications with multiple interconnected pods.‍

Charts are declared as files in a directory tree that can either be used as-is or subsequently packaged into versioned .tgz archives, ready for distribution. In a parent directory, a chart consists of several key files and directories:

• Chart.yaml: A YAML file containing information about the chart.
• values.yaml: The default configuration for the chart.
• charts/: A directory containing any charts upon which this chart depends.
• crds/: A directory containing any custom resource definitions.
• templates/: A directory of templates that will be combined with values to generate valid Kubernetes manifests.

Noteworthy Helm Features

Helm has several features that help you manage your Kubernetes applications more efficiently.‍

Templates and Value Substitution

Often, you will need to create dynamic templates that can be configured depending on how the application will be used. Helm handles this by allowing you to define values in your values.yaml file, which can then be used in your templates through a special templating syntax.‍

For instance, consider a values.yaml file like this:

color: red

You could use this value in a template like so:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data: 
  color: {{ .Values.color }}‍

Using templated values this way means you can control this value without directly modifying the manifest template.

Release Management and Versioning

As a package manager, one of Helm’s responsibilities is the release and version management of packages. While you will typically use the latest version when installing a chart, Helm package archives are versioned, so it is possible to specify a particular version of a package, much like other package managers you may be familiar with.‍

This means that if you maintain Helm charts, you can make incremental updates and publish new versioned archives as needed, while the old ones can remain available to have historical records or for legacy support.

Dependency Management

One of Helm’s benefits is its ability to help you install complex applications without manually setting everything up.‍

Complex applications often require a number of dependencies. If you were to set up an application from scratch, you would need to declare and manage the dependencies yourself.‍

Helm, however, has built-in dependency management: a chart declares its dependencies, and these will be set up and configured when the release is created.‍

Rollback Capabilities

If something goes wrong during a release, Helm makes it easy to revert to your previous working configuration through rollbacks.

Each time you install, upgrade, or roll back a release, your release’s revision number is incremented by 1. You can use this revision number to revert to a previous version of your release like so:

# helm rollback [RELEASE] [REVISION]
helm rollback my-release 1‍

To determine which revision to roll back to, you can view the revision history of a given release:‍

$ helm history my-release  
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION  
1               Tue Sep 10 09:26:54 2024        deployed        wordpress-23.1.12       6.6.1           Install complete

How Does Helm Work?

Helm offers many options, and trying to understand them all at once can be overwhelming. However, you don’t need that to get started. You only have to know how Helm’s core features can be used together to form a workflow:‍

• ‍Chart creation and packaging: If you’re packaging your own application, the first step is to create the necessary files. This can be done via helm create NAME,which will generate some boilerplate files for you to modify. Once your application is configured, you can create a versioned archive if you want to distribute it.
• ‍Finding existing charts: Rather than packaging your own applications, you can also use Helm to find and download existing charts of other applications. You can use these charts to install and configure an application and its dependencies.
• ‍Template rendering process: As part of the installation process, Helm combines your chart, templates, and values to render your templates as Kubernetes manifests, ready to be applied to your cluster.
• ‍Interaction with the Kubernetes API: With the rendered manifests on hand, Helm interacts with the Kubernetes API server to apply the manifests and create or update any resources necessary for your release.‍

Getting Started with Helm

There are several ways to install Helm, including binary release, install scripts, and package managers. Refer to the Helm documentation to select the best method for your needs.‍

Once you have Helm installed and a Kubernetes cluster to use it with, you can try out some common workflows.‍

Basic Helm Commands

To use Helm, you’ll issue commands via the CLI client. Helm has quite a few commands, but the following are essential ones you should be aware of:‍

# Install a chart
helm install <name> <chart>

# Install a chart while setting values on the command line (can specify multiple or separate values with commas)
helm install <name> <chart> --set key1=val1,key2=val2
# Run a test installation to validate chart
helm install <name> <chart> --dry-run --debug
# Upgrade a release
helm upgrade <release> <chart>
# Upgrade a release, or install it if a corresponding release does not already exist
helm upgrade <release> <chart> --install
# Add a repository from the internet:
helm repo add <repo-name> <url>
# Update information of available charts locally from chart repositories
helm repo update
# Download a chart as a versioned archive
helm pull <chart>‍

The official documentation has a handy cheat sheet with more common commands and their purposes.

Creating Custom Charts

If you want to use Helm for packaging and distributing your own applications, you will need to create a custom chart. To do this, run helm create my-chart, which creates a new directory containing generated boilerplate files. The following are key files to be mindful of here:‍

• Chart.yaml: This file contains metadata about your chart.
• templates/: This directory contains manifest templates for each resource your chart will create. This is where you can define any Kubernetes resources you want your custom chart to include.
• values.yaml: This file contains the configuration values that many of the default templates will use. Anything that should be configurable in your chart should be defined here.‍

Once you’ve modified your chart to suit your needs, you can install it directly from your my-chart/ directory by running helm install my-chart.It will run through the workflow above to render your templates before applying them to the Kubernetes cluster.‍

Finding and Using Existing Charts

You can use Helm to search for existing charts, either by searching the artifact hub or a repo.‍

For instance, if you wanted to install nginx you could search for it on the artifact hub using helm search hub nginx or by accessing the hub via the web. Viewing the entry on the web shows that you can install the chart with its default settings by running this command:‍

helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginx‍

If you want to view or modify the chart before installing it, use the helm pull command like so:‍

helm pull oci://registry-1.docker.io/bitnamicharts/nginx‍

This command downloads a versioned chart archive that you can view and modify as needed. You can also view the values supported by the chart to reveal any options you can modify and configure before installing:‍

helm show values oci://registry-1.docker.io/bitnamicharts/nginx‍

Specify any values you would like to change by defining them in a YAML file like my-values.yaml and pass it as an option when you install the chart, like so:‍

helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginx -f my-values.yaml‍

Deploying a Sample Application

Let’s now see how all of the above comes together when you install, upgrade, and roll back a simple application. A good example application to use for understanding Helm’s workflows is nginx; it needs no configuration, and it’s easy to tell whether it is working.‍

As mentioned, you can install the nginx chart directly from the artifact hub linked above, but adding the source repository and installing charts from there is closer to how you are likely to use Helm for internal application development. It is good to be familiar with both approaches, but the repository approach will be used here.‍

To add the Bitnami nginx repo, run this command:‍

helm repo add bitnami https://charts.bitnami.com/bitnami‍

You can search your repos for nginx charts like so:‍

$ helm search repo nginx
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION  
bitnami/nginx                           18.1.11         1.27.1          NGINX Open Source is a web server that can be a...  
bitnami/nginx-ingress-controller        11.4.1          1.11.2          NGINX Ingress Controller is an Ingress controll...  
bitnami/nginx-intel                     2.1.15          0.4.9           DEPRECATED NGINX Open Source for Intel is a lig...‍

To install a basic nginx release, you can use one of the charts listed by your search:‍

helm install my-nginx bitnami/nginx --version 18.1.11 --namespace my-nginx --create-namespace‍

This will install version 18.1.11 of the chart, which corresponds to version 1.27.1 of nginx. The --namespace my-nginx specifies the Kubernetes namespace into which to install the chart, and the --create-namespace option creates the namespace if it does not already exist. You can omit these options if you prefer, but it's good to know them since they give you more control over how your applications are installed.‍

Once this command is done running, you can confirm whether the release has been successfully installed via kubectl:‍

$ kubectl get all -n my-nginx
NAME                            READY   STATUS    RESTARTS   AGE  
pod/my-nginx-546f4bccc7-pvmt2   1/1    Running   0          11m
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE  
service/kubernetes   ClusterIP      10.152.183.1    <none>       443/TCP                    2d11h  
service/my-nginx    LoadBalancer   10.152.183.65   <pending>   80:32399/TCP,443:31390/TCP   13m
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE  
deployment.apps/my-nginx   1/1    1            1           13m
NAME                                DESIRED   CURRENT   READY   AGE  
replicaset.apps/my-nginx-546f4bccc7   1         1       1       13m‍

Several resources have been created to support the release, even for this basic application. This is one of Helm’s key advantages — it manages all the resources and dependencies for you.‍

Suppose you want to change some of the values in the nginx chart. You can view a list of all the values available by running:

helm show values bitnami/nginx‍

There are many values you can configure, and one of them is replicaCount, which corresponds to how many pods will be running for this release. You can modify your existing release to set new values. For good measure, you can also use a different version of the chart (in this case, an earlier version if you were already on the latest):

helm upgrade my-nginx bitnami/nginx --version 18.1.0 --set replicaCount=2‍

Once this command is done, you can view the impact with kubectl again:‍

$ kubectl get all -n my-nginx
NAME                            READY   STATUS    RESTARTS   AGE  
pod/my-nginx-7f9647978d-5j8rn   1/1    Running   0          26s  
pod/my-nginx-7f9647978d-8hdqd   1/1    Running   0          15s
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE  
service/kubernetes   ClusterIP      10.152.183.1    <none>       443/TCP                    2d11h  
service/my-nginx    LoadBalancer   10.152.183.65   <pending>   80:32399/TCP,443:31390/TCP   18m
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE  
deployment.apps/my-nginx   2/2    2            2           18m
NAME                                DESIRED   CURRENT   READY   AGE  
replicaset.apps/my-nginx-546f4bccc7   0         0       0       18m  
replicaset.apps/my-nginx-7f9647978d   2         2       2       18m‍

Similarly, you can view the release history in Helm, which lists each revision your release has gone through:‍

$ helm history my-nginx
REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION  
1               Tue Sep 10 22:10:05 2024        superseded      nginx-18.1.11   1.27.1          Install complete  
2               Tue Sep 10 22:11:02 2024        deployed        nginx-18.1.0    1.27.0          Upgrade complete‍

If you want to undo some changes you’ve made to a release, it’s as simple as running the following:‍

helm rollback my-nginx 1‍

This command reverts the release to the specified revision. You can confirm the revert through kubectl and helm history:‍

$ kubectl get all -n my-nginx
NAME                            READY   STATUS    RESTARTS   AGE  
pod/my-nginx-546f4bccc7-5bm62   1/1    Running   0          56s
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE  
service/kubernetes   ClusterIP      10.152.183.1    <none>       443/TCP                    2d11h  
service/my-nginx    LoadBalancer   10.152.183.65   <pending>   80:32399/TCP,443:31390/TCP   23m
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE  
deployment.apps/my-nginx   1/1    1            1           23m
NAME                                DESIRED   CURRENT   READY   AGE  
replicaset.apps/my-nginx-546f4bccc7   1         1       1       23m  
replicaset.apps/my-nginx-7f9647978d   0         0       0       22m‍

How Helm Streamlines Kubernetes DevOps

As you’ve seen, Helm offers powerful capabilities over your standard Kubernetes toolkit, making deploying and managing Kubernetes applications simpler.

When used effectively, Helm can streamline both the development and operation of your applications. Helm offers the following benefits for developers of Kubernetes applications:‍

• Packaging: You can package an entire Kubernetes application into a single unit rather than a loose collection of manifests.
• Version management: Helm provides easy, built-in version management functionality for your charts.
• Templates: The combination of templates and values gives you an effective way to customize your application for deployment in different environments.
• Dependencies: Helm streamlines the complexity of managing dependencies between different components of your application.
• Reuse: You can create reusable charts for common application components and patterns you want to share between multiple applications.‍

Once applications have been developed and are ready to be deployed and operated, Helm also offers advantages for operations:‍

• Consistency: Helm gives you a consistent, standard way to manage the deployment of your applications across many environments. It also provides a consistent mechanism for applying things like security best practices, environment configuration, and settings across deployments.
• Upgrades and rollbacks: Helm’s upgrade and rollback functionality makes it easy and low-risk to upgrade applications, change values, and revert changes if something goes wrong. This reduces the effort and complexity involved in modifying running applications.
• Management: Helm’s dependency management means applications are essentially plug-and-play, without needing to ensure all your dependencies are configured and ready to go in advance. This greatly simplifies the process of deploying new application instances.‍

Wrapping Up

Helm, a powerful package manager for Kubernetes applications, provides new functionality for managing larger-scale application deployments on top of the existing Kubernetes API server and kubectl functionality. Features like templates with value substitution, seamless upgrades and rollbacks, fully managed dependencies, and versioned package archives fill the gaps needed to take Kubernetes from a container orchestrator to an out-of-the-box application platform.‍

Even though tools like Kubernetes and Helm provide powerful capabilities for scalable cloud-native operations, complexity can be a burden for development teams. mogenius, as a self-service solution, bridges the gap and allows developers to safely deploy and manage applications without deep Kubernetes expertise. The internal developer platform comes with a built-in Helm manager that enables teams to manage Helm repositories, charts, and releases on clusters with a comprehensive interface. You can even sign up for free and deploy your first Helm chart effortlessly.