Lifecycle Management with Helm

In this blog, we can see how we can do Lifecycle Management with Helm.

Upgrading Releases with Helm

Now lifecycle management can sound like a fancy technical term that’s too abstract to understand at first glance. So let’s translate into plain English by taking a look at practical examples. 

Each time we pull in a chart and install it, a release is created. A release is somewhat similar to an app, but more specifically, it represents a package or a collection of Kubernetes objects. Since Helm knows what Kubernetes objects belong to each release, it can do things like upgrades, downgrades, or uninstalls, without touching objects that might belong to other releases. So each release can be managed independently, even if they’re all based on the same chart.

Let’s just create a new release and discuss this as we go along. We’ll install a pretty old version of this chart.

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

We now have an Nginx release, plainly called nginx-release. Now imagine 2 months go by. That’s a long time for any piece of software, but especially for a website. A lot of security vulnerabilities get discovered and they need to be patched up.

Our Nginx-hosted website may have many objects in our Kubernetes cluster. When we upgrade the pods running Nginx, maybe we also need to make some changes to other Kubernetes objects. But it may be hard to keep track of all the pieces that need to be changed. Fortunately, as we said, Helm keeps track of everything associated with a release. So we don’t have to upgrade our objects one by one. Helm can automatically upgrade them all, with one single command.

But first, let’s see, what version of Nginx is running in our pod. We initially have to find out the name of our Nginx pod.

Pretty old. Now let’s see a Helm upgrade in action. The command is rather simple, we just tell Helm what release we want to upgrade, then specify the chart that this release is based on.

In the upgrade process, the old pod gets destroyed and a new one gets created, so we’ll need to get the name of the new one.

You can see how we have a newer version running here.

So there you have it, we just went through the so-called Lifecycle Management with Helm. A release can exist for months or years. Helm can manage its lifecycle in many ways, by keeping track of its current state, previous states and bringing it into future states. So, in this case, we brought the release into a future state, by upgrading it. But Helm kept a record of the previous state too. We noticed the revision number changing to “2”, so the previous state would be revision “1”. Now how does that help us?

Rolling Back Releases with Helm

If we take a look at our releases:

We can clearly see a lot of useful things:

• What chart version was/is used in each revision.
• Which app version was/is used in each revision.
• What action actually created that revision. Was it an install, an upgrade, a rollback?

So this paints a clear picture of the stages our release went through, its lifecycle history.

Now let’s assume this upgrade did something we don’t like. Helm’s lifecycle management allows for another cool thing called rollback. This lets us return a release to a previous state. So, in this case, we want to return to revision 1.

We see the old Nginx version restored.

And Helm also recorded this change in the release’s state.

It’s worth mentioning that we chose Nginx here as it’s simple to upgrade. But there will be Kubernetes packages that may require a few extra steps to upgrade. For example, if we’d have tried to upgrade the previous WordPress release we created, we would have got this output:

Now that’s not to say that this is a problem. It can be easily solved by adding some more parameters to the command line as instructed in the text. Why does this happen? In this case, Helm cannot upgrade everything without having access to some administrative passwords. It needs administrative access to the database and to the WordPress website itself so that it can get permissions to make necessary changes.

It’s also worth mentioning that although rollbacks are very similar to a backup/restore feature, it doesn’t cover file/directory data that may be created by our applications. Instead, Helm backs up and restores the declarations/manifests of our Kubernetes objects. So for things that use Persistent Volumes or other forms of persistent data, a rollback won’t restore that data too. For example, imagine you rollback a MySQL database server. The MySQL pods will be restored to their previous states, software versions used, and so on, but the actual database, its data, will remain the same.

Checkout the Helm for the Absolute Beginners course here

Checkout the Complete Kubernetes learning path here