Skip to main content
In this article, we explore how Helm simplifies lifecycle management in Kubernetes. Helm packages Kubernetes objects into releases, allowing you to install, upgrade, and roll back configurations with ease. Every time you install a chart, Helm creates a release that tracks all associated Kubernetes objects. This tracking enables seamless upgrades, downgrades, or uninstallations without interfering with other releases—all even if multiple releases are based on the same chart. For instance, you can deploy two independent releases from the same WordPress chart:

​
Creating a New Release

Let’s walk through creating a new release. In this example, we install an older version of the NGINX chart using the --version option:
After installation, you might see that the running NGINX pod uses version 1.19.2—a version that, at this point, is considered outdated. Later on, if security vulnerabilities emerge or improvements are required, Helm can update your application without manually modifying each object.

​
Upgrading a Release

Before upgrading, you can verify the current version by describing the pod:
To upgrade the release, execute the following command. In doing so, Helm replaces the old pod with a new one running the updated version:
You can confirm the upgrade by checking the pod details again—the new pod should be running NGINX version 1.21.4.

​
Reviewing Release History

Helm provides commands to inspect a release’s lifecycle. The helm list command displays summary information, including the current revision, while helm history offers detailed revision insights:
This detailed output helps you understand the progression of changes and enables efficient troubleshooting or auditing of configurations.

​
Rolling Back a Release

If an upgrade introduces an unexpected change, you can easily roll back to a previous configuration. Unlike a simple revert, Helm creates a new revision that mirrors the state of the earlier release:
After the rollback, a new revision reflecting the configuration of revision one is recorded, while the revision number continues to increase.

​
Handling Upgrade Dependencies in Kubernetes Packages

When upgrading certain Kubernetes packages, additional parameters are sometimes required. For example, if you attempt to upgrade a WordPress release without supplying the current administrative passwords, you might encounter an error like the following:
Helm requires access to specific administrative passwords to upgrade certain configurations, particularly for external services like databases. If these credentials are not provided during an upgrade, you will encounter errors. Consider implementing dedicated backup and restore strategies (often via Chart Hooks) for persistent data stored on volumes or in external databases.

​
Summary

Helm’s lifecycle management empowers you to:
  • Install releases that package and manage multiple Kubernetes objects.
  • Upgrade releases seamlessly in one command with robust tracking of configuration changes.
  • Roll back to previous states by creating new revisions that reflect past stable configurations.
  • Inspect release history to monitor and audit configuration modifications over time.
Now that you understand lifecycle management with Helm, try applying these concepts in your hands-on practice environment. Happy Helming! For further information, explore:

Watch Video

Practice Lab