Skip to content

10.08 Lifecycle Management With Helm

Abstract

Lifecycle Management with Helm means managing an application release from installation to upgrades, rollback, history tracking, and uninstall.

Helm treats a Kubernetes application as a release, not just a group of separate YAML objects.

This makes production operations easier because Helm tracks what was installed, what changed, and how to revert safely.

What Is a Helm Release?

A release is one installation of a Helm chart.

You can install the same chart multiple times using different release names.

helm install my-site bitnami/wordpress
helm install my-SECOND-site bitnami/wordpress

Each release is managed independently.

Release Chart Purpose
my-site bitnami/wordpress Main WordPress site
my-SECOND-site bitnami/wordpress Second WordPress site

Note

The same chart can be reused many times.
Each installation becomes a separate release with its own revision history.

Why Lifecycle Management Matters

Without Helm, you must manually manage many Kubernetes objects:

  • Deployments
  • Services
  • ConfigMaps
  • Secrets
  • PVCs
  • Ingress objects
  • Jobs
  • StatefulSets

Helm tracks these objects as one application package.

Success

Helm lets you install, upgrade, rollback, and uninstall an application using release-level commands instead of managing every Kubernetes object manually.

Helm Release Lifecycle

Typical Helm release lifecycle:

Install chart
    ↓
Revision 1 created
    ↓
Upgrade release
    ↓
Revision 2 created
    ↓
Rollback if needed
    ↓
Revision 3 created
    ↓
Uninstall release

Tip

Every major Helm action creates a new revision, which helps track application history.

Installing a Specific Chart Version

You can install a specific chart version using --version.

helm install nginx-release bitnami/nginx --version 7.1.0

Check the pod:

kubectl get pods

Describe the pod to verify the image version:

kubectl describe pod <pod-name>

Example output:

Image: docker.io/bitnami/nginx:1.19.2-debian-10-r28

Example

Installing an older chart version is useful for testing upgrades or reproducing production issues.

Upgrading a Release

To upgrade a release:

helm upgrade nginx-release bitnami/nginx

After upgrade, Helm creates a new revision.

Example output:

Release "nginx-release" has been upgraded. Happy Helming!

REVISION: 2
CHART: nginx-9.5.13
APP VERSION: 1.21.4

Verify the new pod:

kubectl get pods
kubectl describe pod <new-pod-name>

Example upgraded image:

Image: docker.io/bitnami/nginx:1.21.4-debian-10-r0

Note

During an upgrade, Kubernetes may terminate old pods and create new pods depending on the workload strategy.

Upgrade Command Pattern

helm upgrade <release-name> <chart-name>

Example:

helm upgrade nginx-release bitnami/nginx

With custom values:

helm upgrade nginx-release bitnami/nginx   -f values-prod.yaml

Upgrade or install if missing:

helm upgrade --install nginx-release bitnami/nginx   -f values-prod.yaml

Tip

helm upgrade --install is commonly used in CI/CD pipelines because it works for both first deployment and later updates.

Viewing Releases

List releases:

helm list

Example:

NAME            NAMESPACE   REVISION   STATUS      CHART          APP VERSION
nginx-release   default     2          deployed    nginx-9.5.13   1.21.4

Note

helm list shows the current state of each release, including namespace, revision, chart version, and app version.

Viewing Release History

Use helm history to see all revisions of a release.

helm history nginx-release

Example:

REVISION   UPDATED                  STATUS      CHART        APP VERSION   DESCRIPTION
1          Mon Nov 15 19:20:51       superseded  nginx-7.1.0  1.19.2        Install complete
2          Mon Nov 15 19:25:55       deployed    nginx-9.5.13 1.21.4        Upgrade complete

Success

helm history helps troubleshoot what changed, when it changed, and which chart/app version was used.

Rolling Back a Release

If an upgrade causes issues, rollback to a previous revision.

helm rollback nginx-release 1

Example output:

Rollback was a success! Happy Helming!

Note

Helm does not technically move back to revision 1.
It creates a new revision using the configuration from revision 1.

Example:

Revision 1 → Initial install
Revision 2 → Upgrade
Revision 3 → Rollback to revision 1 configuration

Rollback Command Pattern

helm rollback <release-name> <revision-number>

Example:

helm rollback nginx-release 1

Check history again:

helm history nginx-release

You should see a new revision created for the rollback.

Warning

Rollback restores Kubernetes manifests, not application data stored inside databases or persistent volumes.

Helm Rollback vs Data Restore

Helm rollback restores:

  • Deployment specs
  • Service specs
  • ConfigMaps
  • Secret references
  • Chart-managed Kubernetes manifests

