Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

Installing, Upgrading, and Rolling Back

9 min read Chapter 66 of 87
Summary

Covers the full Helm release lifecycle: helm install...

Covers the full Helm release lifecycle: helm install with --set and -f overrides, namespace targeting with -n, listing releases with helm list, checking status with helm status, upgrading with helm upgrade, atomic installs with helm upgrade --install, revision history with helm history, rolling back with helm rollback, and clean removal with helm uninstall. Includes exam-relevant patterns and common pitfalls.

Installing, Upgrading, and Rolling Back

With a chart found and its values understood, the next step is the release lifecycle: creating a release, modifying it, reverting mistakes, and cleaning up. Every command in this section maps directly to exam tasks — the CKAD frequently asks you to install a chart with specific values, upgrade a release, or roll back to a previous revision.

Installing a Release

The helm install command creates a new release from a chart:

helm install my-nginx bitnami/nginx

The first argument (my-nginx) is the release name — your chosen identifier for this installation. The second argument (bitnami/nginx) is the chart reference. Helm renders the chart templates with default values, applies the resulting manifests to the cluster, and records the release in the current namespace.

Install with Value Overrides

Override defaults using --set:

helm install my-nginx bitnami/nginx \
  --set replicaCount=3 \
  --set service.type=NodePort

Or provide a values file with -f:

helm install my-nginx bitnami/nginx -f custom-values.yaml

Combine both — --set takes precedence over file values:

helm install my-nginx bitnami/nginx \
  -f custom-values.yaml \
  --set image.tag=1.25.5

Install into a Specific Namespace

By default, Helm installs into the namespace configured in your kubeconfig context. Target a specific namespace with -n:

helm install my-nginx bitnami/nginx -n web-apps

If the namespace doesn’t exist, add --create-namespace:

helm install my-nginx bitnami/nginx \
  -n web-apps \
  --create-namespace

This creates the web-apps namespace and installs the release into it in a single command. Without --create-namespace, Helm fails if the namespace is missing.

Waiting for Readiness

By default, helm install returns immediately after submitting resources to the API server, without waiting for Pods to become Ready. To block until all resources are healthy:

helm install my-nginx bitnami/nginx --wait --timeout 5m

The --wait flag tells Helm to monitor the release resources until they reach a ready state. The --timeout flag sets the maximum wait duration (default is 5 minutes). If resources don’t become ready within the timeout, the install is marked as failed.

Generate a Release Name

If you don’t care about the release name, let Helm generate one:

helm install bitnami/nginx --generate-name
NAME: nginx-1709234567
...

Helm generates a name by appending a timestamp to the chart name. This is useful for quick experiments but makes releases harder to manage — prefer explicit names for anything beyond throwaway tests.

Listing Releases

helm list

View all releases in the current namespace:

helm list
NAME      NAMESPACE  REVISION  UPDATED                   STATUS    CHART          APP VERSION
my-nginx  default    1         2026-02-15 10:30:00 UTC   deployed  nginx-15.14.0  1.25.4

Key columns:

  • REVISION — the current revision number (starts at 1, increments on each upgrade)
  • STATUS — deployed, failed, pending-install, pending-upgrade, or uninstalled
  • CHART — chart name and version

List releases across all namespaces:

helm list -A

List releases in a specific namespace:

helm list -n web-apps

Filter by status:

helm list --failed
helm list --deployed

helm status

Get detailed information about a specific release:

helm status my-nginx
NAME: my-nginx
LAST DEPLOYED: Sun Feb 15 10:30:00 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
...

The output includes the release status, the deployment timestamp, and the chart’s NOTES.txt content — which typically contains instructions for accessing the application (port-forward commands, URLs, etc.).

Check the status of a release in another namespace:

helm status my-nginx -n web-apps

Upgrading a Release

helm upgrade

Modify a deployed release with new values or a new chart version:

helm upgrade my-nginx bitnami/nginx --set replicaCount=5

This creates a new revision of the release. Helm computes the difference between the current state and the desired state, then applies only the changed resources. The revision number increments from 1 to 2.

Upgrade with a values file:

helm upgrade my-nginx bitnami/nginx -f production-values.yaml

Upgrade to a specific chart version:

helm upgrade my-nginx bitnami/nginx --version 15.13.2

Important: Values Are Not Inherited

A critical detail that catches many people: helm upgrade does not automatically inherit values from the previous revision. If you installed with --set replicaCount=3 and then upgrade with --set service.type=NodePort, the replica count reverts to the chart default (typically 1).

To preserve previously set values during an upgrade, add --reuse-values:

helm upgrade my-nginx bitnami/nginx \
  --set service.type=NodePort \
  --reuse-values

This merges your new overrides with the values from the current revision. Without --reuse-values, only the values you explicitly provide (plus chart defaults) are used.

helm upgrade —install

The --install flag makes the upgrade command idempotent — if the release doesn’t exist, Helm creates it; if it does exist, Helm upgrades it:

