Select Page


Helm is a package deal supervisor for Kubernetes that permits builders and operators to extra simply configure and deploy programs on Kubernetes clusters.

On this instructional we will be able to arrange Helm and use it to put in, reconfigure, rollback, then delete an example of the Kubernetes Dashboard application. The dashboard is an professional web-based Kubernetes GUI.

For a conceptual review of Helm and its packaging ecosystem, please learn our article An Introduction to Helm.

Must haves

For this instructional you’re going to want:

  • A Kubernetes 1.8+ cluster with role-based get right of entry to regulate (RBAC) enabled.
  • The kubectl command-line instrument put in to your native system, configured to hook up with your cluster. You’ll learn extra about putting in kubectl in the official documentation.

    You’ll take a look at your connectivity with the next command:

    In the event you see no mistakes, you are hooked up to the cluster. In the event you get right of entry to a couple of clusters with kubectl, make sure to check that you have decided on the proper cluster context:

    • kubectl config get-contexts


    CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-nyc1-k8s-example do-nyc1-k8s-example do-nyc1-k8s-example-admin docker-for-desktop docker-for-desktop-cluster docker-for-desktop

    On this instance the asterisk (*) signifies that we’re hooked up to the do-nyc1-k8s-example cluster. To modify clusters run:

    • kubectl config use-context context-name

If you end up hooked up to the proper cluster, proceed to Step 1 to start out putting in Helm.

Step 1 — Putting in Helm

First we will set up the helm command-line application on our native system. Helm supplies a script that handles the set up procedure on MacOS, Home windows, or Linux.

Alternate to a writable listing and obtain the script from Helm’s GitHub repository:

  • cd /tmp
  • curl >

Make the script executable with chmod:

  • chmod u+x

At this level you’ll use your favourite textual content editor to open the script and investigate cross-check it to ensure it’s protected. If you end up glad, run it:

You can be brought about to your password. Supply it and press ENTER.


helm put in into /usr/native/bin/helm Run 'helm init' to configure helm.

Subsequent we will be able to end the set up by way of putting in some Helm parts on our cluster.

Step 2 — Putting in Tiller

Tiller is a better half to the helm command that runs to your cluster, receiving instructions from helm and speaking at once with the Kubernetes API to do the true paintings of making and deleting sources. To present Tiller the permissions it must run at the cluster, we’re going to make a Kubernetes serviceaccount useful resource.

Be aware: We can bind this serviceaccount to the cluster-admin cluster function. This will likely give the tiller provider superuser get right of entry to to the cluster and make allowance it to put in all useful resource sorts in all namespaces. That is high-quality for exploring Helm, however it’s your decision a extra locked-down configuration for a manufacturing Kubernetes cluster.

Please consult with the official Helm RBAC documentation for more info on putting in other RBAC eventualities for Tiller.

Create the tiller serviceaccount:

  • kubectl -n kube-system create serviceaccount tiller

Subsequent, bind the tiller serviceaccount to the cluster-admin function:

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

Now we will run helm init, which installs Tiller on our cluster, together with some native home tasks duties equivalent to downloading the solid repo main points:

  • helm init --service-account tiller


. . . Tiller (the Helm server-side part) has been put in into your Kubernetes Cluster. Please observe: by way of default, Tiller is deployed with an insecure 'permit unauthenticated customers' coverage. For more info on securing your set up see: Satisfied Helming!

To make sure that Tiller is working, checklist the pods within thekube-system namespace:

  • kubectl get pods --namespace kube-system


NAME READY STATUS RESTARTS AGE . . . kube-dns-64f766c69c-rm9tz 3/3 Working 0 22m kube-proxy-worker-5884 1/1 Working 1 21m kube-proxy-worker-5885 1/1 Working 1 21m kubernetes-dashboard-7dd4fc69c8-c4gwk 1/1 Working 0 22m tiller-deploy-5c688d5f9b-lccsk 1/1 Working 0 40s

The Tiller pod call starts with the prefix tiller-deploy-.

Now that we’ve got put in each Helm parts, we are able to make use of helm to put in our first utility.

Step 3 — Putting in a Helm Chart

Helm tool applications are referred to as charts. Helm comes preconfigured with a curated chart repository referred to as solid. You’ll browse the to be had charts in their GitHub repo. We’re going to set up the Kubernetes Dashboard for instance.

Use helm to put in the kubernetes-dashboard package deal from the solid repo:

  • helm set up solid/kubernetes-dashboard --name dashboard-demo