Helm rollback does not restore:

  • Database records
  • Files inside persistent volumes
  • External cloud resources not managed by the chart
  • Application-level user data

Danger

Do not treat helm rollback as a database backup or disaster recovery solution.

Example: WordPress Upgrade Issue

Some charts require existing passwords during upgrade.

Example upgrade:

helm upgrade wordpress-release bitnami/wordpress

Possible error:

PASSWORDS ERROR: You must provide your current passwords when upgrading the release.

The chart may ask you to retrieve existing secrets:

export WORDPRESS_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release   -o jsonpath="{.data.wordpress-password}" | base64 --decode)

export MARIADB_ROOT_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb   -o jsonpath="{.data.mariadb-root-password}" | base64 --decode)

export MARIADB_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb   -o jsonpath="{.data.mariadb-password}" | base64 --decode)

Then upgrade with required values:

helm upgrade wordpress-release bitnami/wordpress   --set wordpressPassword=$WORDPRESS_PASSWORD   --set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD   --set mariadb.auth.password=$MARIADB_PASSWORD

Warning

Some charts validate credentials during upgrades.
Always read the chart upgrade notes before upgrading production releases.

Production Upgrade Workflow

Recommended production workflow:

Check current release
      ↓
Review chart changelog
      ↓
Render manifests
      ↓
Run dry-run
      ↓
Backup data if required
      ↓
Upgrade release
      ↓
Validate application
      ↓
Rollback if needed

Commands:

helm list
helm history nginx-release
helm show values bitnami/nginx
helm template nginx-release bitnami/nginx -f values-prod.yaml
helm upgrade nginx-release bitnami/nginx -f values-prod.yaml --dry-run --debug
helm upgrade nginx-release bitnami/nginx -f values-prod.yaml

Tip

Use --dry-run --debug before production upgrades to preview what Helm will apply.

Helm Lifecycle Commands

Task Command
Install release helm install <release> <chart>
Install specific chart version helm install <release> <chart> --version <version>
List releases helm list
Upgrade release helm upgrade <release> <chart>
Upgrade or install helm upgrade --install <release> <chart>
View history helm history <release>
Rollback release helm rollback <release> <revision>
Uninstall release helm uninstall <release>
Dry-run upgrade helm upgrade <release> <chart> --dry-run --debug

Tabs: Common Lifecycle Operations

helm install nginx-release bitnami/nginx --version 7.1.0

helm upgrade nginx-release bitnami/nginx

helm history nginx-release

helm rollback nginx-release 1

helm uninstall nginx-release

Best Practices

Recommended

  • Use meaningful release names
  • Pin chart versions in production
  • Store values files in Git
  • Use helm history before rollback
  • Use --dry-run --debug before upgrades
  • Backup databases before upgrading stateful applications
  • Read chart release notes before upgrading
  • Use separate releases for dev, test, and prod

Do's

  • Use helm list to verify release status
  • Use helm history before rollback decisions
  • Use helm upgrade --install in automation
  • Use custom values files for repeatable releases
  • Validate pods after upgrade
  • Backup persistent data before major upgrades
  • Roll back quickly if production validation fails

Don'ts

  • Don't upgrade production blindly
  • Don't assume rollback restores database data
  • Don't skip chart-specific upgrade instructions
  • Don't use random release names
  • Don't manually edit Helm-managed Kubernetes objects unless necessary
  • Don't pass sensitive passwords directly in shell history
  • Don't forget to verify app health after upgrade

Troubleshooting

Question

Upgrade failed?

Check:

  • Did the chart require existing passwords?
  • Did you pass the correct values file?
  • Did you change chart versions too far at once?
  • Are pods stuck in ImagePullBackOff or CrashLoopBackOff?
  • Did PVCs or Secrets remain from the old release?
  • Did you run helm upgrade --dry-run --debug?

Useful commands:

helm list
helm history <release>
helm status <release>
kubectl get pods
kubectl describe pod <pod-name>
kubectl get events --sort-by=.metadata.creationTimestamp

Production Notes

Danger

Stateful applications require extra care.

For applications like WordPress, MySQL, PostgreSQL, Redis, or Elasticsearch, Helm rollback only reverts Kubernetes object definitions. It does not automatically restore application data.

Use proper backup tools for:

  • databases
  • persistent volumes
  • object storage
  • external dependencies

Summary

Quote

  • Helm manages applications as releases
  • Each install, upgrade, or rollback creates a revision
  • helm history shows the lifecycle of a release
  • helm rollback restores Kubernetes manifests to a previous revision
  • Rollback does not restore persistent application data
  • Production upgrades should include dry-runs, backups, validation, and rollback planning