Helm is the first and the most popular package manager for Kubernetes. It allows DevOps teams to version, distribute, and manage Kubernetes applications.
Although one can live with standard kubectl commands and Kubernetes manifest YAML files, when organisations work on microservice architecture — with hundreds of containers interacting with each other — it becomes a necessity to version and manage the Kubernetes manifests.
Helm is now becoming a standard for managing Kubernetes applications and a necessary skill for anyone working with Kubernetes.
The obvious question is: Why do we need Helm? Let’s find out.
A Docker image forms a template for a Docker container. You can use one Docker image to create multiple containers from it.
The same wasn’t true for Kubernetes. You can’t reuse the manifest files easily. For instance, if you have to deploy two instances of PostgreSQL, you have to duplicate your manifest files.
Helm helps you manage it using charts and variables. You just need to create a generic PostgreSQL chart and use variables to deploy different instances in the form of releases.
Developers initially used to create Kubernetes manifests using YAML files, which they then stored in source-code repositories.
The issue with this approach is the manifest isn’t semantically versioned. A source-code repository isn’t the right place to version your releases. You should always version your releases as packages. Helm solves this problem by packaging your application in a Helm chart, which makes it possible to have multiple versions of your chart stored in the Helm repository, and you can quickly rollout or rollback a release without building from a source.
For Docker images, you can share your images on DockerHub — the same wasn’t possible for Kubernetes. With public Helm repositories like Kubernetes charts, this is now possible. Public Helm repositories allow the reuse of Kubernetes applications, enable vendors to provide standard Helm charts for consumers, and make life simple for both of them.
With Helm, you can run simple commands, such as helm install and helm del, to install and delete releases.
You don’t have to worry about finding the manifest files and running kubectl delete. Everything is so dynamic with Helm.
Let’s take, for example, a LAMP stack. There’s an explicit dependency of Apache on MySQL. You shouldn’t install Apache without MySQL.
With Helm, you can add a dependency of MySQL on the Apache chart to allow this to happen, something you wouldn’t be able to do with pure Kubernetes manifests.
Helm allows chart developers to start with standard templates, and they customise them according to their application requirements.
Standard templates will enable them to meet the minimum standards of developing an application with Kubernetes. The manifest templates generated by Helm is of some quality, and developers learn from it.
I’ve introduced a lot of jargon in the previous section — let’s find out what they mean.
A chart is a Helm package. If you understand Linux, a Helm chart is the Kubernetes equivalent of an RPM or DEB. A Helm chart wraps up your Kubernetes manifests into dynamic templates with a chart version and all of the needed dependencies, which allows you to standardise and distribute your applications.
A Helm release is an instance of a Helm chart on a Kubernetes cluster. The Helm chart acts as a template for the release, while a release is an actual running Helm application.
You can use the same Helm chart to create multiple releases. Say, for instance, you want to install two separate PostgreSQL instances — you can use the PostgreSQL Helm chart to create two releases with different variables.
Helm repositories store Helm charts like Yum repositories store RPMs. Anyone who needs to install the application on Kubernetes can download the app from Helm repositories using simple Helm commands.
A Helm repository can run on any web server, and, therefore, it’s simple to host one. The traditional method involves creating an index.yaml file within the charts directory, which you create in the public folder of your web server, and updating the file manually when you push a chart into the repository. Below is an example structure of what the web-server directory structure looks like:
charts/
|
|- index.yaml
|
|- alpine-0.1.2.tgz
|
|- alpine-0.1.2.tgz.prov
However, mature organisations at the moment use some form of artifact repository manager, such as Nexus Repository Manager, which integrates with their CI/CD pipeline.
The three big concepts of Helm
A typical continuous integration and continuous deployment (CI/CD) pipeline with Docker and Helm looks like this:
DevOps engineers create Docker files and the required dependencies (along with a Helm chart of the application) and push it to a source-code repository.
The source-code repository has a post-commit hook to a CI/CD tool such as Jenkins, which:
It then updates the index with the latest package from Nexus using helm repo update and triggers Kubernetes to run a helm upgrade --install to either upgrade an existing release or install a new one based on the latest chart available in Nexus.
Nexus makes organising and managing repositories easy, as they provide support for multiple types of repositories for various technologies, such as Maven, Yum, Go, Python, npm, Docker, and many others.
For organisations that use Sonatype Nexus already, it makes sense for them to host their Helm repositories within Nexus.
Sonatype doesn’t officially support Helm repositories. However, there have been community efforts to build a capability for hosting Helm repositories.
One such project is here.
I’ll demonstrate how to use the project to enable Nexus to store Helm charts.
Identify the version of your Nexus installation, and use the correct version of the plugin using this table. Then, run the following commands to generate the plugin Jar file.
Copy the generated Jar from the nexus-repository-helm/target directory to the Nexus plugins directory at <nexus_dir>/system/org/sonatype/nexus/plugins/nexus-repository-helm/<plugin_version>/nexus-repository-helm-<plugin_version>.jar.
Edit the features.xml file to include the plugin in the Nexus configuration.
If you’re using Nexus 3.21 and newer, edit <nexus_dir>/system/org/sonatype/nexus/assemblies/nexus-cma-feature/3.x.y/nexus-cma-feature-3.x.y-features.xml.
For older OSS versions, edit <nexus_dir>/system/com/sonatype/nexus/assemblies/nexus-oss-feature/3.x.y/nexus-oss-feature-3.x.y-features.xml.
For older PRO versions, edit <nexus_dir>/system/com/sonatype/nexus/assemblies/nexus-pro-feature/3.x.y/nexus-pro-feature-3.x.y-features.xml.
Add the following lines marked with + to the file. Save the file, and restart Nexus.
If everything looks good, then Helm (hosted) and Helm (proxy) will be featured in the repository recipe.
Create a helm repository called helm-hosted on Nexus using the Helm (hosted) recipe.
Select recipe
Create repository
Helm-hosted repository
Now that we’ve successfully configured the helm-hosted repository on Nexus, it’s time to test it on your Kubernetes cluster.
Add the Nexus repository to your Helm config using the below command:
You can then access the Nexus repository using Helm.
To push your helm chart to Nexus, we’d first package the chart and then upload the chart using curl to the helm-hosted repository.
Browse the helm-hosted repository to see your asset uploaded.
Check the index.yaml file, and you’ll find it’s been autoupdated.
To install your Helm chart from Nexus, you need to update your local repo index with the latest packages on Nexus using helm repo update and then run helm install to create a new release from the Chart.
If everything goes well, Helm will download the chart from Nexus and install it on your Kubernetes cluster.