When I first started using Helm, I assumed that the sky was the limit in terms of what you could configure in a Helm chart. Need to add volumes? I believed you could always change that. Labels? “No problem,” I thought.

Being much more experienced with Helm today, I know that my assumption was not correct because there was no way to change parts of a Helm chart that were not exposed by values…until now. Helm 3.1 introduced the ability to use post-renderers, which allow you to patch any resource that a Helm chart manages before they are sent off to the API server.

There are a few different types of post-renderers, but in this post, we’ll take a look at the Kustomize post-renderer and how you can use it to make changes to your chart’s resources, even if the chart doesn’t expose any values that allow you to do so.

To understand the Kustomize post-renderer, you first need to know how the Kustomize CLI works. Let’s quickly explore this tool before diving into the post-renderer functionality.

What is Kustomize?

At a high level, Kustomize is used to patch Kubernetes resources. It is used to make small changes to already-defined resources to prevent you from rewriting large amounts of boilerplate.

Imagine, for example, you wanted to add an environment variable to your deployment when deploying to a dev environment but wanted to add a different environment variable when deploying to test. Rather than rewrite the same deployment resource twice, you can simply write two small kustomize.yaml files.

The dev kustomize.yaml file would look like this:

bases:
  - ../../base
patches:
  - dev_env.yaml

Bases refers to the deployment file that you are patching. Patches refers to the file that contains your desired patch. So, the “dev_env.yaml” patch could look like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  template:
    spec:
      containers:
        - name: nginx
          env:
            name: ENVIRONMENT
            value: dev

When you run kustomize against this kustomization.yaml file, it will merge this environment variable into the base deployment. Below is the command used to perform this merge:

kustomize build $PATH_TO_KUSTOMIZATION_FILE

You could follow the same idea for the test kustomize.yaml file and additional environments where you plan to deploy.

With a brief intro to Kustomize out of the way, let’s see how it can help make changes to any resource we want in a Helm chart.

#cloud #kubernetes #devops #containers #helm