Kubernetes Helm : A Getting Started Guide

Published:13 October 2021 - 7 min. read

Azure Cloud Labs: these FREE, on‑demand Azure Cloud Labs will get you into a real‑world environment and account, walking you through step‑by‑step how to best protect, secure, and recover Azure data.

If you’re new to Kubernetes and looking for a way to manage your Kubernetes applications, then you’re in for a treat. Kubernetes Helm is the package manager for Kubernetes that allows you to define, install and upgrade complex Kubernetes applications.

In this tutorial, you will learn how to manage and deploy Kubernetes applications with Helm by running commands.

Ready? Let’s get started!


This tutorial comprises hands-on demonstrations. To follow along, you will need the following:

  • You will need Minikube (v1.22.0) to deploy a testing Kubernetes cluster, but you can use your existing cluster.
  • Helm client (v3.6.3).
  • Kubectl client (v1.21.2) to interact with the cluster.
  • An Ubuntu machine – This tutorial uses Linux Ubuntu 20.01.3 machine, but any other operating system will work.

Viewing Existing Kubernetes Resources

Kubernetes, also known as K8s, is an open-source container orchestration engine. Kubernetes uses the kubectl tool to manage containerized applications and all the resources needed by them. Those resources are Kubernetes objects like persistent volumes, secrets, configmaps, or pods (groups of containers).

To manage Kubernetes resources, you’ll first need to know which resources are currently existing. Each of the kubectl get commands below lists the existing resources based on the resource type you specified.

For this example, launch your terminal and run the kubectl get all command below to list all existing resources.

# Lists all resources
kubectl get all

# Alternatively run the commands below to list specific resources
kubectl get pods # Lists pods resources
kubectl get service # Lists service resources

Below, you can see all resources listed, such as pod, service, deamonset, deployment, replicaset, and statefulset.

Listing Existing Kubernetes Resources
Listing Existing Kubernetes Resources

Finding Kubernetes Helm Charts

You can define complex applications with manifest files, but maintaining them would be difficult because their content may vary depending on the environment. So is there a better way? Yes!

A Helm chart is a collection of resources that Helm uses to generate manifest files and deploy Kubernetes applications. Helm charts use a template engine to create manifest files according to some input parameters. The template engine allows you to deploy different configurations for the same application using a single Chart.

1. Visit the ArtifactHUB website to look for existing Helm charts. ArtifactHUB is the main Helm chart repository and the first place to search a specific chart.

You can also find Helm charts on other websites, such as GitHub, Gitlab, Bitbucket, and similar platforms.

2. On the ArtifactHUB website, type the name of the Helm chart you’re looking for in the search box, as shown below. For this tutorial, enter jupyterhub and select jupyterhub to see the chart’s information.

The jupyterhub Helm chart runs multi-user jupyter notebooks in the cloud. Jupyter notebooks are documents combining live code, equations, visualizations, and narrative text.

Always choose the official chart made by the organization responsible for the software, in this case, the one made by JupyterHub. You can also select charts from verified publishers, like Bitnami. Their charts are a good alternative when official charts are not available or are not good enough.

Finding Helm Charts in Artifact Hub
Finding Helm Charts in Artifact Hub

A Helm chart is composed of the following:

  • A templates directory with files used by Helm to generate manifest files for Kubernetes.
  • A values.yaml file with input values used by templates to generate the manifest files. Each chart has a file with the default values for each parameter, but you can overwrite those values.
  • A chart.yaml file containing information about the chart and the software that is packaged into it. The jupyterhub Helm chart includes the software version and the dependencies (usually other Helm Charts) required to run the whole application.

You can see these parts of the Helm chart on ArtifactHUB’s right-most side, as shown below.

Understanding Parts of a Helm Chart
Understanding Parts of a Helm Chart

3. Click on the Templates button to see a list of templates for the Helm chart (jupyterhub).

Finding Helm chart templates in ArtifactsHub
Finding Helm chart templates in ArtifactsHub

4. Now in the Templates window, click on hub/deployment.yaml template from the list in the left panel to view its content.

Selecting a Template
Selecting a Template

Helm uses the golang template system to include control structures, such as loops or conditionals, in its templates.

For example, the code inside the deployment.yaml template (line 33) has a conditional block, as shown below. The conditional block indicates that the inner code will only appear in the final manifest file if the condition is met.

Also, have in mind that those statements that start with .Values in the screenshot below refer to input values (parameters) introduced by the user in the values.yaml file.

{{- if .Values.scheduling.podPriority.enabled }}
      priorityClassName: {{ include "jupyterhub.priority.fullname" . }}
{{- end }}
Viewing Template Contents
Viewing Template Contents

Helm templates include everything required to create manifest files generated according to the input parameters. Manifest files are what Helm uses to deploy an application.

The templates system and their control structures, along with other template mechanisms, lets you create different deployments from the same template for a specific application.

Deploying Applications with Helm

