This article explores managing Kubernetes application lifecycles using Helm, covering releases, upgrades, and rollbacks with practical examples.
In this article, we explore how to effectively manage the lifecycle of Kubernetes applications using Helm. Learn how Helm handles releases, upgrades, and rollbacks through real-world examples that simplify complexity and enhance application management.
When you install a Helm chart, a release is created. Each release is like an application package—a collection of related Kubernetes objects. Since Helm tracks all objects associated with a release, it allows you to upgrade, downgrade, or uninstall a release without affecting other deployments. For instance, even if you deploy the same chart twice, each release remains independent:
This command deploys an NGINX release named “nginx-release” using an earlier version of NGINX. After installation, verify the Pod status and details of the image:
Copy
Ask AI
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-release-687cdd5c75-ztn2n 0/1 ContainerCreating 0 13s
Once the Pod is running, get detailed information about the image:
In this case, the installed NGINX version is 1.19.2, which might become outdated over time.
If you discover security vulnerabilities or need feature updates, Helm makes it easy to upgrade your application along with all associated Kubernetes configurations.
Helm’s upgrade functionality allows seamless transition to new versions. When you upgrade a release, Helm replaces the old Pod with a new one that includes updated settings and images. Here’s an example of upgrading the existing NGINX release:
Copy
Ask AI
$ 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
After upgrading, verify the updates with the following commands:
If an upgrade leads to unexpected behavior, Helm supports rollbacks. Rolling back reverts the release to its previous known-good state. For example, to rollback the NGINX release to revision 1, run:
Copy
Ask AI
$ helm rollback nginx-release 1Rollback was a success! Happy Helming!
After a rollback, the configuration reverts to the settings in revision 1. However, note that Helm records this as a new revision, providing a complete history for audit and troubleshooting.
Remember that while rollbacks restore Kubernetes manifest configurations, they do not include the actual data stored in persistent volumes or external databases. Always ensure you have a separate backup solution for persistent data.
When working with more complex applications, such as WordPress, additional parameters might be required during an upgrade. Missing these parameters can result in errors like the one below:
Copy
Ask AI
$ helm upgrade wordpress-release bitnami/wordpressError: UPGRADE FAILED: template: wordpress/templates/NOTES.txt:83:4: executing "wordpress/templates/NOTES.txt" at <include "common.errors.upgrade.passwords.empty" ...>: 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)
This error indicates that administrative credentials must be provided for certain components during the upgrade. Always supply the necessary parameters to ensure that all Kubernetes objects and application components are appropriately updated.
Update an existing release to a new version with all associated configurations.
helm upgrade my-release bitnami/nginx
Rollback
Revert a release to a previous configuration state in case of issues.
helm rollback my-release 1
By following the practices outlined in this article, you can streamline application management across your Kubernetes clusters. Practice these Helm commands with hands-on exercises to deepen your understanding and improve your deployment workflows.For more information, consider exploring the Helm Documentation.
