Introduction to Helm

Requirements

• Basic knowledge of Kubernetes.
• Have Kubernetes installed.
• Have a cluster created.

All these requirements are explained in a previous article.

Helm is a package manager for Kubernetes, a tool to help us deploy applications. The main benefits are as follows:

• Managing complexity through _Charts_.
• Easy updates
• Easy portability
• System for managing _rollbacks_

Important concepts

There are three fundamental concepts in Helm:

• _Charts_: various YAML configuration files and certain templates that define how to instantiate a K8s application.
• _config_: as its name suggests, configuration information that can be combined with a _chart_ to create a _release_.
• _Release_: an instance of a _chart_ with a particular _config_

Architecture

Helm's architecture essentially has two parts: the client side and the server side:

Helm client

This is the command line from which we issue commands to be executed by the server, such as sending _charts_ to be installed, requesting information, or uninstalling a _release_.

Tiller

This is the server component, which in this case runs in a K8s cluster and communicates with the K8s API. It handles client requests, installs various _charts_, and performs other actions requested by the client.

 Structure of a _Chart_

package-name/
charts/
templates/
Chart.yaml
LICENSE
README.md
requirements.yaml
values.yaml

• charts/: directory of Charts that are dependencies of the Chart we are defining.
• templates/: directory containing templates that, combined with the values in values.yaml, generate valid manifest files for Kubernetes.
• Chart.yaml: configuration file with general information about the package, such as its name or version.
• LICENSE (optional): plain text file containing information about the license under which the package is distributed (e.g.: MIT, GNU GPL v3,…).
• README.md (optional): Markdown file with useful information (similar to the README in a git repository).
• requirements.yaml (optional): Chart dependency file.
• values.yaml: default configuration values for use by the templates (located in templates/).

Installing Helm

As mentioned earlier, Docker and Kubernetes are assumed to be installed on the machine you will be working on. In our example, we will work on a GNU/Linux system, specifically Ubuntu version 18.04. At least 2Gb of RAM and 10Gb of hard disk space are recommended.

Before starting, you need a Kubernetes cluster to install Tiller. We can check whether it is configured correctly by running:

# kubectl cluster-info

The response should look similar to this:

Kubernetes master is running at https://URL_VPS:6443
KubeDNS is running at https://URL_VPS:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

If there are any errors, K8s is not configured correctly. We recommend following the steps in this article up to and including the “Common” section.

If there have been no errors, we need to check whether the Context is correct with the following commands:

CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* kubernetes-admin@kubernetes kubernetes kubernetes-admin

In this case, the asterisk indicates that we are connected to the _kubernetes-admin@kubernetes_ cluster. You can switch between clusters with:

# kubectl config use-context NOMBRE_CONTEXTO

Now we can install Helm. The installation instructions are practically the same on other systems, since Helm's GitHub repository provides a script that simplifies installation:

# cd /tmp
# curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > instalacionHelm.sh

We grant execution permissions to the downloaded script and run it:

# chmod u+x instalacionHelm.sh
# ./instalacionHelm.sh

If everything ran normally and without errors, Helm should now be installed, displaying a screen similar to the following:

Downloading https://get.helm.sh/helm-v2.15.1-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
Run 'helm init' to configure helm.

Now it is time to configure Tiller. To do this, we will create a _serviceaccount_ so that it works correctly:

# kubectl -n kube-system create serviceaccount tiller

If it ran without errors, we need to add it to _cluster-admin_:

# kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

After installing it, we can start it to finish configuring it (creating configuration folders, adding the default repository,…) with the following command:

Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see:
https://docs.helm.sh/using_helm/#securing-your-helm-installation

 Example: Installing nginx

Let's look at deploying a basic web server (nginx) using Helm. This will help us understand how _Charts_ and their repositories work.

By default, helm adds a repository created by its developers. First, we will update it:

Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.

 To search for a _Chart_, we can use the helm search command, which, if we do not add any parameters, returns a list of all the _charts_ in the repository (the default one). Since we want to install _nginx_, we run:

NAME CHART VERSION APP VERSION DESCRIPTION
stable/nginx-ingress 1.24.4 0.26.1 An nginx Ingress controller that uses ConfigMap to store ...
stable/nginx-ldapauth-proxy 0.1.3 1.13.5 nginx proxy with ldapauth
stable/nginx-lego 0.3.1 Chart for nginx-ingress-controller and kube-lego
stable/gcloud-endpoints 0.1.2 1 DEPRECATED Develop, deploy, protect and monitor your APIs...

As you can see, none of the available _charts_ is for _nginx_. This is because it does not exist in the default repository, which is why it cannot be found. To solve this problem, we will look for it in another repository, specifically the Bitnami repo.

First, we need to add the repository to our local list of repos:

# helm repo add bitnami https://charts.bitnami.com/bitnami

We can easily print a list of the packages available in this repository:

# helm search bitnami

Since we specifically want the _nginx_ package:

NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/nginx 4.3.10 1.16.1 Chart for the nginx server
bitnami/nginx-ingress-controller 5.0.10 0.26.1 Chart for the nginx Ingress controller

We can see that the first package is the one we want, since it is the server package. To install it:

# helm install bitnami/nginx --name miservidor

And this is the output it should produce:

NAME: miservidor
LAST DEPLOYED: Sat Oct 26 16:55:41 2019
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
miservidor-nginx 0/1 1 0 1s
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
miservidor-nginx-7f6b9459c7-gfpf8 0/1 Pending 0 0s
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
miservidor-nginx LoadBalancer 10.107.125.197 80:31658/TCP 1s
NOTES:
Get the NGINX URL:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w miservidor-nginx'
export SERVICE_IP=$(kubectl get svc --namespace default miservidor-nginx --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo "NGINX URL: http://$SERVICE_IP/"

When running this command, it may say that there is no tiller ready to execute the task. If so, and running `kubectl get pods –namespace kube-system` shows a pod starting with _tiller-deploy-_ with a Pending status, you can resolve this so that it runs as follows:

# kubectl taint nodes --all node-role.kubernetes.io/master-

We can see that it specifies the Kubernetes resources it has created (which, had we looked at the ngnix _chart_, were declared there). We can check this directly in `kubectl`:

NAME READY STATUS RESTARTS AGE
miservidor-nginx-7f6b9459c7-gfpf8 0/1 Pending 0 3m36s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 92m
miservidor-nginx LoadBalancer 10.107.125.197 URL 80:31658/TCP 4m2s

If we access URL from a web browser, we will see the typical nginx welcome screen:

 Other useful Helm commands:

• List all installed _charts_:

# helm list

• Completely delete a _chart_ and all its files:

# helm delete --purge miservidor

• Help:

# helm help

CC-BY – David Población