07 · PackagingLab 42 / 59

Guided labhelm

Helm Upgrades, Rollbacks & Release Strategy

Ship a release, break the next one on purpose, and get back to a working state in seconds.

Time: 45 min
Level: Intermediate
Objectives: 4 objectives
Cost: Free

Start the lab Challenge

Where this fits in the platform

Already built

Creating a Custom Helm Chart for Django Microservices

This lab adds

An upgrade you can undo in seconds

Which lets you

—

Before you start

You will need

Helm 3.14+
kind or minikube

You do not need these already — the lab environment below provides them.

You will be able to

Upgrade with `--atomic` so a failed release rolls itself back
Inspect release history and roll back to a known-good revision
See what an upgrade would change before running it

Cost — Free

— kind or minikube.

Nothing to pay in the browser. Open the terminal runs this against a simulated cloud — the same API calls and the same commands, with no account and no bill. The figure above applies only if you build it in your own.

How to clean up →

The scenario#

The chart lab taught you to build a chart. This is the other 95% of the job: upgrading it, discovering the new version does not start, and getting back to the one that did — under time pressure.

Hands-on environment

Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.

Open the terminal

Opens in Killercoda, in a new tab — keep this page open for the steps.

Run it on your own machine

Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:

You will need:

docker
kubectl
kind
helm

git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start k8s
./egykode shell

You need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.

Not sure what you already have? Run: npm run doctor — it checks and changes nothing.

Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.

A release to operate

Step 1 of 7

What you are proving: You can install a release you can then operate on

Marking this settles success criterion 1.

Terminal

kubectl create namespace demo
helm install demo oci://registry-1.docker.io/bitnamicharts/nginx \
  -n demo --version 18.1.0 --wait
helm list -n demo

What you are proving: You can read a release's revision history and the status of each revision

Marking this settles success criterion 1.

Terminal

helm history demo -n demo

text

REVISION  UPDATED       STATUS      CHART        APP VERSION  DESCRIPTION
1         Mon Aug 10..  deployed    nginx-18.1.0 1.27.0       Install complete

Helm keeps every revision's rendered manifests and values in a Secret in the namespace. That is what makes rollback instant — nothing is rebuilt or re-fetched.

What you are proving: You can see what an upgrade would change before applying it

This step settles no success criterion on its own.

Terminal

helm plugin install https://github.com/databus23/helm-diff
helm diff upgrade demo oci://registry-1.docker.io/bitnamicharts/nginx \
  -n demo --version 18.1.0 --set replicaCount=3

helm upgrade with no preview is the Terraform equivalent of applying without a plan. The diff shows exactly which fields change.

What you are proving: You can explain what atomic does that wait alone does not

Marking this settles success criterion 4.

Terminal

helm upgrade demo oci://registry-1.docker.io/bitnamicharts/nginx \
  -n demo --version 18.1.0 --set replicaCount=3 \
  --atomic --timeout 3m

Flag	Does
`--wait`	Waits for resources to be ready, then reports failure
`--atomic`	`--wait`, and rolls back automatically if it fails
`--timeout`	How long to wait before calling it failed

--wait tells you the release broke. --atomic un-breaks it. The difference is whether a failed deploy at 5pm is an incident or a message.

What you are proving: You can break an upgrade and find the release still serving the previous revision

Marking this settles success criterion 2.

Terminal

helm upgrade demo oci://registry-1.docker.io/bitnamicharts/nginx \
  -n demo --version 18.1.0 \
  --set image.tag=this-tag-does-not-exist \
  --atomic --timeout 90s

The Pods never become ready, the timeout expires, and Helm rolls back on its own:

Terminal

helm history demo -n demo      # a failed revision, then a rolled-back one
kubectl get pods -n demo       # still serving the working image

The release history records the failure — which is what you want. A rollback that hides the attempt makes the postmortem harder.

What you are proving: You can roll back to a named revision and verify the image that is actually running

Marking this settles success criterion 3.

Terminal

helm rollback demo 1 -n demo --wait
helm history demo -n demo
kubectl get deploy -n demo -o jsonpath='{.items[0].spec.template.spec.containers[0].image}'

A rollback is itself a new revision, so history stays append-only and you can always move forward again.

Clean up#

Run this even if you did not finish.

Destructive — This removes real resources. Check which environment you are in first.

Terminal

helm uninstall demo -n demo
kubectl delete namespace demo --ignore-not-found

Cost of this lab: Free — kind or minikube.

Maintained by others, on Killercoda. Useful for extra repetition on one tool — it does not complete this lab or settle any criterion above.

Helm scenarios

Success criteria

0 of 4

The concept behind it

Package Management (Helm)

Ready to try it without help?Do the challenge

Next up

Lab 42 of 59 on the project path

Managing EKS Cluster Add-ons with Helm & IRSAInstall the controllers a cluster needs to be useful, each with its own AWS identity instead of node credentials.39 minIntermediateBillable — destroy resources when you finish

Previous: Creating a Custom Helm Chart for Django Microservices