helm upgrade --install my-nginx bitnami/nginx \
  -f custom-values.yaml \
  -n web-apps \
  --create-namespace

This is the preferred pattern for CI/CD pipelines and automation scripts. Instead of checking whether a release exists and branching between helm install and helm upgrade, a single helm upgrade --install command handles both cases. The --create-namespace flag ensures the namespace exists, making the entire operation idempotent.

On the exam, helm upgrade --install saves time and avoids errors when you’re unsure whether a prior installation exists.

Release History

helm history

View the revision history of a release:

helm history my-nginx
REVISION  UPDATED                   STATUS       CHART          APP VERSION  DESCRIPTION
1         Sun Feb 15 10:30:00 2026  superseded   nginx-15.14.0  1.25.4       Install complete
2         Sun Feb 15 11:45:00 2026  superseded   nginx-15.14.0  1.25.4       Upgrade complete
3         Sun Feb 15 12:00:00 2026  deployed     nginx-15.14.0  1.25.4       Upgrade complete

Each revision represents a snapshot: the chart version, the applied values, and the Kubernetes manifests at that point. The STATUS column shows which revision is currently active (deployed) and which are historical (superseded).

Inspecting a Specific Revision

Check the values used in a previous revision:

helm get values my-nginx --revision 1

View the manifests generated for a previous revision:

helm get manifest my-nginx --revision 1

These commands are invaluable for debugging — comparing what changed between revisions helps pinpoint configuration drift.

Rolling Back

helm rollback

Revert a release to a previous revision:

helm rollback my-nginx 2

This rolls the release back to revision 2. Helm re-applies the manifests from that revision, creating a new revision in the process:

helm history my-nginx
REVISION  UPDATED                   STATUS       CHART          APP VERSION  DESCRIPTION
1         Sun Feb 15 10:30:00 2026  superseded   nginx-15.14.0  1.25.4       Install complete
2         Sun Feb 15 11:45:00 2026  superseded   nginx-15.14.0  1.25.4       Upgrade complete
3         Sun Feb 15 12:00:00 2026  superseded   nginx-15.14.0  1.25.4       Upgrade complete
4         Sun Feb 15 12:15:00 2026  deployed     nginx-15.14.0  1.25.4       Rollback to 2

Notice that the rollback creates revision 4 with the description “Rollback to 2”. The rollback does not delete revision 3 — the full history is preserved. The revision number only moves forward.

Roll back to the immediately previous revision (shorthand):

helm rollback my-nginx

Without a revision number, Helm rolls back to current revision - 1.

Rollback with Wait

Like install and upgrade, rollback supports --wait:

helm rollback my-nginx 2 --wait --timeout 3m

Uninstalling a Release

helm uninstall

Remove a release and all its Kubernetes resources:

helm uninstall my-nginx
release "my-nginx" uninstalled

This deletes the Deployment, Service, ConfigMap, and every other resource that the chart created. It also removes the release metadata from the cluster.

Uninstall a release in a specific namespace:

helm uninstall my-nginx -n web-apps

Keeping History After Uninstall

If you want to preserve the release history for auditing or future rollback:

helm uninstall my-nginx --keep-history

With --keep-history, the release status changes to uninstalled but its history remains accessible via helm history my-nginx. You could then roll back to a previous revision to re-deploy the application.

Without --keep-history, all release records are permanently deleted.

Exam-Relevant Command Reference

A compact reference of the commands most likely to appear on the CKAD exam:

TaskCommand
Add a repositoryhelm repo add bitnami https://charts.bitnami.com/bitnami
Update repository metadatahelm repo update
Search for chartshelm search repo nginx
Show chart valueshelm show values bitnami/nginx
Install a releasehelm install my-app bitnami/nginx -f values.yaml
Install into namespacehelm install my-app bitnami/nginx -n ns --create-namespace
List releaseshelm list / helm list -A
Check release statushelm status my-app
Get applied valueshelm get values my-app
Upgrade a releasehelm upgrade my-app bitnami/nginx --set key=val
Idempotent install/upgradehelm upgrade --install my-app bitnami/nginx
View release historyhelm history my-app
Roll backhelm rollback my-app <revision>
Uninstallhelm uninstall my-app

Time-Saving Exam Patterns

Pattern 1: Always use helm upgrade --install. On the exam, you may lose track of whether you already installed a release. Using upgrade --install avoids “release already exists” errors.

Pattern 2: Redirect values to a file, then edit. Instead of trying to remember value paths, dump the defaults and grep:

helm show values bitnami/nginx > /tmp/vals.yaml
grep -n "replica" /tmp/vals.yaml

Pattern 3: Use --dry-run before committing. If you’re uncertain about your values, run with --dry-run first to verify the generated manifests.

Pattern 4: Check helm list after every operation. Verify the revision number and status changed as expected. A quick helm list takes two seconds and catches mistakes before they compound.

Pattern 5: Know the namespace flag. Nearly every Helm command accepts -n <namespace>. If a release isn’t showing up in helm list, you’re probably looking in the wrong namespace. Use helm list -A to search all namespaces.