NAME: dashboard-demo LAST DEPLOYED: Wed Aug 8 20:11:07 2018 NAMESPACE: default STATUS: DEPLOYED . . .

Understand the NAME line, highlighted within the above instance output. On this case we specified the call dashboard-demo. That is the call of our unlock. A Helm unlock is a unmarried deployment of 1 chart with a particular configuration. You’ll deploy a couple of releases of the similar chart with, each and every with its personal configuration.

If you do not specify your personal unlock call the usage of --name, Helm will create a random call for you.

We will be able to ask Helm for an inventory of releases in this cluster:


NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 1 Wed Aug 8 20:11:11 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

We will be able to now use kubectl to ensure {that a} new provider has been deployed at the cluster:


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP 443/TCP 51s kubernetes ClusterIP 443/TCP 34m

Understand that by way of default the provider call akin to our unlock is a mix of the Helm unlock call and the chart call.

Now that we’ve got deployed the applying, let’s use Helm to modify its configuration and replace the deployment.

Step 4 — Updating a Unencumber

The helm improve command can be utilized to improve a unlock with a brand new or up to date chart, or replace the it’s configuration choices.

We are going to make a easy exchange to our dashboard-demo unlock to exhibit the replace and rollback procedure: we will replace the call of the dashboard provider to simply dashboard, as a substitute of dashboard-demo-kubernetes-dashboard.

The kubernetes-dashboard chart supplies a fullnameOverride configuration solution to regulate the provider call. Let’s run helm improve with this feature set:

  • helm improve dashboard-demo solid/kubernetes-dashboard --set fullnameOverride="dashboard"

You can see output very similar to the preliminary helm set up step.

Test in case your Kubernetes products and services mirror the up to date values:


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 443/TCP 36m dashboard ClusterIP 443/TCP 40s

Our provider call has been up to date to the brand new price.

Be aware: At this level chances are you’ll wish to in truth load the Kubernetes Dashboard to your browser and test it out. To take action, first run the next command:

This creates a proxy that permits you to get right of entry to far flung cluster sources out of your native pc. In keeping with the former directions your dashboard provider is called kubernetes-dashboard and it is working within the default namespace. Chances are you’ll now get right of entry to the dashboard on the following url:

http://localhost:8001/api/v1/namespaces/default/products and services/https:dashboard:/proxy/

If essential, replace your personal provider call and namespace for the highlighted parts. Directions for in truth the usage of the dashboard are out of scope for this instructional, however you’ll learn the official Kubernetes Dashboard docs for more info.

Subsequent we will take a look at Helm’s talent to roll again releases.

Step 5 — Rolling Again a Unencumber

After we up to date our dashboard-demo unlock within the earlier step, we created a 2nd revision of the discharge. Helm keeps all of the main points of earlier releases in case you wish to have to roll again to a previous configuration or chart.

Use helm checklist to investigate cross-check the discharge once more:


NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

The REVISION column tells us that that is now the second one revision.

Use helm rollback to roll again to the primary revision:

  • helm rollback dashboard-demo 1

You must see the next output, indicating that the rollback succeeded:


Rollback was once a good fortune! Satisfied Helming!

At this level, in case you run kubectl get products and services once more, you’re going to understand that the provider call has modified again to its earlier price. Helm has re-deployed the applying with revision 1’s configuration.

Subsequent we will glance into deleting releases with Helm.

Step 6 — Deleting a Unencumber

Helm releases can also be deleted with the helm delete command:

  • helm delete dashboard-demo


unlock "dashboard-demo" deleted

Regardless that the discharge has been deleted and the dashboard utility is now not working, Helm saves all of the revision data in case you need to re-deploy the discharge. In the event you attempted to helm set up a brand new dashboard-demo unlock at the moment, you would get an error:

Error: a unlock named dashboard-demo already exists.

In the event you use the --deleted flag to checklist your deleted releases, you can see that the discharge remains to be round:


NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 3 Wed Aug 8 20:15:21 2018 DELETED kubernetes-dashboard-0.7.1 default

To truly delete the discharge and purge all outdated revisions, use the --purge flag with the helm delete command:

  • helm delete dashboard-demo --purge

Now the discharge has been in reality deleted, and you’ll reuse the discharge call.


On this instructional we put in the helm command-line instrument and its tiller better half provider. We additionally explored putting in, upgrading, rolling again, and deleting Helm charts and releases.

For more info about Helm and Helm charts, please see the official Helm documentation.