What is Helm?

Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package.

In a microservice architecture, you create more microservices as the application grows, making it increasingly difficult to manage. Kubernetes, an open source container orchestration technology, simplifies the process by grouping multiple microservices into a single deployment. Yet managing Kubernetes applications across the development lifecycle brings its own set of challenges, including version management, resource allocation, updating, and rollbacks.

Helm provides one of the most accessible solutions to this problem, making deployments more consistent, repeatable, and reliable. In this article, you’ll learn about Helm and its use cases, as well as how to decide if you should adopt it for your Kubernetes projects.

Simplifying Kubernetes management with Helm

A container is a lightweight software component that bundles an application and its dependencies into a single image file. Containers are portable between different platforms, leading to faster application startup and easy scaling.

Kubernetes deploys using YAML configuration files. For complex deployments with frequent updates, it can be difficult to keep track of all the different versions for these files. Helm is a handy tool that maintains a single deployment YAML file with version information. This file lets you set up and manage a complex Kubernetes cluster with a few commands. In the following sections, we will review the different components of Helm and how they help to simplify Kubernetes management.

Helm Charts

A Helm chart is a package that contains all the necessary resources to deploy an application to a Kubernetes cluster. This includes YAML configuration files for deployments, services, secrets, and config maps that define the desired state of your application.

A Helm chart packages together YAML files and templates that can be used to generate additional configuration files based on parametrized values. This allows you to customize configuration files to suit different environments and to create reusable configurations for use across multiple deployments. Additionally, each Helm chart can be versioned and managed independently, making it easy to maintain multiple versions of an application with different configurations.

How Helm works

The Helm application library uses charts to define, create, install, and upgrade Kubernetes applications. Helm charts allow you to manage Kubernetes manifests without using the Kubernetes command-line interface (CLI) or remembering complicated Kubernetes commands to control the cluster.

Consider a practical scenario where Helm is helpful. Suppose you want to deploy your application in a production environment with ten replicas. You specify this in the deployment YAML file for the application and run the deployment using the kubectl command.

Now, run the same application in a staging environment. Assume that you need three replicas in staging and that you will run an internal application build in the staging environment. To do this, update the replicas count and the Docker image tag in the deployment YAML file and then use it in the staging Kubernetes cluster.

As your application becomes more complex, the number of YAML files increases. Eventually, the configurable fields in the YAML file also increase. Soon, updating many YAML files to deploy the same app in different environments becomes hard to manage.

Using Helm, you can parameterize the fields depending on the environment. In the previous example, instead of using a static value for replicas and Docker images, you can take the value for these fields from another file. This file is called values.yaml.

Now, you can maintain a values file for each environment with the proper values for each. Helm helps you decouple the configurable field values from the actual YAML configuration.

Helm repositories

The Helm repository is where you can upload Helm charts. You can also create a private repository to share charts within your organization. Artifact Hub is a global Helm repository that features searchable charts that you can install for numerous purposes. In short, Artifact Hub does for Helm charts what Docker Hub does for Docker images.

Using Helm for deployments and rollbacks

Once the Helm chart is created, deploying an app is easy. To deploy all the Kubernetes resources, you need to run only a couple of Helm commands.

Consider a practical example. You have your application running in a Kubernetes cluster deployed using Helm charts. Now you want to configure a monitoring solution like Prometheus for your application. You have two options:

• Create all the deployments and services for the Prometheus application from scratch. This is a time-consuming task.
• Search for a Prometheus chart on Artifact Hub, update the configuration according to your requirements, and install it. This process is like to using existing Docker images from Docker Hub in the FROM statement of a Dockerfile.

You can install any Helm chart using these steps:

1. Register the Helm repository locally to help the Helm library identify the location to pull the Helm chart from.
2. Fetch all the Helm charts available in the repository that you have configured.
3. Update the values.yaml file (if required) and install a specific Helm chart using the helm install command.

Another advantage of using Helm is that it makes the rollback process easy.

