Lesson: Installing & Managing Releases

What you'll learn

How to add a repository and install a public chart.
The release lifecycle: install, upgrade, rollback, uninstall.
How to override values safely and preview changes before applying them.
How to inspect what's installed and what changed.

By the end you'll be able to install, upgrade, and roll back an app on the lab cluster with confidence.

The lesson

1. Repositories: where charts come from

A chart repository is an index of published charts. You add one, update your local cache, then search:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx          # find charts matching "nginx"

(Many charts also live on Artifact Hub — search there to discover the repo URL.)

2. Installing a release

helm install <release-name> <chart> creates a named release in the current namespace:

helm install web bitnami/nginx
helm install web bitnami/nginx -n demo --create-namespace   # into a specific namespace

web is your name for this installation. You can install the same chart again under a different name (web2) — they're independent releases.

3. Overriding values (the whole point)

You rarely want a chart's raw defaults. Override them two ways:

# inline, for a few values
helm install web bitnami/nginx --set replicaCount=3 --set service.type=ClusterIP

# from a file, for many values (preferred for real use — it's version-controllable)
helm install web bitnami/nginx -f my-values.yaml

Precedence (last wins): chart defaults → -f files (in order) → --set. Keep your overrides in a file checked into Git (ties back to Module 4) so an install is reproducible.

4. Preview before you change anything

Two habits that save you from surprises:

helm install web bitnami/nginx -f my-values.yaml --dry-run     # render + validate, change nothing
helm template web bitnami/nginx -f my-values.yaml              # just show the manifests

 edit values  ──▶  --dry-run / template  ──▶  read the diff in your head  ──▶  install/upgrade
                         (no cluster change yet)

5. Upgrading and rolling back

This is where Helm earns its keep. Change a value, then upgrade:

helm upgrade web bitnami/nginx -f my-values.yaml --set replicaCount=5
helm upgrade web bitnami/nginx -f my-values.yaml --atomic --timeout 2m   # auto-rollback if it fails

Every upgrade is a new revision. If something breaks, go back:

helm history web                 # list revisions 1,2,3… with status
helm rollback web 1              # return to revision 1

--atomic is the safety net: if the upgrade doesn't become healthy within --timeout, Helm rolls it back for you automatically. Use it for anything important.

6. Inspecting and cleaning up

helm list -A                     # all releases across all namespaces
helm status web                  # current state + the NOTES.txt message
helm get values web              # the values this release was installed with
helm get manifest web            # the actual manifests Helm applied
helm uninstall web               # remove the release (and its objects)

On the lab, run these from the Jumpbox (where helm and the kubeconfig are ready) against the live cluster. helm list -A is a great first command to see what's already running.

7. A note on namespaces and state

Helm stores release info in the cluster (as Secrets in the release's namespace), not on your laptop — so anyone with cluster access sees the same releases via helm list. Be deliberate about which -n <namespace> you target; installing into the wrong namespace is the most common beginner mix-up.

Dig deeper

Search terms

helm install upgrade rollback tutorial
helm --set vs values file precedence
helm dry-run template preview
helm upgrade --atomic explained
helm history rollback revision

Check yourself

What's the difference between a chart and a release name in helm install web bitnami/nginx?
Give the value-override precedence order (defaults, -f, --set).
Which flags let you preview an install/upgrade without changing the cluster?
What does --atomic do on an upgrade, and why is it useful?
How would you list every revision of a release and return to an earlier one?