What is Helm and why is it important for Kubernetes deployments?
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.
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:
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.
│ ├── deployment.yaml
│ ├── rbac.yaml
│ └── service.yaml
File structure of a Helm chart
Related: Getting Started with Rancher
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
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.
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.
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.
helm install demo-app
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
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.