Introduction to Helm for Kubernetes

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:

‍

‍

‍

You could use this value in a template like so:

‍

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:‍

‍

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

‍

‍

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:

‍

‍

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 nginxyou could search for it on the artifact hub using helm search hub nginxor 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:

‍

‍

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

‍

‍

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:

‍

‍

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:

‍

‍

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:

‍

‍

You can search your repos for nginx charts like so:

‍

‍

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

‍

‍

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:

‍

‍

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:

‍

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):

‍

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

‍

‍

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

‍

‍

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

‍

‍

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

‍

‍

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 empower developers to build better cloud-native applications, access to easy-to-use Kubernetes environments remains a blocker for many teams. Kubernetes environments can be difficult to set up and costly to maintain, especially if you want to allow developers to create new clusters as needed rather than working with a set of static clusters. Self-service, managed Kubernetes environments provided by mogenius help to eliminate needless complexity and empower developers to be as effective as possible.

‍