Helm charts tutorial and examples

Because Kubernetes makes container-orchestration incredibly easy, it’s become a mainstay in the cloud-native ecosystem, but dealing with Kubernetes objects can be complex.

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

DevOps engineers frequently use package managers like yum, Homebrew, and Chocolatey to install software.

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:

1. Deploying Kubernetes packages through a single CLI command. If you have a dependency on other charts, you can include that as well.
2. Helm allows you to customize application configurations during deployment so that you can reuse one Helm Chart across multiple environments.
3. It makes it easy to streamline CI/CD pipeline for Kubernetes workloads.
4. 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.
5. 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

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:

1. By chart reference: helm install mymaria example/mariadb
2. By path to a packaged chart: helm install mynginx ./nginx-1.2.3.tgz
3. By path to an unpacked chart directory: helm install mynginx ./nginx
4. By absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz
5. 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.

kubectl get all

You’ll notice from the output above that Helm has created the service, Pod, deployment, and replica set for us.

Run the helm list command to list down the deployed or failed releases.

$ helm list

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 values.yaml.

For example, maybe you want to limit the amount of hardware resources your application can utilize. You can add the following changes in your values.yaml file.

If you would like to change the imagePullPolicy to Always from the default IfNotPresent add the following changes to your values.yaml file.

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 helpers.tpl file.

Use Helm functions to simplify

Helm functions simplify operations inside template files. We typically combine it with pipelines, and you can control flow in your Helm templates.

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.

Conclusion

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.

Airplane Views makes it easy to monitor your applications and make changes quickly. Airplane offers an extensive template and component library that makes it easy to get started.

To try it out and build your first dashboard or complex workflow in minutes, sign up for a free account or book a demo.