Learn more about Helm, a package manager for Kubernetes that makes it easy to take applications and services that are highly repeatable and deploy them to a typical Kubernetes cluster.

To help you better understand Helm, I’m going to walk you through a typical scenario of using Helm to quickly define, manage, and easily deploy a few different applications and services in Kubernetes.

I hope you leave this video with a deeper appreciating for Helm, and make sure you subscribe to the YouTube channel to be notified about more videos like this when they are published.

Learn more

• IBM Cloud Kubernetes Service
• What is Kubernetes?
• VIDEO – Kubernetes Explained
• VIDEO – Kubernetes vs. Docker: It’s Not an Either/Or Question
• Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery
• Want to get some free, hands-on experience with Kubernetes? Take advantage of interactive, no-cost Kubernetes tutorials by checking out IBM CloudLabs.

Video Transcript

What is Helm?

Hey everybody, I’m David Okun with IBM Cloud, and today we’re gonna talk about Helm.

Helm is a package manager for Kubernetes that makes it easy to take applications and services that are highly repeatable or get used in a lot of different scenarios, and it makes it easier to deploy them to a typical Kubernetes cluster.

Deploying applications and services into Kubernetes

To really understand and take that home, let’s walk through a typical scenario of a couple of different applications and services as they’re deployed in Kubernetes.

So, let’s say we’re working with an e-commerce application that’s signing up users for a certain shopping platform for the holidays. I’m sure you can think of a couple examples there, and let’s say that we’ve written a Node.js application that we’re going to deploy to our Kubernetes cluster. 

Here, we’re going to say that that’s marked here with one deployment, but we have two replicas of this.

This is because this is going to need to be highly available, so we have two replicas to handle all the different requests that are going to be coming in.

And then additionally underneath this, we’ve got a MongoDB database. This is going to handle communications to and from each of our replicas—just our main Node.js application that we have.

And let’s say that we’ve also written a service as a way to access our application. Let’s say we’ve written that as a NodePort—NodePort meaning that there’s just a one-to-one ratio between IP’s inside of and outside of our Kubernetes cluster.

Writing YAML files

So in order to deploy this kind of application stack, you need to define this. One way that you can define this with Kubernetes is writing a couple of YAML files to describe what your deployments are going to look like, what your service is going to look like, etc.

And this is a fairly parsed-down example, but let’s go through some of the key elements of this here.

Deployment.YAML

With our deployment of our Node.js application, let’s assume Mongo’s there for, you know, persistence’s sake. With our deployments, we know that we’re going to be writing an image of Node and Mongo. So, for example, our YAML file here might look something like node/mongo:1 and you might say version one something like that.

And again for the number of replicas that we have for this application, we know that we need two replicas here to, again, be able to handle that high availability. 

Service.YAML

Now for our service, we decided that it was going to be a type of NodePort, so we’re gonna write that here. 

And again this is a one-to-one ratio between IP’s outside of our service and inside of it to be able to route it to just one service here on our deployment because we have two replicas here to mitigate load whenever it comes to our deployment. 

And then let’s say for this particular example, this is going to be served up on port:8080.

So we can write that purely inside our Service.YAML file here. 

Helm provides an easier way to manage the configuration for your application stack

Now, this all works, and let’s say that you wrote this application yourself, you wrote these YAML files yourself, you’re really familiar with the configuration, so as long as you’re still working on this it’s fairly easy to be able to make changes to it and change things as requirements might change.

So let’s say the holidays end and you want to go ahead and spend this down you know exactly where to find the number of replicas that you need to change. But let’s say you move on to a different job in your company and somebody else is stuck managing this. They might not know—even in this simple example—where to go to change the number of replicas that you have with this particular application.

So what if there was an easier way to manage the configuration for your whole application stack and separate that logically from everything you have with your particular templated application.

This is one place where Helm can really help you out. Think of Helm as combining two particular components for your whole application stack:

