Helm 3: Basics.

Helm helps us cognitively simplify the rather unforgiving task of releasing new/updated applications on a Kubernetes cluster.

Theoretically, any new-ness that we want to target for our clusters should be a simple matter of using kubectl and its modules (like create, apply and edit) along with a YAML manifest (or manifests).

For simple applications, of course this is not a particularly difficult task but the minute we have a complex application architecture, with many moving pieces, the effort ratchets up quiet drastically, simultaneously increasing risk of failed production deployments.

This is where Helm is so useful as it can streamline deployments of complex applications on a Kubernetes cluster.

First off, why Helm?

Let's clarify WHY a Kubernetes application can be difficult to release.

To understand WHY Helm, we have to consider Kubernetes not as an orchestration tool but rather as an operating system. Any OS provides the necessary environment for executing user programs and needs the tools necessary to store, execute, and monitor the life cycle of a program.

Continuing on with this analogy of Kubernetes being an OS, it must also, like any OS, provide the tools needed to manage containers, all the way from downloading the correct image version, storing it, executing it and monitoring its health.

Most operating systems and development platforms are supported by a package manager:

• Linux uses apt-get and apt
• Windows uses Chocolatey and
• MacOS uses HomeBrew.
• Python Packages require pip.
• Java uses Maven.
• Node.js uses npm.

The job of these package manager is to make it easy to find, install, upgrade, and delete the programs on an operating system.

Similarly, the need for having this kind of package management for Kubernetes became more and more obvious and thus, Helm was born.

Among its many capabilities, Helm:

• Tells Kubernetes about the various package repositories available and also helps with searching through them to find what Kubernetes applications are available.
• Has the familiar install, upgrade, rollback and delete commands.
• Defines a method for configuring packages prior to installing them.
• Has tools for seeing what is already installed and how it is configured.
• Lets Kubernetes investigate the origins of the packages for security.

A typical application deployed on a Kubernetes cluster contains a number of moving pieces, as illustrated in Figure 1 below:

If we use kubectl (or other Kube-API server clients) for our application deployments, we will require a manifest for each of the moving pieces in Figure 1.

Typically, everytime there is a change in any of the moving pieces, a new updated manifest for it has to be created, and kubectl is re-employed to reflect the changes on the cluster.

Strictly speaking there is nothing wrong with using kubectl for manually updating various Kubernetes objects, but there are situations where using kubectl in this manner could increase the risk of a bad deployment if:

• There are any dependencies between the moving pieces that need to be processed sequentially. For example, a Secret may need to be deployed first, followed by a Pod, for the application to properly secure itself. Any deviation from the expected order could result in an insecure, or worse, and broken application deployment.
• There is ever a need to rollback to the previous version of the Secrets, which may require some remedial actions to be taken on other objects in the cluster as well. Making sure these actions follow some kind of sequence can become difficult, especially in complex application architectures.

Having developed an idea of the WHY, let's discuss the HOW.

Figure 2 shows how YAML manifests are executed upon through kubectl to update the state of a cluster.

If we used Helm instead of kubectl, the YAML files will get replaced with a Helm Chart.

The official Helm documentation website provides us with a useful definition of a Chart:

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.

This Chart is an aggregated definition of our entire application, and is used by Helm to produce the same kind of outcomes that we would have achieved using individual YAML manifests and kubectl.

As mentioned earlier, Helm can rollback applications to their previously deployed versions (or Chart Instances). Helm will store all the information about previous versions as a Secret inside the Kubernetes cluster.

Demo: Using Helm to manage an applications release on a Kubernetes Cluster.

Step 1: Download and install kubectl and Minikube

Follow the instructions provided online for both kubectl and Minikube. You could also choose KinD for setting up your cluster.

Step 2: Enable ingress on the cluster

Step 3: Add the clusters IP to /etc/host file (on Ubuntu) for name resolution.

Step 4: Install Helm

Helm installation is fairly straight forward.

We start with installing the Helm client.

• Go to Helm's official website.
• There are multiple ways in which to get the Helm binary. For this article, the Binary release for Linux amd64 was used.

Step 5: Add the official Helm Chart repository to the Helm installation

Step 6: Download a Helm Chart for MySQL Server.

Before doing this, confirm the existence of any MySQL related Kubernetes object.

Run the kubectl command in Figure 9 again.

Step 7 (Optional): Cleaning up Helm installed applications.

As a result of using Helm to install MySQL, pods and services were deployed as was confirmed using the script in Figure 11.

In addition, Helm will also store this Chart instance as a Kubernetes Secret (and these are used for rollback purposes, as mentioned earlier).

Cleaning up, therefore, is simply going to include removing the pods, services, secrets and other Kubernetes objects from the cluster.

We could do this manually of course, by using kubectl delete <entity type> <entity name> where:

• <entity type> could be one of pods, services, deployments and secrets
• <entity name> could be the name of the <entity type> being deleted

BUT...

we will use Helm to uninstall the Chart instance.

Confirm this was indeed done by executing commands in Figure 9 and Figure 11 once again.

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.