Certified Kubernetes Application Developer (CKAD) #9 Helm: install, upgrade, rollback, values

In #8 Deployment strategies, we hand-built the patterns for zero-downtime deployment with blue-green and canary. But in practice, deploying a single application doesn’t end with one Deployment. A Deployment, Service, ConfigMap, Secret, and Ingress travel together as a bundle, and you have to repeatedly manage manifests that differ only slightly in their values from one environment to the next. The tool that installs this bundle of manifests as a single package, versions it, rolls it forward, and reverts it is Helm.

Helm’s exam weight in CKAD isn’t large. Still, it falls under the Application Deployment domain, so the basic flow of installing a chart, changing values and reapplying, and rolling back when something goes wrong is in scope. Rather than deep chart authoring, this post focuses on operating the helm command — we’ll learn it by typing along by hand.

The problem Helm solves #

In K8s practice track #2, we covered the flow of applying manifests with kubectl apply -f. That’s enough for a simple app, but real-world applications come with the following burdens.

• One app is made up of multiple manifests — Deployment, Service, ConfigMap, Secret, Ingress, and more
• Across dev, staging, and prod, only values like the replica count, image tag, and domain differ
• When you deploy a new version and something breaks, you need to revert to the previous state in one shot
• You want to install an externally built application (e.g., PostgreSQL, Redis) with a vetted configuration

Helm packages this bundle of manifests into something called a chart, injects values into it, and manages the result of installing it on the cluster as a release. Just as a package manager installs, upgrades, and removes software, Helm does the same for Kubernetes applications.

Core concepts: chart, release, repository #

Get just three words straight and the Helm commands fall into place at a glance.

Install the same chart multiple times under different names and each becomes a separate release. A release’s revision number increments with each upgrade, and that number is the reference point for rollback.

A chart’s directory structure #

A chart is a bundle with a fixed directory structure. You’ll rarely author one yourself, but knowing the structure clarifies where values come from.

mychart/
  Chart.yaml          # Chart metadata (name, version, appVersion)
  values.yaml         # Default values. The starting point before --set or -f override
  templates/          # Manifests written as Go templates
    deployment.yaml
    service.yaml
    _helpers.tpl      # Template helpers (naming conventions, etc.)
  charts/             # Holds dependent charts (subcharts)

Manifests inside templates/ reference values like {{ .Values.replicaCount }}, and those values start from the defaults in values.yaml and get overridden by --set or -f. You could say this flow is all there is to Helm.

helm create scaffolds the standard skeleton in one shot.

helm create mychart

Registering and searching repositories #

To use an external chart, first register the repository and refresh the index.

# Register a repository
helm repo add bitnami https://charts.bitnami.com/bitnami

# Refresh the index of registered repositories (always before install)
helm repo update

# List registered repositories
helm repo list

# Search a repository for charts
helm search repo nginx
helm search repo bitnami/postgresql

If you skip helm repo update, you may install from a stale index, so getting into the habit of refreshing once before install is the safe move. To check which values of a chart you can change, helm show values is handy.

# Print the chart's default values.yaml as-is
helm show values bitnami/nginx

install: installing a chart as a release #

Installation takes the form helm install <release name> <chart>. The key point is that you set the release name yourself.

# Install bitnami/nginx as a release named myweb
helm install myweb bitnami/nginx

# Install into a specified namespace (created if absent)
helm install myweb bitnami/nginx --namespace web --create-namespace

# List installed releases
helm list

# Releases across all namespaces
helm list -A

# Status of a specific release
helm status myweb

helm list shows the release name, revision, status (deployed), and chart version. If the release is healthy, confirm the Pods and Services the chart produced with kubectl get all -n web.

Auto-generating the release name #

When naming is a chore, you can let Helm generate the name with --generate-name. That said, the exam usually asks you to specify the release name, so it’s better to get comfortable with the form where you set it yourself.

helm install bitnami/nginx --generate-name

values overrides: same chart, different configuration #

A chart’s real value lies in installing it differently per environment by changing only the values. There are two ways to override values.

Inline specification with --set #

Used when changing one or two simple values.

# A single value
helm install myweb bitnami/nginx --set replicaCount=3

# Nested values with dot notation, multiple with commas
helm install myweb bitnami/nginx \
  --set replicaCount=3 \
  --set image.tag=1.27

# Array index notation
helm install myweb bitnami/nginx --set ingress.hosts[0].host=example.com

Specifying a values file with -f #

When there are many values to change, or you want to split configuration by environment, pass a separate YAML file.

# myvalues.yaml
replicaCount: 3
image:
  tag: "1.27"
