Helm concepts

The goal here is to go over some basic insight into helm, what it is, and its usecases. To install software on machines we commonly use today (macs, ubuntu, linux, etc.), we commonly use package managers. Brew for mac, apt for ubuntu machines, etc. Using these package managers abstracts out the several dependencies that would be required to install that piece of software. For example, installing rabbitmq (which is a messaging queue service) on a mac is as simple as using the package manager brew and running brew install rabbitmq.

Similar to package managers on our laptops which abstract out dependencies required to install a piece of software, helm is a package manager for k8s. It helps with installing things on our k8s cluster, and creates a layer of abstraction for the possibly complex installations of running certain services within the cluster.

So for example, to install nginx which is very commonly known as a reverse proxy, or prometheus/grafana (the common open source monitoring stack), you could either define the right configuration YAML files with the right k8s resources to install it, or use helm, which would abstract all that for you.

3 common traits about a package manager like helm (even brew/apt which is for machines) include being able to install, uninstall, and update packages.

Helm in itself does not require anything to be installed on the cluster which makes it very easy to use. When using helm commands, helm also uses your current k8s context to determine what k8s cluster the resources would be deployed on.

The most common helm’s concepts include: repositories and charts. Repositories consist of a bunch of charts, and these charts are installed onto the cluster. For example, the below is what you get by running helm search repo bitnami, which displays all charts available to install onto the cluster.

To add a chart to the cluster, we first run helm repo add {some_name} {repo_url} which registers this remote repository to the local helm client, which is what is used to install charts.

aneeshseth@Aneeshs-MacBook-Air ~ % helm repo add bitnami https://charts.bitnami.com/bitnami

"bitnami" already exists with the same configuration, skipping

I get this response since I already have the repository locally present on my local helm client with the same name.

Once this is done, we run a simple helm install nginxv3 bitnami/nginx which essentially installs nginx onto our cluster, abstracting out all the dependencies / other k8s resources we’d need to install for it, and installs the chart with the final useable resource’s name as nginxv3 within the cluster, while bitnami/nginx represents the {some_name}/{chart} where some_name is the name we gave during the repo add command.

The below highlighted pod shows the nginxv2 pod running, which was deployed via the helm chart.

Beyond using external charts, we can also create our own charts. The usecase here is that a company may offer their app on-prem to be deployed by customers, which given this company uses k8s, would ideally require making it as easy as possible for the customer to deploy the app in their own cluster. Hence, what we can also do is create helm charts for own apps, so customers can install the charts into their own cluster to run the app on-prem as a customer, which would install all dependencies/services required to run the app.

To create your own chart, we first run helm create {chart_name}, which creates a few files/folders in your current directory. Below is an example of creating a chart called my-app.

The /templates folder is where all of your resources to deploy would live. So your deployment.yaml files, your services, and all other resources required. This is definetly an oversimplication of how complicated modern app architectures can be, but this sets a baseline. The Chart.yaml in the root directory consists of metadata associated with the chart. The version of the chart, version of the app being deployed, etc. The values.yaml consists of value overrides for the resources in the /templates folder. So for example, if I had a simple deployment YAML file in my templates, the last line as you’d see in this deployment references image.repository, which is what I would put in my values.yaml file.

templates/deployment.yaml:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: {{ .Release.Name }}-{{ .Chart.Name }}

  labels:

    app: {{ .Chart.Name }}

spec:

  replicas: 1

  selector:

    matchLabels:

      app: {{ .Chart.Name }}

  template:

    metadata:

      labels:

        app: {{ .Chart.Name }}

    spec:

      containers:

        - name: {{ .Chart.Name }}

          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

          command: ['sh', '-c', 'echo {{ .Values.appMessage }}; sleep 3600']

          imagePullPolicy: {{ .Values.image.pullPolicy }}

values.yaml:

image:

  repository: busybox

  tag: latest

  pullPolicy: IfNotPresent

appMessage: “App Service"

Once done, the next steps would involve packaging the chart, shipping the chart, and creating an index file. These are required steps to install the chart on a k8s cluster. The last step would be pushing this directory to github with some repo name, and running:

helm repo add {some_name} https://username.github.io/{repo_name} (this requires the repo to be public. For private repositories, we would have to push this helm chart just how we might publish docker images to use them. This can be done by storing helm charts using the OCI (open container initiative) specification).

We then run: helm repo update

And finally, we then run helm search repo {some_name} to see what charts we have available to install, and install the chart then using helm install {name_to_install_with} {some_name}/{repo_name}. Here’s an example with a sample chart I have and the commands I ran to see my charts available.

aneeshseth@Aneeshs-MacBook-Air ~ % helm repo add myrepo https://aneeshseth.github.io/helm-charts-trial
"myrepo" already exists with the same configuration, skipping
aneeshseth@Aneeshs-MacBook-Air ~ % helm search repo myrepo

NAME           CHART VERSION APP VERSION DESCRIPTION                

myrepo/auth    0.1.0        1.16.0     A Helm chart for Kubernetes

myrepo/payments 0.1.0        1.16.0     A Helm chart for Kubernetes

Helm all in all is great to use to remove the headache of managing dependencies in the cluster for very common resources you’d want to run such as an open source metrics stack.