Create, Install, Upgrade, and Rollback a Helm Chart (Part 2)
In the second half of this series, we take a look at how to install and upgrade your Helm Chart as well as how to roll it back and solve some common errors.
Join the DZone community and get the full member experience.
Join For FreeIn part 1 of this post, we explained how we can create a Helm Chart for our application and how to package it. In part 2, we will cover how to install the Helm package to a Kubernetes cluster, how to upgrade our Helm Chart, and how to rollback our Helm Chart.
Install Chart
After all the preparation work we have done in part 1, it is time to install our Helm package. First, check whether our Helm package is available:
helm search myhelmchartplanet
The output is as follows and we can notice that the chart version and application version is as we have configured:
NAME CHART VERSION APP VERSION DESCRIPTION
local/myhelmchartplanet 0.1.0 0.0.2-SNAPSHOT A Helm chart for Kubernetes
With the inspect
command we can display the information of our Helm Chart. Beware that you don’t have to add local/ to the Helm Chart name:
helm inspect myhelmchartplanet
And now the moment we have been waiting for. Let’s install our Helm Chart:
sudo helm install myhelmchartplanet
Execute the notes section of the installation output in order to set the NODE_IP and the NODE_PORT and execute the following command (wait for the pod to be running, you can check this with sudo kubectl get pods
):
curl http://$NODE_IP:$NODE_PORT/hello
The output is the following which means that our application is up-and-running!
Hello Kubernetes! From host: independent-walrus-myhelmchartplanet-7b4b7655c4-bd585/172.17.0.5
Upgrade Chart
In this section, we will upgrade our Chart (see GitHub tag v0.0.2). First, check the information of our deployed Chart with sudo helm list
:
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
independent-walrus 1 Sat Sep 22 14:31:21 2018 DEPLOYED myhelmchartplanet-0.1.0 0.0.2-SNAPSHOT default
The deployed Chart version is v0.1.0 and the deployed application version is 0.0.2-SNAPSHOT. The name of the release looks a bit awkward, but that is because we did not define it ourselves and therefore, Helm has given us this name.
In order to upgrade our Chart, we will make an adaptation to our values.yaml. We will increase the number of pods that we want to use.
We change the following in the values.yaml:
...
replicaCount: 2
...
And we change the Chart version number from 0.1.0 to 0.2.0 in the Chart.yaml:
...
version: 0.2.0
Push the changes to the git repository, package the Helm Chart and check the Chart Repository (helm search myhelmchartplanet
). The output of the search
command is:
NAME CHART VERSION APP VERSION DESCRIPTION
local/myhelmchartplanet 0.2.0 0.0.2-SNAPSHOT A Helm chart for Kubernetes
The Chart version is 0.2.0 as expected. The application version is still 0.0.2-SNAPSHOT. We did not change this, so that is ok.
Execute the upgrade with the following command:
sudo helm upgrade independent-walrus myhelmchartplanet
Notice that we need to supply the release name and the chart name we want to upgrade.
Check the number of pods (that is what we have changed) with sudo kubectl get pods
:
NAME READY STATUS RESTARTS AGE
independent-walrus-myhelmchartplanet-7b4b7655c4-bd585 1/1 Running 0 28m
independent-walrus-myhelmchartplanet-7b4b7655c4-fvqjc 1/1 Running 0 15s
Now 2 pods are running with our application and that is exactly what we wanted to do.
Check again the information of our deployed Chart just like we did in the beginning of this section (sudo helm list
):
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
independent-walrus 2 Sat Sep 22 14:59:08 2018 DEPLOYED myhelmchartplanet-0.2.0 0.0.2-SNAPSHOT default
The revision has been changed to 2 and the Chart version is now 0.2.0.
When we execute the curl command in order to check our application, we notice that the host pod/ip changes after each execution.
Rollback Chart
What if we notice that we made a mistake after upgrading? Then we can easily rollback the Chart to a previous revision. We need to provide the release name and the revision number we want to rollback to:
sudo helm rollback independent-walrus 1
Again, when you check the pods, you will notice that only one pod is running. When we check the deployed Chart with sudo helm list
, we notice that the revision is now 3 and the Chart version is 0.1.0 again:
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
independent-walrus 3 Sat Sep 22 15:12:16 2018 DEPLOYED myhelmchartplanet-0.1.0 0.0.2-SNAPSHOT default
History of Release
The last thing to check is the history of a release. We only need to provide the release name:
sudo helm history independent-walrus
The output is as follows:
REVISION UPDATED STATUS CHART DESCRIPTION
1 Sat Sep 22 14:31:21 2018 SUPERSEDED myhelmchartplanet-0.1.0 Install complete
2 Sat Sep 22 14:59:08 2018 SUPERSEDED myhelmchartplanet-0.2.0 Upgrade complete
3 Sat Sep 22 15:12:16 2018 DEPLOYED myhelmchartplanet-0.1.0 Rollback to 1
We can see exactly what we have done: we have installed Chart version 0.1.0 (revision 1), upgraded to Chart revision 0.2.0 (revision 2) and executed a rollback to revision 1 (revision 3).
Problems Encountered
When writing this post I encountered some problems after deploying the Chart. In this section, I briefly want to mention what the problems were and how I was able to solve them.
The first problem was a problem with an invalid configuration in the service.yaml file. I thought this was being checked with the lint
command, but it does not seem to check every valid combination.
The error that was raised was the following (the release name was newbie-boxer):
Error: release newbie-boxer failed: Service "newbie-boxer-myhelmchartplanet" is invalid: spec.ports[0].port: Invalid value: 0: must be between 1 and 65535, inclusive
I solved it by looking at the service.yaml file and noticed that the port was filled with a value from the values.yaml file which I had removed. Adding the value again solved the issue.
Another problem was a bit more tricky. When the Chart was being deployed, the pod did not start correctly and came in a CrashLoopBackOff state. Eventually, I solved this issue as follows:
- Downloaded the deployment.yaml, pod.yaml, replicaset.yaml and service.yaml via the Minikube dashboard;
- Remove the deployed Helm Chart;
- Installed the application and created the service with kubectl. This had been working before;
- Downloaded the deployment.yaml, pod.yaml, replicaset.yaml and service.yaml via the Minikube dashboard;
- Compared the yaml files of the manual installation with the Helm installation;
- I quickly noticed that the main problem resided with the readinessProbe and livenessProbe;
- Removed the manual installation and deployed the Helm Chart again;
- Via the Minikube dashboard I edited the yaml files in order that the pod started correctly;
- Now that we know that the configuration is correct, I made the changes to the Helm Chart, pushed it to the git repository, packaged it and successfully deployed the Helm Chart.
Summary
In part 2 and the final part of this post, we installed our Helm package to our Kubernetes cluster, executed an upgrade and a rollback. We also explained how to view the history of releases and how problems can be solved when creating Helm Charts.
Published at DZone with permission of Gunter Rotsaert, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments