Mastering Helm Hooks: Control Your Release Lifecycle

Helm hooks exist to give you, the chart developer, the ability to intervene at strategic points in a release's lifecycle. This is crucial for automating tasks that need to happen before or after certain events, such as installations or upgrades. For instance, when you run helm install foo, the default lifecycle processes the installation without any custom logic. By implementing hooks, you can alter this flow, adding operations that execute at specific moments, like running a job after the installation completes.

The mechanism works through annotations in your resource definitions. For example, you can define a post-install hook with the annotation helm.sh/hook: post-install. You can also set hook weights using helm.sh/hook-weight, which allows you to control the execution order of multiple hooks. The default weight is 0, but you can assign negative or positive values to dictate when hooks run relative to each other. Additionally, the helm.sh/hook-delete-policy annotation helps manage the lifecycle of hook resources, with options like before-hook-creation and hook-succeeded to determine when these resources should be cleaned up. Remember that hooks can block operations; the Helm client will pause while a job runs, which can affect deployment speed.

In production, understanding the implications of hooks is vital. For example, if you create resources within a hook, you can't rely on helm uninstall to remove them later. This can lead to orphaned resources if not managed carefully. Also, be aware that the crd-install hook has been removed in Helm 3, so you should use the crds/ directory instead. Starting from Helm 3.2.0, hooks with the same weight are installed in the same order as non-hook resources, which can simplify your deployment logic.