Helm Chart Hooks Tutorial | Rafay

Helm Chart Hooks Tutorial

January 20, 2021

Phani Mahavrathayajula

Helm chart hooks are a useful tool in your Kubernetes deployments and are used to perform certain actions at specific points in a release cycle. Helm supports a variety of hooks and this blog serves as a tutorial to help you quickly learn how and when you can use them to make your kubernetes management process as efficient and repeatable as possible.

What are Helm Chart Hooks?

Oftentimes a Helm chart developer may want to perform some auxiliary operations before installing the main service or upgrading the main service that are required for the main service to function in the correct manner. Typically, these operations are one time operations that are performed during a specific stage of the chart. Helm chart hooks provide the ability to perform these operations in a release lifecycle. Helm chart hooks get deployed onto the cluster as kubernetes resources, but are cleaned up according to the hook clean up policy. Helm chart hooks are simple Kubernetes manifest templates identified by an annotation whose value will determine when the hook should be rendered. These YAML files are bundled in the templates/ folder of a chart and are identified with helm.sh/hook(-*) annotations. In a Helm release, any manifest resource with hook annotation(s) can declare multiple stages where the hooks should be executed.

Helm Chart Hooks Use Cases

Helm chart hooks have many use cases in helping developers package complex applications. Some of the use cases include:

Types of Helm Chart Hooks

Helm chart hooks are categorized into the following types based on what stage of the chart life cycle they are triggered.

How Helm Chart Hooks Are Executed

When a Helm chart containing hooks is executed, components like pods or jobs pertaining to hooks are not directly applied in a Kubernetes environment, instead when a hook is executed, a new pod is created corresponding to the hook. If successfully run, they will be in Completed state. Any resources created by a Helm hook are un-managed Kubernetes objects. In other words, uninstalling a Helm chart will not remove the underlying resources created by hooks. A separate deletion policy needs to be defined in the form of annotation if those resources need to be deleted. Three different deletion policies are supported which will decide when to delete the resources:

If no hook deletion policy annotation is specified, the before-hook-creation behavior is applied by default.

Example of a Pre-Install Helm Chart Hook (Pod)

apiVersion: v1
kind: Pod
metadata:
  name: hook-preinstall
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  containers:
    - name: hook1-container
      image: busybox
      imagePullPolicy: IfNotPresent
      command: ['sh', '-c', 'echo The pre-install hook Pod is running  - hook-preinstall && sleep 15']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0

In the above example, there is an annotation with key “helm.sh/hook” and mentions a stage at which this should get executed. This hook will start a container, will sleep for 15 seconds and will be completed.

Example of a Post-Install Helm Chart Hook (Pod)

apiVersion: v1
kind: Pod
metadata:
  name: hook-postinstall
  annotations:
    "helm.sh/hook": "post-install"
spec:
  containers:
    - name: hook2-container
      image: busybox
      imagePullPolicy: IfNotPresent
      command: ['sh', '-c', 'echo post-install hook Pod is running - hook-postinstall && sleep 10']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0

Example of a Pre-Install Helm Chart Hook (Job)

apiVersion: batch/v1
kind: Job
metadata:
  name: job-hook-preinstall
  annotations:
    "helm.sh/hook": "pre-install"
spec:
  template:
    spec:
      containers:
      - name: pre-install
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'echo pre-install Job Pod is Running ; sleep 5']
      restartPolicy: OnFailure
      terminationGracePeriodSeconds: 0
  backoffLimit: 3
  completions: 1
  parallelism: 1

Using Rafay and Helm Charts

DevOps and Application teams can use Rafay to dramatically accelerate and streamline the deployment and ongoing operations for their Helm charts. Some of the core benefits provided by Rafay are described below. Visualize Helm Releases Rafay provides users with intuitive dashboards that automatically organize and display details of all Kubernetes resources associated with a Helm chart workload deployed to remote clusters. Users can also instantly view Helm release information associated with a deployed workload on remote clusters.

Deploy and Operate Helm Workloads to Remote Clusters behind Firewalls Operate with a great security posture by not requiring inbound access to your remote clusters. Use Rafay's Zero Trust KubeCTL Access (ZTKA) to dramatically simplify secure networking requirements between your CI/CD system and remote clusters in your datacenters. Use the Helm client with Rafay’s ZTKA to securely deploy Helm charts to remote clusters.

Drift Detection and Protection Control Loop Rafay can detect, report and block changes to Helm charts deployed on remote clusters. Organizations can ensure that deployed Helm workloads on remote clusters are not accidentally or maliciously tampered:

Helm charts and helm chart hooks are incredibly useful tools to help you manage the definition and deployment of Kubernetes applications. And Rafay makes it easy to manage it all. To learn more about Helm and Helm Chart Hooks, please visit: