What is Helm and why is it important for Kubernetes deployments?

by Peyton Vaughn | Wednesday, Sep 19, 2018 | Kubernetes

The runaway success of Kubernetes has created an ecosystem of tools to simplify the complexity of application development and deployment.

The majority of these tools exist as open-source projects maintained by a community of enthusiasts. However some, due to their popularity and the importance of the role they fulfill, gain additional recognition through adoption by the Cloud Native Computing Foundation.

In this post I discuss Helm, selected by the CNCF as a package manager providing an easy way to manage and publish software on Kubernetes.

Why Helm?

Helm's initial release was the result of a combination of efforts by Deis (a container tooling company, now part of Microsoft) and Google. In June 2018, Helm was adopted as an official CNCF project.

CNCF recognition is important for two reasons:

• It opens the project's support to a larger open source community
• It effectively solidifies Helm as the standard for Kubernetes package management

While the problem of managing applications on Kubernetes can be complex, Helm itself is quite simple to use, if you understand a few key concepts:

Charts

A Helm chart is simply a collection of YAML template files organized into a specific directory structure. Charts are somewhat analogous to DEB and RPM files. However, since they are text-based, charts are versionable and simple to maintain with familiar SCM tools.

~>tree demo-chart/
demo-chart/
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── rbac.yaml
│   └── service.yaml
└── values.yaml

File structure of a Helm chart

Related: Getting Started with Rancher

Releases

Helm is more than just a format, it is also the tool used to install Helm charts.

Extending on the analogy above, to install NGNIX on a Debian-based system you would run apt install nginx. Similarly, to install NGINX to a Kubernetes cluster, you could simply run helm install nginx.

Each installation of a Helm chart to your cluster is referred to as a release. However, unlike traditional OS package managers, with Helm it's easy to have multiple releases installed to a single cluster, each with its own specific configuration.

Repositories

Helm charts can additionally be published to repositories. These can be private repos for internal use, or publically hosted, like hub.kubeapps.com. Again, like yum and apt, they can be searched to discover what's available.

helm search nginx
NAME                       	CHART VERSION	APP VERSION	DESCRIPTION                                       
stable/nginx-ingress       	0.23.0       	0.15.0     	An nginx Ingress controller that uses ConfigMap...
stable/nginx-ldapauth-proxy	0.1.2        	1.13.5     	nginx proxy with ldapauth                         
stable/nginx-lego          	0.3.1        	           	Chart for nginx-ingress-controller and kube-lego  
stable/gcloud-endpoints    	0.1.2        	1          	DEPRECATED Develop, deploy, protect and monitor...

Public Helm charts can be a great resource, both for quickly getting up and running, and experimenting with new technologies.

Why is Helm important for Kubernetes deployments?

At this point, it would be easy to think that Helm is just “yum for Kubernetes”. While it does fill that function, it can actually play a much larger role in optimizing an organization's CI/CD integration with Kubernetes.

As mentioned, each deployment of a chart is a Helm release. Helm automatically maintains a versioned history of your releases. If something goes wrong with a deployment, getting back to your previous state can be as simple as helm rollback RELEASE_NAME.

Helm also provides several CI/CD pipeline integration hooks, so you can configure actions to occur, for example, before installation begins, or after an upgrade has finished. You can even configure health checks for Helm to run and verify a deployment has completed successfully.

Related: Monitoring Kubernetes with Prometheus

Another distinguishing feature is the ability to provide application configuration during deployment. Not only can you specify the Kubernetes resources (deployments, services, etc.) that make up your application, but also environment-specific configuration for those resources. This allows the same Helm chart to be used across all of your environments.

For example, when deploying to production, a high number of replicas and persistent storage may be required. Conversely, a developer working on their laptop may only need a single instance of the app and no storage.

# Production
helm install demo-app
# Development
helm install --set replicas=1 --set persistence.enabled=false demo-app

In the production example, Helm will set the application's configuration from the values.yaml that is part of every Helm chart. This file would likely be maintained by your DevOps team, and versioned with your SCM. The developer is able to use the exact same deployment process in their local environment, overriding configuration as needed with a few CLI parameters.

This also has the benefit of lowering the learning curve for coders not yet familiar with Kubernetes. The need to understand Kubernetes resources and edit YAML files is replaced by an intuitive CLI. And since charts are easy to share (via code or Helm repositories), developers are able to leverage similar installation procedures across different parts of an organization's application stack. This eliminates the days of tedious (often OS-specific) dev environment setup for each and every stack component.

Can I bet on Helm?

The amazing momentum behind Kubernetes has certainly seen many supporting projects come and go as the community evolves. But the popularity and enthusiasm behind the Helm project has ensured that it will be the de facto package standard for some time. This year saw the first Helm Summit - a pretty strong testament to Helm's adoption.

It's also quite likely the full benefits of Helm remain to be discovered. When the deployment process for development and production are practically identical, collaboration between development and DevOps teams can only increase. Being able to deploy entire application stacks allows coders to focus more on actual development, and less on standing up development environments. Coders not having to worry about interacting with so many tangential code repositories helps foster a more microservices-oriented culture for an organization.

Regardless of what benefits remain to be discovered, Helm will continue to represent a fundamental shift in how Kubernetes applications are defined and managed.