Helm automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining configuration files into a single reusable package. In short, Helm is a package manager for Kubernetes. Automating this work helps developers working with microservices.
In a microservices 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. But 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, and how to decide if it will work for your Kubernetes projects.
Simplifying Kubernetes management with Helm
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 how Helm components simplify Kubernetes management.
Helm charts
A Helm chart is a package that contains all the resources you need to deploy an application to a Kubernetes cluster. This package has YAML files for deployments, services, secrets, and config maps that set up your application as needed.
A Helm chart combines YAML files and templates to create configuration files based on specific parameters. You can customize these configuration files for different environments and create configurations that are reusable across multiple deployments. Additionally, you can version and manage each Helm chart individually, making it easier to maintain multiple versions of an application with different configurations.
Configs
The config contains application configurations that you usually store in a YAML file. The Kubernetes cluster deploys resources based on the config values.
Releases
A release is a running instance of a chart. 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. The architecture has two main components: client and library.
A Helm client helps users control chart development, manage repositories, and release software using the command line. 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 Helm library handles the combination of config and chart files to create any release.
The Helm architecture improved significantly between versions 2 and 3. In version 2, there was a Tiller server that connected the Helm client to the Kubernetes API server. It kept track of all the resources created using Helm. Version 3 no longer has the Tiller server. It now uses a direct API connection for client-only architecture. This allows it to interact with the Kubernetes API server.
How Helm works
The Helm application library uses charts to define, create, install, and upgrade Kubernetes applications. You can use Helm charts to manage Kubernetes manifests without using the Kubernetes command-line interface (CLI). You don’t need to remember 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 update, change the number of replicas and the Docker image tag in the deployment YAML file. After making these changes, apply the file to 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. Instead of using a fixed value for replicas and Docker images, you can get these values 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 you have created the Helm chart, deploying an app is easy. To deploy all the Kubernetes resources, you need to run only a couple of Helm commands.
Imagine 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
FROMstatement of a Dockerfile.
You can install any Helm chart using these steps:
- Register the Helm repository locally to help the Helm library identify the location to pull the Helm chart from.
- Fetch all the Helm charts available in the repository that you have configured.
- Update the
values.yamlfile (if required) and install a specific Helm chart using thehelm installcommand.
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 is important for making Kubernetes apps easier to build and test in a 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. You can use container runner to deploy workloads to a private Kubernetes cluster using Helm charts. This allows you to scale your environment based on demand.
Pros and cons of using Helm
Some scenarios benefit from using Helm, while other use cases aren’t as well-suited for it. This section discusses when Helm is helpful and when it is not. It also describes signs that your organization could benefit from using Helm.
When to use Helm
Helm is helpful when your project uses Kubernetes to run complex applications with many microservices. With Helm, you can automate deploying and managing applications, reducing manual work and improving system reliability and stability. Helm gives access to many preconfigured packages, making it simple to add new features and functions to the application.
Helm helps manage application components by organizing them into charts for easy installation and upgrades. It reduces the amount of manual work needed to maintain the application. It also helps prevent errors and inconsistencies that can arise when managing complex systems manually.
Helm helps deploy containers in different environments like development, staging, and production. It makes managing containers during development easier.
When Helm does not excel
Helm is most helpful for managing many containers together. Helm does not work as well for projects that require deploying a single container on a server. In this case, using Helm may not be necessary and could add complexity to the process.
If you have only a few Kubernetes apps, you can likely handle them manually, without a package manager. Using Helm may not provide significant benefits.
Does your organization have strict security policies that prevent using third-party tools? If so, 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 instance, consider a project that includes multiple Kubernetes applications that require management and deployment as a cohesive unit. Helm makes it easier to manage and deploy applications by packaging them into a single chart for convenience.
If you update and deploy Kubernetes apps often, Helm tools can help manage your application lifecycle, including rollbacks.
If your project has many teams or people working together on Kubernetes apps, Helm can help. You can share and track different versions of charts, helping teams work together and keep things consistent when deploying.
Next steps
In this article, you learned about Helm and how it simplifies deployment in Kubernetes. You also learned about all the core concepts of Helm, like Helm charts, repositories, deployments, and more.
Helm is a valuable tool for managing the deployment of multiple containers as a single unit. Helm simplifies deploying complex microservice-based apps using a consistent deployment approach. Helm also manages container deployment in various environments. These capabilities make Helm an essential tool for organizations that rely on container-based applications.
With this knowledge, you’re ready to deploy your app in Kubernetes using Helm. Follow this quickstart guide to install Helm and create your first Helm chart. To further streamline your development and deployment process, consider adopting CI/CD in your organization. Sign up for a free CircleCI account to automate your project’s build, test, and deployment workflows and increase your delivery speed and reliability.
