What Is A Helm Chart? – A Beginner’s Guide

Helm is a Kubernetes package and operations manager. The name “kubernetes” is derived from the Greek word for “pilot” or “helmsman”, making Helm its steering wheel. Using a packaging manager, Charts, Helm allows us to package Kubernetes releases into a convenient zip (.tgz) file. A Helm chart can contain any number of Kubernetes objects, all of which are deployed as part of the chart. A Helm chart will usually contain at least a Deployment and a Service, but it can also contain an Ingress, Persistent Volume Claims, or any other Kubernetes object.

Helm charts are used to deploy an application, or one component of a larger application. 

You can view the list of official Helm Charts here (https://github.com/helm/charts). These Charts can be installed as-is, or modified to suit your purpose. For example, you could modify a Chart to install specific plugins or to use a custom Docker image.

Installing Helm

Helm versions 1 and 2 are actually composed of two pieces – the Helm CLI, and Tiller, the Helm server-side component. It is important to note that Helm 3 removes the Tiller component, and thus is more secure. Helm can be installed on Linux, Mac, or Windows.

 Before installing and configuring, you’ll need access to your Kubernetes cluster and an understanding of the security configurations to apply to the cluster. The default Tiller installation applies no security configuration, which is completely appropriate for clusters without many security concerns, such as local development. For a production cluster using Helm 1 or 2, it’s important to consider your security context and create the appropriate RBAC (role-based access control) Service Account to assign to Tiller.

Check here for basic installation directions.

Check here for best practices for securing Helm and Tiller.

Where to Store Your Helm Chart – Chart Repositories

A Helm repository is an http server with an index.yaml file containing names and metadata for the repository’s charts. This means that the server location is extremely versatile. You can set it up on GitHub or GitLab, host it yourself on a web server, or use a Nexus plugin. Only the packages are stored in this repository. The charts themselves are version controlled, usually with the application that they support.

Learn more about chart repositories here.

Anatomy of a Helm Chart

You can generate a skeleton chart for your own applications using the following command, where chartname is the name of your chart:

helm create chartname

A helm chart tree contains a values.yaml file, template files that consume the values, a chart.yaml file with name and version information, and a NOTES.txt file which prints on the command line when you start your application.

Essentially, Helm charts are Kubernetes yaml files that accept variables. For example, here is a section of a values.yaml file:

image:
  repository: jenkins/jenkins
  tag: lts
  pullPolicy: IfNotPresent

 Here is a section of a deployment.yaml file that consumes those values:

containers:
  - name: {{ .Chart.Name }}
  image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
  imagePullPolicy: {{ .Values.image.pullPolicy }}

.Chart.Name comes from the chart.yaml file. It can be very tedious to modify this name after the chart has been generated since each file would need to be modified to reflect the new name for the chart to deploy.

Tip: variable quoting – To ensure that integers and floats used as image tags in the values.yaml are evaluated as a string, the quote function can be used in the file consuming the value to wrap the value in double quotes.

{{ .Values.my.value | quote }}

 Tip: edit the NOTES.txt file to suit your application. This file prints access directions to the command line when a chart has been deployed and can consume variables. 

You can also structure Helm charts as “umbrella” charts, where one chart will bring up a nested stack of dependencies. To do this, add a requirements.yaml file at the same level as the values.yaml file. Here is an example dependencies file that pulls a Jenkins chart from a public repository, as well as a local chart from a filepath.

dependencies:
  - name: jenkins
    repository: https://kubernetes-charts.storage.googleapis.com/
    version: 1.3.6
  - name: my-local-chart
    repository: file://path/to/charts/
    version: 1.0

You can nest dependencies within charts. Please note, for dependency purposes, Kubernetes considers a pod to be “Running” when it exists, and not when the optional Liveness and Readiness probes have passed. Although Helm respects the basic order of dependencies, you may still need to make use of init containers to be sure that your dependency applications are really ready before connecting to them.

For example, to check that mongodb is ready before initializing the pod that will connect to it:

initContainers:
  - name: init-wait-for-mongo
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mymongochartname; do echo waiting for mymongochartname; sleep 2; done;'] 

Init containers are under spec.template.spec, just like the containers section.

Deploy With Helm

When your chart is ready, you can use this command to create a .tgz package:

helm package chartname

You can upload this package to your chart repository, or install it to your cluster. You can also install or upgrade the chart without packaging it first.

First, install your chart “mychart”:

helm install mychart

List the helm releases – you should see a generated deployment name with the Docker image designated by “mychart”.

helm ls

Delete the deployment.

helm delete generated-deployment-name

Package the chart. 

helm package mychart

Install the packaged chart.

helm install mychart-0.1.0.tgz

To make changes, update the version number in Chart.yaml. Package the chart, and upgrade.

helm upgrade generated-deployment-name mychart-0.2.0.tgz

To assign a release name to a Helm chart, type:

helm install release-name mychart 

Tip: to delete all local helm deployments, use helm delete $(helm ls –short)

Helm Is Pretty Cool

Helm charts can help take your Kubernetes application to the next level by templatizing variables, reducing copy-paste work with a values.yaml file, and specifying chart dependencies.