<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

Magalix Introduces the Cloud-Native Application Policy Pack

Exit icon Learn More

Kubernetes Deployment With Helm Charts

DevOps Kubernetes helm write-for-cloud-native
Kubernetes Deployment With Helm Charts
DevOps Kubernetes helm write-for-cloud-native

Helm is a package manager for Kubernetes applications. Kubernetes has grown tremendously over the past few years, and so has the ecosystem to support it. Recently, Cloud Native Computing Foundation (CNCF) has announced Helm as an incubating project that demonstrates its growing popularity among Kubernetes users. It uses a YAML file form called Charts. Charts are used to describe, install, and update Kubernetes. They are a prototype sort and they support even the most complex Kubernetes applications. Charts are built to be easy to produce and maintain, and can be exchanged and used for Kubernetes publishing.

We'll explain the basics of Helm and show what a powerful tool it can be for working with Kubernetes resources.

Kubernetes Deployment With Helm Charts

What Are The Benefits Of Using Helm With Kubernetes?

Helm helps us to build a framework for clearly defined microservices, and manages our scalability needs (up or down), and assists in adding more Kubernetes nodes and pods to the cluster as needed. Instead of working with a holistic image, and increasing resources, you are running only a necessary set of images, and independently scaling them up.

  • Deployment Speed: A Helm map can quickly be deployed into a Kubernetes cluster. Either pull down a GitHub project with the Helm chart that you are planning to deploy, or give the Chart name from the desired Helm repository. The Consul-Helm repository can be pulled from GitHub, or from the default Helm repository hosted by Google.
  • Application Testing: You’re not alone in this - engineers have built Helm maps to guide you. Like any engineer with testing in mind, they expect failure, and design around it. You'll appreciate the amount of tests available in several of the Helm map repos. The tests can range from proper load-testing, to simple config testing, to ensure that your services run properly.

What Are The Prerequisites For Installing And Using Helm?

  • A Kubernetes version 1.8 + cluster, enabled with Role-Based Access Control (RBAC).
  • The command-line tool kubectl installed on your local machine, configured to connect with your cluster. More information on installing kubectl can be found in the official documentation.

The following command can test your connectivity:

kubectl cluster-info

If you see no errors, you’re connected to the cluster. If you access multiple clusters with kubectl, be sure to verify that you’ve selected the correct cluster context:

kubectl config get-contexts

Your output should look like:

CURRENT     NAME                    CLUSTER                      AUTHINFO   
*         do-nyc1-k8s-example     do-nyc1-k8s-exam    do-nyc1-k8s-example-admin

          docker-for-desktop      docker-for-desktop-cluster docker-for-desktop

In this example the asterisk (*) indicates that we are connected to the do-nyc1-k8s-example cluster.

LAB: Creating A Kubernetes Deployment Using Helm Charts:

1. Installing Helm

First, we're going to install the Helm command-line utility on our local host. Helm provides a script that will handle the MacOS, Windows, or Linux installation process.

Change to a writable directory, and download the GitHub repository script from Helm:

cd /tmp

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > install-helm.sh

Make the script executable with chmod:

chmod u+x install-helm.sh

You can use your favorite text editor at this point to open the script, and inspect it to make sure it's safe.

If you're satisfied with it, run the following:


Next, you’ll be prompted to provide your password.

2. Installing A Helm Chart

Packages of Helm software are called charts. Helm comes pre-configured with a collection of curated charts called a stable. In their GitHub repos, you can search all of the available charts. Next, as an example, we’ll be installing the Kubernetes Dashboard.

Use Helm to install kubernetes-dashboard from the stable repo package:

helm install stable/kubernetes-dashboard --name dashboard-demo
NAME:   dashboard-demo
LAST DEPLOYED: Wed Aug  8 20:11:07 2018
NAMESPACE: default

. . .

Note the line NAME, highlighted in the output of the above example. In this case the name dashboard-demo was specified. That is our release name - a Helm release is a single one-chart deployment, with a specific configuration. With that map you can deploy several releases, each with its own configuration.

