A typical application deployed to Kubernetes will have objects like deployments, services, Pods, configmaps, secrets, hpa, ingress, etc., and with its declarative nature, you define everything through YAML files.
Now imagine having to manage and maintain the YAML files for each environment. That’s where Helm comes in. It’s a widely known package manager for your Kubernetes workloads. Helm Charts help you define, install, and upgrade complex Kubernetes applications.
In this article, you’ll learn how Helm Charts fit into a Kubernetes workflow and review examples for how they can be used to benefit your organization.
Why you need Helm
Helm is the only package manager specifically for Kubernetes applications. You can package your applications as a Helm Chart, and then install, update, and roll back your Kubernetes applications using Helm. In addition, you can use production-ready, pre-packaged charts for popular software like NGINX, MySQL, and MongoDB from a stable chart repository like Bitnami or ArtifactHUB.
What makes Helm architecture superior
The original version of Helm followed a client-server architecture, which required two separate installations; On the client-side, the CLI, and on the server-side, a component named Tiller. Because of some security concerns, Tiller was removed, and Helm v3 is a client-only utility.
Helm provides numerous features for Kubernetes applications including:
- Deploying Kubernetes packages through a single CLI command. If you have a dependency on other charts, you can include that as well.
- Helm allows you to customize application configurations during deployment so that you can reuse one Helm Chart across multiple environments.
- It makes it easy to streamline CI/CD pipeline for Kubernetes workloads.
- It simplifies the rollback of your Kubernetes applications in case of issues in deployment. Helm does this by automatically maintaining all the versions of your releases.
- Helm enables teams to automate the pre- and post-deployment actions with its CI/CD integration hooks.
How to use Helm charts in practice
Let’s begin by first installing Helm. You can install Helm on Windows, macOS, and Linux using standard package managers like Chocolatey, Homebrew, or APT.
On macOS, you can use the Homebrew command
brew install helm to install.
Or, on Windows, you can use
choco install kubernetes-helm to install using Chocolatey.
Helm also provides an installer script that will download the latest version for you.
After installing Helm on your operating system, verify the installation using
helm version. You will see the following output after running the command:
The following is a list of supported commands with Helm CLI:
Let’s install NGINX using a pre-packaged Helm Chart on your local Kubernetes cluster. Use
helm search repo chart-name to look for the chart in the local repository.
As you can see, the local helm repository is not updated, and it fails to find the chart. You can fix this by running the command
helm repo update.
Then rerun the command
helm search repo nginx to verify that you can now search for the NGINX Helm Chart.
$ helm search repo nginx
|NAME||CHART VERSION||APP VERSION||DESCRIPTION|
|bitnami/nginx||9.5.13||1.21.4||Chart for the nginx server|
|bitnami/nginx-ingress-controller||9.0.6||1.0.5||Chart for the nginx Ingress controller|
|bitnami/kong||4.1.9||2.6.0||Kong is a scalable, open source API layer (aka ...|
You should see all the charts have NGINX in their name.
Now, choose the
bitnami/nginx chart name and install it using the
helm install nginx bitnami/nginx command.
There are five different ways you can express the chart you want to install:
- By chart reference:
helm install mymaria example/mariadb
- By path to a packaged chart:
helm install mynginx ./nginx-1.2.3.tgz
- By path to an unpacked chart directory:
helm install mynginx ./nginx
- By absolute URL:
helm install mynginx https://example.com/charts/nginx-1.2.3.tgz
- By chart reference and repo url:
helm install --repo https://example.com/charts/ mynginx nginx
Before you continue with installing the Helm Chart, make sure you have a local Kubernetes cluster up and running.
The following is the output of running
helm install nginx bitnami/nginx:
Verify the installation by running
kubectl get all
You’ll notice from the output above that Helm has created the service, Pod, deployment, and replica set for us.
helm list command to list down the deployed or failed releases.
$ helm list
|nginx||default||1||2021-11-17 01:12:56.74093 +0530 IST||deployed||nginx-9.5.2||1.21.1|
Since you are using minikube as a local Kubernetes cluster, you can use the
minikube service nginx command to expose the service for external access.
$ minikube service nginx
🎉 Opening service default/nginx in default browser...
Use the URL mentioned in the preceding output to access your application:
Now you have deployed a pre-packaged Helm Chart.
You can also create a Helm Chart specific to your application using the
helm create command. Your output would be:
An NGINX image is configured by default, but you can tweak all the configurations based on your needs by editing the
values.yaml file and installing it using the
helm install command. Template files under the
/templates directory contain the placeholders. Their values are replaced by
For example, maybe you want to limit the amount of hardware resources your application can utilize. You can add the following changes in your
If you would like to change the
Always from the default
IfNotPresent add the following changes to your
Helm tips and best practices
Before incorporating Helm Charts into your Kubernetes workflow, keep in mind the following best practices to ensure your processes are efficient and practical.
Use Heml template to verify
To make sure that everything is as expected before deploying your chart to the target Kubernetes cluster, use the
helm template command. This will render chart templates locally and display the output.
Any values that would normally be looked up or retrieved in-cluster will be faked locally, and the command will finally display each YAML file created by all the templates.
Use Heml lint to test
You can use
helm lint to run a series of tests to verify that the chart is well-formed. If the linter encounters things that will cause the chart to fail installation, it will emit ERROR messages. If it encounters issues that break with convention or recommendation, it will emit WARNING messages.
Label your resources
Labels can be used to find your resources created by Helm releases instantly. The easiest way to define labels is using the
Use Helm functions to simplify
For example, if the value for an image tag is not provided in a template file, it will use the chart app version as an image tag. Here
default is the function.
Limitations of Helm charts
As with any new tool, there is a learning curve involved with Helm. It’s not easy to create and deploy your first chart.
Charts are also an extra piece of code that you have to manage and take care of. This includes the overhead to manage, maintain, and store in a chart repository. Helm can be excessive for simpler deployments.
Maintaining charts alone may not be a significant issue, but using charts managed by others can be. Are you comfortable using charts managed by third parties? What if the chart uses an old image with known vulnerabilities? Keep these factors in mind before using Helm.
In addition, troubleshooting issues on an application with a lot of Kubernetes resources can be difficult with Helm.
A Helm alternative
If you want to consider a Helm alternative, then Kustomize is worth exploring. It’s a Kubernetes native configuration management open-source tool. Contrary to Helm, Kustomize introduces a template-free way to customize application configuration. You don’t have to install it separately, as it’s baked into
kubectl. You can use it by simply supplying the -k flag with the
kubectl apply command.
With Helm, deploying and reverting changes for your Kubernetes workloads is as easy as pressing a button. If you are a DevOps engineer trying to install applications developed internally or with third-party software like databases, you should consider Helm. It’s easier to share applications packaged as charts with others in the organization, and you can deploy Kubernetes packages through a single CLI command.
If you're looking for an internal tooling solution that makes it easy to build complex workflows and UIs, then check out Airplane. Airplane is the code-first platform for building internal tools. The basic building blocks of Airplane are Tasks, which are functions that anyone on your team can use. Airplane also offers Airplane Views, a React-based platform for building complex UIs.