Helm Charts in Kubernetes

For this demo, I’m using Flask App Deployment. It is a multi-tier web application, which stores user detail in this application. I have a flask app deployment that has two ports. This application is exposed to the user by a NodePort service. I have a MySQL database, which connects to my frontier application using MySQL service. It has secrets where we store sensitive values.

What happens if we deployed this application without Helm? So we have 5 YAML files, one for flask service, one for SQL service, one for MySQL deployment, one for flask deployment, and one for SQL. If we want to deploy this application in our cluster, we have to deploy each and every file individually. If we want to change a value in our application, we would have to change that value, and all files using that value.

By using Helm, we can bundle up all these files in a single entity, called a Helm Chart. We can just deploy the single Helm Chart and deploy our application. If we want to deploy two different applications, we can just provide different configuration values. We can have two different applications by using just the single Helm Chart.

Let’s move forward to the demo. Let me first show you my manifest files. This is my flask deployment file. I have two replicas here, and I have an image that is my flask app. My app is running on port 5000 and my environment variables are coming from the secrets. I have one file for my flask service and the type of microservice is a NodePort. I have one manifest file running my MySQL image and the values are also coming from the secrets. It has one file for my MySQL service and I have one file for the secrets. Here, my values are encoded in base 64.

So if we want to deploy this application without Helm, we have to deploy all the files individually. If we want to change our value, we have to change that value in all of our files.

To deploy this file using Helm, we first convert this file to Helm Chart. So to create Helm, we will run the command Helm-create and the name of the Helm Chart. Let’s see. Demo. It will create our Helm Chart and it has some dummy data in it. Let me show you. It has a chart .yaml file, where we have metadata of servers chart, and we have some dummy files in templates. We have values .yaml file in which we will write the values of our files.

If we want to deploy this deployment to Helm, we first move to our newly created Helm Chart. We will delete the Demo files and we will move our manifest files to that folder. Now that we have all four files in our template, we can run this Helm Chart, and we can install all our files to Helm. But if we want to make a replication dynamic, we will use the values file. Let’s say we want to parameterize our replica of the value. We will write our replica variable here, like replica count and the value is two. We will call this value in our main template. To call this value, we will write double curly braces, and thought values to tell them our value is coming from the value node and then the name of our variable. Now it will get the value from the value. If we want to change the replica count, we just have to change it here. We’ll change our value in replica values here. For this, I already wrote a Helm Chart for it. I have written all my values in that value-stored YAML file. If we look into our Helm Chart, I have written some functions here. For example, if we don’t have a value for the container port, it will ultimately set the default value to 5000.

We also have a quote function here if we want our value to be in double quotes. We can write this function so that whatever values we get from the value, it writes in the double quotes. The same samples I follow are in all the YAML files. I’m getting the values from the value-stored YAML file. In the value file, I write all the values. If I want to change a specific value, I have to change it just right here and it will automatically populate it in all the files.

If I want to deploy this Helm Chart in my cluster, I just write Helm-install and my app name, and the part of the repo where my chart is. By just running this single command, we can deploy our complete application. It will get deployed on my cluster by running just one command. Let me show you my app here. I have a deployment here, one plus deployment, and one stateful set, MySQL. All my ports are running and my services are running by just running one command. All of my manifest files are deployed in a cluster.

If I want to change my existing application, I just choose this. I want to write a command, Helm-upgrade, and write my application names and part of the repo. I have another value file here. I can change the value here and I could pass that value file in my Helm Chart. To pass my new value file here, I use the values flag here, and we’ll give the values file path. By this simple command, we can update our existing application with new configuration values. Basically, it will create a new revision of my application, which is version two, and it will update my configuration value. I changed the replica count to one. Now if I go to my ports or deployment, my replica is one. It changed my application value. I can see my revision by the Helm-history command and history and my app name. It’ll show me the history of my app. In case I want to roll back to my previous revision, if the new configuration values make some changes that are not expected, I can roll back my application to the previous revision. For this, I can write Helm-rollback and my app name.

To create a new revision, which is revision three in my case, which is the same replica of the previous revision, which is revision one. If I go to see my history, it created a new revision, which is basically a replica of my first revision, and it changed my replica back two. That’s how Helm can help us to deploy our application in Kubernetes. We can just use a single command to deploy and upgrade and to rollback our replication.