Now you have an idea of the Helm chart, let’s see how to deploy applications with Helm. But before doing so, you’ll first need to download the sources of the Helm chart (jupyterhub).

  1. In the jupyterhub Helm chart dashboard, click on the Install button, as shown below, to see the required commands to deploy a Helm chart into a Kubernetes cluster.
Clicking Install to Download Sources of the Helm Chart
Clicking Install to Download Sources of the Helm Chart

2. Click on the link (this link) at the bottom of the pop-up window to download the Helm chart (jupyterhub) package’s contents so you can interact directly with them. You can download the chart to any path on any machine with access to the Kubernetes cluster.

Downloading the Helm Chart Package's Content
Downloading the Helm Chart Package’s Content

Extract the package’s content, then open a terminal and change to the extracted folder’s directory.

# change the directory to the extracted folder's path.
cd jupyterhub

Alternatively, you can download and extract the sources directly from the terminal by running the following commands.

# download sources
wget https://jupyterhub.github.io/helm-chart/jupyterhub-1.1.3.tgz
# extract sources
tar -xvf jupyterhub-1.1.3.tgz
# move to the extracted folder
cd jupyterhub

4. Run the command below to deploy a testing cluster with minikube. You’ll need this cluster to start deploying an application.

Feel free to skip running the following if you already have another kind of cluster that you want to use. Consider using a tool such as Kubectx, which is designed to manage and switch between kubectl contexts. But if you only have one cluster, you won’t need to switch contexts.

# start minikube engine and switch to minikube context
minikube start

You can see below that the command automatically sets your kubectl configuration to use minikube context.

Creating a Kubernetes Cluster with Minikube
Creating a Kubernetes Cluster with Minikube

Installing Helm Charts

With the cluster ready, you can now install the Helm chart with your desired configuration. In the downloaded sources, you have a values.yaml file that contains default values for any available configuration. Based on those default values, you can add custom configurations when installing a chart.

1. Open the values.yaml file in your favorite code editor, and set the replicas to 3 to increase the number of pods replicas, as shown below. The higher value of replicas, the higher availability.

Editing the values.yaml file to increase the default number of replicas
Editing the values.yaml file to increase the default number of replicas

2. Next, run the command below to install (helm install) the Helm chart (jupyterhub) to your Kubernetes cluster with a custom values file (-f values.yaml) in the working directory (.). You can also use a relative or absolute path or even an URL to a remote Helm instead of the working directory.

Notice the name assigned to the deployment of this Helm application is jupyterhub-example, but you could use any other name instead.

helm install jupyterhub-example -f values.yaml .

The execution of the command can take a few minutes to finish as your computer will create all the required components to run the application.

Bear in mind that minikube creates development environments that you shouldn’t use in production, or you’ll get bad cluster performance. Tools like minikube are only used for local development and testing purposes and can be slow depending on your local system resources.

The information printed after deployment contains instructions on how you should proceed (according to the developers) in using the application. The information usually includes the address and port required to connect with the application, possible default passwords, and more.

Installing JupyterHub application on Kubernetes cluster using Helm with custom input values.
Installing JupyterHub application on Kubernetes cluster using Helm with custom input values.

3. Finally, run the command below to see the list of generated resources.

kubectl get all
Listing resources created by Helm after installing the JupyterHub chart.
Listing resources created by Helm after installing the JupyterHub chart.

Testing Deployed Service

By now, you have already deployed a service in your cluster, but you should check if the service you deployed works.

In a production cloud environment, you would probably add a DNS record to your DNS manager to access the new service from outside of the cluster. But there is a command to forward ports from the cluster to your localhost through kubectl.

1. Run the kubectl command below to list all available services (get service).

kubectl get service

From the list below, you can see each service has a CLUSTER-IP field. The IP is internal to the cluster and is the one that other services would use to interact with one service. CLUSTER-IP addresses are private to the cluster and aren’t accessible from your browser, but let’s fix that in the next step.

Listing available services on Kubernetes cluster
Listing available services on Kubernetes cluster

2. Run the following command to forward (port-forward) the port 8081 (used by the JupyterHub service) to your localhost address. This command enables you to navigate to the service from your local computer.

kubectl port-forward service/hub 8081
Forwarding ports from the cluster to your localhost
Forwarding ports from the cluster to your localhost

Another way to navigate to the service from your local computer is by creating an external IP for the service. But that way is beyond the scope of this tutorial.

3. Finally, navigate your localhost on your browser, appending the port forward in the previous command (localhost:8081) to test if the deployed service is working.

Testing the deployed service
Testing the deployed service


In this tutorial, you have learned how Kubernetes Helm packages applications with Helm charts. You’ve learned to apply your first Helm chart and deploy and working service. Now you’re ready to deal with complex Kubernetes cloud-native applications.

With this newfound knowledge, what kinds of applications do you have on mind to deploy with Helm? Perhaps deploy dependencies for your projects, such as a rabbit MQ service or a MySQL database?

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

Explore ATA Guidebooks

Looks like you're offline!