1. A configuration (which is going to be defined by our values—that YAML file up here):

2. A template, or what we call in Helm, a chart:

Helm charts

Your chart is going to consist of all the files that you’re going to be templating here. Now, how do we actually template these files and inject variables into them?

Well you’re going to take your configuration and you’re going to instead use templating language to decide where those values are going to be put inside your templates or your chart here. 

So, let’s say we want the number of replicas to be determined by our configuration up here instead of hard-coding that into our particular Deployment.YAML file.

The way we could change that is we could say replicas are, instead, going be managed by {{Values.deployment.replicas}}, I’ll shorten it but you understand you just write it out after that.

So that way, this is gonna say, okay we’re gonna refer to the {{Values.deployment.replicas}} node, and sure enough, that’s much easier to find in our configuration. So we can simply write `2` here. 

Now this means that depending on what you want to hard code in your template, you can decide what does it keep that hard-coded here or you can make another change here and simply refer to the same thing. Instead, you would say image: and then you could say something like node/mongo:1.

So you could do the same thing for your service as well. Let’s say you want to go from using a NodePort to a load balancer as given to you by Kubernetes in the future, so that you could instead change this and you could say {{Values.service.type}}. And you can change this to say {{Values.service.port}}.

This means that for a developer on this project or for somebody who’s working infrastructure and making sure that this is deployed fresh, you can simply have them change your configuration here.

So for example, here we’re just gonna write NodePort and for this, we’ll just choose 8080.

How does this actually work and how does this get all of this combined into your Kubernetes cluster?

Well, the command that you’re going to write when you install the Helm CLI on your machine, if you want to combine this into one chart, you would simply write helm install myApp—if you’re referring to the right folder that you have as the CLI tells you to do. 

And what Helm will do is it will actually take the templating chart that you have, look for particular parts where you’ve defined variables in your configuration and it will go to that configuration file, use the YAML to find the nodes that you need, and inject those parameters inside your templating file.

Once it’s got everything comprised, Helm will send this over to a component that needs to be installed on your Kubernetes cluster called Tiller.

Think of Tiller as basically just the server-side component of Helm—it’s gonna take the commands you’ve sent with the Helm client and turn that into something that your Kubernetes cluster will understand so that it will say, okay take the service map that there, take the deployment map that there, and take this database and map it there.

Upgrade to a new configuration

Now this becomes extra useful when you want to do things like upgrade to a new configuration and rollback. 

Let’s say you’re past the holidays and you say, okay we can spin this down to where we only need one replica now of this particular deployment. So, rather than taking down the application whole-meal and then going ahead and redeploying it with the new configuration, you could simply instead type helm upgrade myApp.

So you could replace install with upgrade, and that’s how you can use that same syntax.

That way what you would do is Helm would again template everything out, make sure that it works the way you want it to, and get that configuration sent over to Kubernetes so it can manage uptime as being the most important characteristic of your particular stack.

The rollback command and version history

Let’s say you made a mistake when you were upgrading it and something that you just changed it to doesn’t work. The way to roll that back—you guessed it—is the rollback command. 

What Helm will also give you is it actually keeps a version history for you of different configurations that you’ve sent over the wire with Helm so that you can rollback to the last known working configuration whenever you want to.

Deploy charts into repos

Lastly, when you’re working with these you’ve talked about hey maybe you moved on to a different team but maybe other teams need this exact same kind of configuration as well, well you can make use of repos as well. 

And you can actually deploy your charts into that repo by typing helm package and then using Helm repo index to send that up to a repository so anyone in your company can make use of the same chart as well.

Summary

So, what we’ve discussed is basically taking a typical scenario going through it in a fairly understandable way by hard-coding your YAML, but by parameterizing it with Helm you just make it a little bit easier to manage these packages and upgrade them when you need to and make it easier for everyone else on your team to understand it as well.

It’s currently in the incubation phase of the Cloud Native Computing Foundation and it’s ready for open source and ready for you to use today.