If you don't use the —name to specify your own release name, Helm will create a random name for you.

For a list of releases on this cluster, enter the following:

helm list

Our output should look like:

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

Now we can use kubectl to check the deployment of a new service on the cluster:

kubectl get services

Now, our output should look like:

NAME                                   TYPE        CLUSTER-IP    

dashboard-demo-kubernetes-dashboard   ClusterIP         
kubernetes                             ClusterIP

Note that the service name corresponding to our release is, by default, a combination of the name of the Helm release and the name of the charts.

3. Updating A Release

The helm upgrade command can be used with a new or updated chart to upgrade a release, or to update the configuration options.

To demonstrate the update and rollback process, we’ll make a simple change to our dashboard demo release: we’ll update the dashboard service name to the dashboard only, instead of the dashboard demo-kubernetes-dashboard.

The kubernetes-dashboard chart provides a configuration option for fullnameOverride control of the name of the service. Let's upgrade to helm with this set of options:

helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="dashboard"

You’ll see output that’s similar to what we received after the initial step of installing Helm.

Check to see if the updated values reflect your Kubernetes services:

kubectl get services

Next, our output should look like:

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S) 
kubernetes             ClusterIP               443/TCP   dashboard              ClusterIP           443/TCP

So, it's clear that the name of the service was updated to the new value.

"Are you facing monitoring issues? get a bird's eye view &Understand infrastructure trends drill down into the right level of details with just 2 clicks.


Learn More

4. Rolling Back a Release

We created a second modification of the release when we updated our dashboard-demo release in the previous step. Thankfully, Helm retains all previous release details in case you need to roll back to a previous configuration or chart.

To inspect the release again use the helm list:

helm list

The output should look like:

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

The column on REVISION tells us that this is now the second update.

To roll back to the first revision use helm rollback:

helm rollback dashboard-demo 1

You should see the following output, indicating that the rollback succeeded:

Rollback was a success! Happy Helming!

At this point, you’ll notice that the service name changed back to its previous value (if you run kubectl get services again). With the configuration of revision 1 Helm re-deployed the application.

5. Deleting A Release

Helm releases can be deleted with the Helm delete command:

helm delete dashboard-demo

Now, our output should look like:

release "dashboard-demo" deleted

Although the release has been deleted and the dashboard application no longer runs, Helm will save all the revision information (in case you want the release to be re-deployed). If you were trying to install a new dashboard-demo release right now, you would have an error.

Error: a release named dashboard-demo already exists.

If you use the --deleted flag to list your deleted releases, you’ll see that the release still exists:

helm list --deleted

Next, our output should look like:

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

Use --purge flag with helm delete command to really delete the release and purge all old revisions:

helm delete dashboard-demo --purge

Now the release has been completely removed, and the release name can be reused.


  • To sum up, in this article, we’ve installed the Helm command-line tool . We also explored downloading, updating, rolling back, and removing charts and releases from Helm.
  • Kubernetes is the future of cloud container orchestration, and Helm is the most efficient way to utilize Kubernetes. The DevOps team can do the same with standard kubectl commands, but working with Helm gives you the ability to quickly define, cleanly manage, and easily deploy applications. Thus, the combo of Kubernetes + Helm can easily become the foundation tool set for any DevOps specialist in the years ahead.

Comments and Responses

Related Articles

7 Notable and Costly Security Breaches

Learn some notable security breaches that happened a few years ago, the root causes, and how Magalix can help protect your Kubernetes infrastructure

Read more
Security Context Settings Help Mitigate Kubernetes Risk

Kubernetes isn't secure by default and is attacked relentlessly. But security context settings help DevOps teams better secure their pods and containers.

Read more
DevOps Policy as Code
Cloud Data Asset Management and Tagging Cloud Resources

Learn how cloud data asset management enables organizations to manage, optimize and secure their cloud data assets and resource tagging is a key part of it

Read more