How to use Helm Hooks for Fun and Profit

This is the first bonus lesson of Helm Lightning Course. In bonus lessons, we are going to learn some advanced features of Helm. You won’t need these features on a daily basis, but it helps to be aware of them and apply them when needed.

The first feature we are going to explore is Helm Hooks. Helm Hooks are exactly what you would expect from the name: it’s a way to run certain tasks before or after the events of the Helm release.

There are 9 types of hooks that you can define, most of them are directly related to the release lifecycle. You can run a hook before or after a release installation, upgrade, rollback or deletion.

There is another special hook called “test” — in this case, the name “hook” is misleading, because Helm tests are executed separately from managing the release itself. Leave us a comment if you would to see a lesson on Helm Tests.

Let’s add a hook to our pgadmin Helm chart. I want to post deployment notifications once the release is upgraded.

I’ve prepared the majority of the code in advance. Let’s go through it.

There is a ConfigMap with a small script inside. This script sends a POST request to mkdev’s community chat, with a simple message that new version of pgadmin was deployed.

To run this script, I am creating a new Job, which mounts ConfigMap and then passes the Helm’s release version to the script. Let’s remove tty option, which I added before for debugging.

In its current form, this ConfigMap and the Job are not Helm hooks. If I run helm upgrade, Helm will create this two objects, and they will become part of the release.

To transform them to hooks, I need to add an annotation to both ConfigMap and the Job. Annotation is named “helm.sh/hook”, and the value should be the part of the lifecycle when I want this hook to run. I want to post notifications every time upgrade is finished, thus I am using “post-upgrade” hook.

I can enforce order in which hook objects are created by adding another annotation, “hook-weight”. The bigger the weight, the earlier it will be created. I want ConfigMap to be created before the Job.

Now let’s upgrade the release.

If I now go to the chat, I see a notification about version 43 deployed. I can do another upgrade, and get another notification.

There are two important things to keep in mind about the hooks.

First is that hooks are just another Helm templates. They don’t have to be jobs or pods. In our example, we created a ConfigMap, and any other Kubernetes object can be a hook.

The second thing is that hooks are not part of the release. This means that if I remove the release, then all the hooks objects will remain. Let’s test that and uninstall pgadmin-production release.

And now I will check the list of Jobs and ConfigMaps. As you can see, both ConfigMap and all the jobs are still here. Hook objects are not managed by helm, you need to be careful not to pollute your environment with too many random objects. You can configure some clean-up rules with hook deletion policy, to remove hook objects right after hook succeeds — it’s good idea to always have this policy configured.

Hooks are a simple, yet powerful feature of Helm. They let you do things like database migrations, notifications, advanced health checks and many other things. Keep in mind their caveats and use them wisely.

Cloud Native consulting: regardless if you are just getting started, or looking for a big shift from the old ways to the future, we are here to help. About consulting

Here's the same article in video form for your convenience: