This article explores how Helm simplifies lifecycle management of applications on Kubernetes, including tracking, upgrading, and rolling back releases.
In this lesson, we explore how Helm simplifies the entire lifecycle management of applications on Kubernetes. Using practical examples, we will demonstrate how Helm tracks, upgrades, and rolls back releases, ensuring smooth and efficient management of your deployments.
When you install a Helm chart, a release is created. A release is similar to an application—it is a package or collection of Kubernetes objects. Helm meticulously keeps track of the objects associated with each release. This allows you to upgrade, downgrade, or uninstall a release independently without affecting other releases. For example, you can generate multiple releases from the same chart:
Let’s create a new release to see lifecycle management in action. In this example, we install an older version of the NGINX chart by specifying the version option:
After installation, you have an NGINX release named “nginx-release.” Over time—say, two months—security vulnerabilities might be discovered that require patching. In your Kubernetes cluster, the NGINX release might comprise several objects. When you upgrade the Pods running NGINX, you might also need to update other Kubernetes objects (for example, by adding a new environment variable or secret) so that the manifest meets the requirements of the new version.
Helm streamlines the upgrade process by tracking all objects associated with a release, enabling upgrades with a single command. First, verify the version running in your Pod by listing all Pods and then inspecting the target Pod:
$ helm install nginx-release bitnami/nginx --version 7.1.0$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-release-687cdd5c75-ztn2n 0/1 ContainerCreating 0 13s
Once the Pod is running, describe it to confirm the image version:
To upgrade to a newer version, run the following Helm upgrade command:
$ helm upgrade nginx-release bitnami/nginxRelease "nginx-release" has been upgraded. Happy Helming!NAME: nginx-releaseLAST DEPLOYED: Mon Nov 15 19:25:55 2021NAMESPACE: defaultSTATUS: deployedREVISION: 2TEST SUITE: NoneNOTES:CHART NAME: nginxCHART VERSION: 9.5.13APP VERSION: 1.21.4
During this upgrade, Helm replaces the old Pod with a new one running the updated version (NGINX 1.21.4). You can verify the change by listing the Pods again and describing the new Pod.
To view detailed information about each revision, use the Helm history command:
$ helm history nginx-releaseREVISION UPDATED STATUS CHART APP VERSION DESCRIPTION1 Mon Nov 15 19:20:51 2021 superseded nginx-7.1.0 1.19.2 Install complete2 Mon Nov 15 19:25:55 2021 deployed nginx-9.5.13 1.21.4 Upgrade complete
This output provides a comprehensive view of the release’s lifecycle, including chart versions, application versions, and actions like install or upgrade.
If an upgrade introduces undesired changes, Helm supports rollbacks. For instance, to return to revision 1, execute:
$ helm rollback nginx-release 1Rollback was a success! Happy Helming!
Even though the configuration reverts to that of revision 1, Helm creates a new revision (e.g., revision 3) with the same configuration, ensuring a complete record of all release states.
Although Helm manages the configuration and manifest files for Kubernetes objects, it does not back up external data. If your application uses persistent volumes or an external database, a rollback will restore only the pods and configurations. For persistent data, consider using Chart Hooks or backup solutions.
Handling Upgrade Parameters with Additional Requirements
During some upgrades, additional parameters might be necessary. For example, when upgrading a WordPress release, missing administrative passwords can result in errors similar to the following:
$ helm upgrade wordpress-release bitnami/wordpressError: UPGRADE FAILED: template: wordpress/templates/NOTES.txt:83:41: executing "wordpress/templates/NOTES.txt" at <include "common.errors.upgrade.passwords.empty" (dict "validationErrors" $passwordValidationErrors "context" $)>: error calling include: template: wordpress/charts/common/templates/_errors.tpl:21:48: executing "common.errors.upgrade.passwords.empty" at <fail>: error calling fail: PASSWORDS ERROR: You must provide your current passwords when upgrading the release.Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.Further information can be obtained at https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#credential-errors-while-upgrading-chart-releases 'wordpressPassword' must not be empty, please add '--set wordpressPassword=$WORDPRESS_PASSWORD' to the command. To get the current value: export WORDPRESS_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release -o jsonpath="{.data.wordpress-password}" | base64 --decode) 'mariadb.auth.rootPassword' must not be empty, please add '--set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD' to the command. To get the current value: export MARIADB_ROOT_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 --decode) 'mariadb.auth.password' must not be empty, please add '--set mariadb.auth.password=$MARIADB_PASSWORD' to the command. To get the current value: export MARIADB_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb -o jsonpath="{.data.mariadb-password}" | base64 --decode)
In this scenario, Helm requires the current administrative credentials to upgrade the release. Ensure you provide these parameters using the appropriate flags to complete the upgrade successfully.
This lesson demonstrated how Helm manages the lifecycle of your releases—from installation and upgrade to rollback. By keeping track of every state, Helm offers a streamlined and powerful approach to managing your Kubernetes deployments. Now, try these commands to get hands-on practice and enhance your Kubernetes management skills!For further insights, consider exploring these resources:
