In this article, we will talk about Helm the Kubernetes Package Manager. If you need a quick review of Kubernetes concepts you can take a look at our previous article.
Kubernetes, a practical introduction
This is a beginner practical guide where we will be learning some of the key Kubernetes concepts and creating our first…
What is a Package Manager?
Before we get into what Helm is, we need to take a high-level overview of what a Package Manager is.
A Package Manager is a collection of tools that automates the process of installing, upgrading, configuring and removing software. It also deals with version control and dependency management.
There are several PMs. To name a few of them:
- Homebrew Package Manager for OSX, based on git
- APT is the Package Manager used for Debian, Ubuntu and related Linux Distributions
- YUM another Linux PM
- Scoop for Windows operating systems
Package Managers typically maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites. They work closely with software repositories, binary repository managers, and app stores.
What is Helm and why we need it?
Per the official docs:
Helm is a tool for managing Kubernetes packages called charts
So, essentially Helm is a package manager for Kubernetes. If you are a beginner at Kubernetes, you might not see its benefits for simple applications. But Kubernetes can become very complex with all the objects you need to handle ― such as ConfigMaps, services, pods, Persistent Volumes ― in addition to the number of releases you need to manage. This is where Helm comes into the picture to help us.
Per the official documentation, Helm has three main concepts:
- The chart is a bundle of information necessary to create an instance of a Kubernetes application
- The config contains configuration information that can be merged into a packaged chart to create a releasable object.
- A release is a running instance of a chart, combined with a specific config.
Apart from charts, configs, and releases, Helm 2 has two major components. The Helm client and the Tiller server.
The Helm client is a command-line tool for end-users. It runs on the users local machine.
The Tiller server is an in-cluster server that interacts with the Helm client, and interfaces with the Kubernetes API server. Some of the major responsibilities of Tiller are:
- Listening for incoming requests from the Helm client
- Combining a chart and configuration to build a release
- Installing charts into Kubernetes, and then tracking the subsequent release
- Upgrading and uninstalling charts by interacting with Kubernetes
In summary, the client is responsible for managing charts, and the server is responsible for managing releases.
Since Helm 3 was released, the Tiller server was replaced by the Helm library. Instead of the client-server model of Tiller, Helm became a Kubernetes client; that removes layers of complexity but still gives operators the tools they need. This was done to simplify the Helm security model.
At this point, you might be tired of reading about Helm concepts and asking when are we going to see it in action?
Note: this is a promotional link, so you will receive $100 USD for 60 days
Helm installation is straight forward. For Mac, using Homebrew just do
brew install helm
For other operating systems, you can follow the steps in the official documentation.
To verify that the installation was successful, we can perform a helm search. Since version 3, Helm allows you to search for charts in Helm Hub using a command like
helm search hub wordpress
or you can also search in your registered repositories using the repo command
helm search repo wordpress
this last command is going to return an error as we didn’t add any Helm repository yet.
Per the official Helm docs:
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Let’s start deploying our first WordPress chart. First, we will add a charts repository
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
Then, we search for the WordPress available charts
helm search repo wordpress
From the result, we pick up the chart name stable/wordpress and
helm install stable/wordpress --generate-name
And that’s it, after a couple of minutes you should have a new WordPress ready :)
The previous command will return a couple of instructions on how to verify the created resources. The command to get the external IP of the WordPress site is like
kubectl get svc --namespace default -w wordpress-1583840363
Results will be like
To access the WordPress admin page go to http://<your-external-ip>/admin
Finally, if we want to clean up the generated resources we run
helm uninstall wordpress-1583840363
Creating our own chart
We already saw the power of Helm for releasing a new WordPress with just one command. Now, we are going to create our own chart for our application. To do that, we are going to use the assets created in our previous post to deploy a Node.js API.
First clone the repository, move to the project root directory and run
helm create node-starter
This will create a new node-starter folder within the project with the following files
node-starter (master) $ ls -ltr
Chart.yaml # Information about your chart
values.yaml # The default values for your templates
templates/ # The template files
charts/ # Charts that this chart depends on
To customize our helm chart configuration and be able to deploy our app, we will change deployment.yaml, values.yaml, and service.yaml.
In the deployment.yaml descriptor, we will change the container port to 3030. The liveness probe and readiness probe paths will be changed to /api-docs/
In values.yaml, we changed the image, tag and service type
Finally, for service.yaml we updated it with the targetPort and the nodePort
When we complete with the YAML files updates, we can install our Helm chart
helm install node-starter ./node-starter
To verify our release status
At this point, we will have our Node.js API deployed in Kubernetes using Helm. To get the public URL to connect to the API
kubectl get nodes -o wide
Pick up the EXTERNAL-IP and add /api-docs/ to the end
As you can see, the port being used is 30011, that is the one we set in the service.yaml file.
In this Helm introductory guide, we review some of the main concepts of this Kubernetes Package Manager. We talk about charts and some of the differences that were introduced in Helm 3. We go through a practical example of deploying WordPress with just one command. And finally, we end up creating our own Helm chart.