DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Containerization and Helm Templatization Best Practices for Microservices in Kubernetes
  • Automated Rollback the Ultimate Application Release Insurance Policy
  • Developing Saga Participant Code for Compensating Transactions
  • Kubernetes Package Management With Helm

Trending

  • DGS GraphQL and Spring Boot
  • How to Convert XLS to XLSX in Java
  • Unlocking AI Coding Assistants: Generate Unit Tests
  • Unlocking the Potential of Apache Iceberg: A Comprehensive Analysis
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Create, Install, Upgrade, and Rollback a Helm Chart (Part 2)

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.

By 
Gunter Rotsaert user avatar
Gunter Rotsaert
DZone Core CORE ·
Nov. 02, 18 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
128.0K Views

Join the DZone community and get the full member experience.

Join For Free

In 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.

Chart Rollback (data management) application Release (computing) pods

Published at DZone with permission of Gunter Rotsaert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Containerization and Helm Templatization Best Practices for Microservices in Kubernetes
  • Automated Rollback the Ultimate Application Release Insurance Policy
  • Developing Saga Participant Code for Compensating Transactions
  • Kubernetes Package Management With Helm

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!