service:
  type: ClusterIP

helm install myweb bitnami/nginx -f myvalues.yaml

# Layer multiple files (later ones take precedence)
helm install myweb bitnami/nginx -f base.yaml -f prod.yaml

Value precedence #

When the same key is specified in multiple places, it’s overridden in a fixed order. The further down the list, the higher the precedence.

1. The chart’s values.yaml (lowest, the defaults)
2. Files passed with -f (with multiple, later files win)
3. Values specified with --set (highest)

In other words, --set overrides more strongly than any file value. If you specify one key in both a -f file and --set, the --set value applies. When the final applied value is unclear, check it with helm get values.

# The user-specified values actually applied to the release
helm get values myweb

# The full values including defaults
helm get values myweb -a

upgrade and rollback #

To change values or the chart version after installation, use helm upgrade. The revision goes up with each upgrade, and that history lets you revert at any time.

# Upgrade with changed values (revision increments to 2)
helm upgrade myweb bitnami/nginx --set replicaCount=5

# Install if the release doesn't exist, upgrade if it does
helm upgrade --install myweb bitnami/nginx -f prod.yaml

# A release's revision history
helm history myweb

helm upgrade --install handles things in one command without caring whether the release exists, so it’s frequently used in CI pipelines.

rollback: reverting to a previous revision #

When an upgrade goes wrong, check the revision number with helm history and revert with helm rollback.

# Check the history
helm history myweb
# REVISION  STATUS      CHART        ...
# 1         superseded  nginx-15.0.0
# 2         deployed    nginx-15.0.0

# Revert to revision 1 (a new revision 3 is created)
helm rollback myweb 1

# Omit the number to revert to the immediately previous revision
helm rollback myweb

A rollback restores the past state exactly while creating a new revision. So rolling back to revision 1 gives content identical to revision 1, but it is recorded in history as revision 3. Keep this in mind so the numbers don’t confuse your next operation.

Previewing before applying: template and dry-run #

Just as we emphasized kubectl --dry-run in #1, Helm too has ways to check the result before applying. Making it a habit to take a look before a wrong install in the exam saves time.

# Print only the rendered manifests without applying to the cluster
helm template myweb bitnami/nginx -f myvalues.yaml

# Follow the actual install flow exactly but don't apply (includes server-side validation)
helm install myweb bitnami/nginx --dry-run --debug -f myvalues.yaml

helm template renders the templates locally, so it’s fast, while --dry-run --debug sends the result to the API server and goes through validation too, making it closer to a real install. When checking whether values were applied as intended, look directly at the replicas: or image: lines in the rendered output.

uninstall: removing a release #

Deleting a release removes all the resources that release created along with it.

# Remove a release
helm uninstall myweb

# Remove from a specified namespace
helm uninstall myweb --namespace web

# Remove but keep the history (for rollback)
helm uninstall myweb --keep-history

By default, history is deleted along with the release. If there’s a chance you’ll need to revert later, add --keep-history.

Exam points #

• The three concepts. Distinguish chart (raw material), release (install result, holds revisions), repository (the store) precisely
• install form. helm install <release> <repo/chart>. Remember where the release name goes
• value precedence. values.yaml < -f file < --set. --set wins
• upgrade and rollback. helm upgrade increments the revision, helm history checks the number, helm rollback <release> <revision> restores the state. A rollback also creates a new revision
• previewing. helm template renders locally, helm install --dry-run --debug includes server-side validation
• check commands. Inspect install status and applied values with helm list, helm status, helm get values
• repo refresh. Don’t skip helm repo update before install

Wrap-up #

What this post locked in:

• Helm is a tool that treats a bundle of manifests as a package. The result of installing a chart with values is a release
• The repo flow. Find charts with helm repo add → helm repo update → helm search repo
• install and values. Override values on helm install <release> <chart> with --set or -f. --set takes top priority
• upgrade and rollback. Bump the revision with helm upgrade, and revert with helm history and helm rollback
• preview and removal. Check the result with helm template, --dry-run --debug and clean up with helm uninstall

Helm’s weight in CKAD is small, but you need the basic commands — install, upgrade, values, rollback — in your fingers so you don’t get stuck.

Next: Kustomize #

If Helm packages manifests through templates and value injection, the tool that solves the same problem without templates, using patches is Kustomize.

In #10 Kustomize: overlay patterns, per-environment manifests, we’ll build it ourselves and organize how to compose per-environment manifests with base and overlay, the structure of kustomization.yaml, the flow of applying with kubectl apply -k, and when to pick Helm vs. Kustomize.