Helm works at the application level, which means it maintains a state for a running application, also known as a release. Suppose you deployed a new version of your application that did not work as expected. Using the helm rollback command, you can revert to the previous stable release. This command rolls back all the deployments, services, and Kubernetes resources.

Without Helm, rollbacks would be difficult. You must perform a rollback for each Kubernetes resource, which can make it hard to manage complex applications.

Helm and CI/CD

Helm plays a vital role in making Kubernetes applications easier to build and test in a continuous integration and delivery (CI/CD) pipeline. It can automatically deploy an application in any environment and reduce build times. To get more flexibility in your build and test environments, you can use a self-hosted runner for your pipelines.

CircleCI’s self-hosted runners allow you to run CI/CD jobs in an environment you manage. This environment can be a standalone virtual machine or an entire cluster like Kubernetes. With container runner, you can use Helm charts to deploy containerized workloads to a private Kubernetes cluster and scale your environment to accommodate any level of demand.

Pros and Cons of using Helm

There are some scenarios where using Helm is beneficial — and others where Helm is not well-suited to your use case. This section reviews use cases where Helm is and is not helpful and highlights a few signs that your organization would benefit from using Helm.

When to use Helm

Helm is helpful when your project uses Kubernetes to run complex applications with many microservices. Using Helm, you can easily automate the deployment and management of the application, reducing the amount of manual work and improving the reliability and stability of the system. Helm also provides access to an extensive repository of preconfigured packages, making it easy to add new features and functionality to the application.

By organizing the application’s components into modular charts that you can easily install and upgrade, Helm simplifies the process of managing application components. It can reduce the amount of manual work required to maintain the application and helps you avoid errors and inconsistencies that can arise when managing complex systems manually.

Helm also supports the deployment of containers across multiple environments, such as development, staging, and production, making it easy to manage the lifecycle of containers throughout the development process.

When Helm does not excel

Helm is not well-suited to projects where a single container needs to be deployed on a server. In this case, using Helm to manage the deployment of the container would be unnecessary and could even add complexity to the process. Since Helm is designed to manage multiple container deployments as a single unit, it would not be helpful in this scenario.

If you have a small number of Kubernetes applications and can manage them manually without needing a package manager, using Helm may not provide significant benefits.

Finally, if your organization has strict security policies that prevent using third-party tools like Helm, then it may not be possible to use Helm in your environment.

When should you adopt Helm?

There are several indicators that a project could benefit from using Helm. For example, suppose your project involves multiple Kubernetes applications that must be managed and deployed together. In that case, Helm can help by allowing you to package these applications into a single chart, making it easier to manage and deploy them together.

If your project involves frequent updates and deployments of Kubernetes applications, Helm can help by providing tools for managing the lifecycle of your applications. This includes their deployment, updates, and rollbacks. As a result, application updates can be managed and deployed more easily.

Finally, if your project involves multiple teams or contributors who need to collaborate on the development and deployment of Kubernetes applications, Helm can help by providing versioning and sharing capabilities for your charts. It makes it easier for teams to collaborate and maintain consistency across deployments.

Configs

The config contains application configurations that you usually store in a YAML file. Resources in the Kubernetes cluster are deployed based on these values.

Releases

A running instance of a chart is known as a release. When you run the helm install command, it pulls the config and chart files and deploys all the Kubernetes resources.

Architecture

Now that you understand these Helm concepts, here is a look at Helm’s architecture. Helm’s architecture has two main components: client and library.

A Helm client is a command-line utility for end users to control local chart development and manage repositories and releases. Just like using the MySQL database client to run MySQL commands, you use the Helm client to run Helm commands.

The Helm library does all the heavy lifting. It contains the actual code to perform the operations specified in the Helm command. The combination of config and chart files to create any release is handled by the Helm library.

The Helm architecture has improved significantly between versions 2 and 3. Version 2 used a Tiller server to mediate between the Helm client and the Kubernetes API server. It kept track of all the resources created using Helm. In favor of a client-only architecture, version 3 removed the Tiller server, instead using a direct API connection to interact with the Kubernetes API server.

Find out more here.