Kustomize Promote and Helm Charts

Last Friday we released v0.2.0 of kustomize-promote.

We have discussed kustomize-promote in a “Sudo Friday” video (in Dutch) before. If you want more information on what the tool does, and why YOU wil want to use it, check out that video.

This release has a bugfix for an issue where trying to promote images between two overlays where neither overlay has an image defined resulted in a merge error, but also brings a new feature: Promoting the version of a HelmChart being used between two overlays.

HelmCharts? In My Kustomize???

As readers may (or may not) know Kustomize can include Helm Charts in a Kustomization. It does not apply these charts directly to the cluster, but instead fetches the chart, templates it with the “values” you pass it, and then inserts the resulting manifests into the Kustomization as if they were resources defined in a resources: block.

This allows intrepid professionals to mutate the resulting manifests in any way they desire, even if the upstream Helm Chart does not have the capabilities to do so using its normal templating.

Example Helm Chart in a Kustomization

An example of this can be seen in the following code snippet:

 1apiVersion: kustomize.config.k8s.io/v1beta1
 2kind: Kustomization
 3
 4helmCharts:
 5- name: kyverno
 6  releaseName: kyverno
 7  repo: https://kyverno.github.io/kyverno
 8  version: 3.3.4
 9  valuesInline:
10    namespaceOverride: openshift-kyverno
11    securityContext: null
12    migration:
13      securityContext: null
14    webhooksCleanup:
15      securityContext: null
16    policyReportsCleanup:
17      securityContext: null

In this example we can see version 3.3.4 of the kyverno chart being expanded with a number of “values”. These values can also be set from YAML files if you so desire.

Promoting Helm Charts between Overlays

When using Helm from within Kustomize there’s no “easy” commands like helm upgrade. You get the version defined in your Kustomization, and you will like it. So to start an upgrade cycle an administrator or developer will first need to update the desired version of the Chart at the bottom of the tree.

After that is done the kustomize-promote command (available here) can be used to update the helmcharts[*].version field between overlays:

1kustomize-promote overlays/dev overlays/test

A version field will only be upgrade in the target overlay if:

  • Both source and target have a helmCharts entry with the same name
  • Both source and target entries match on the repo field (or the absence thereof)

What about my Bases?

You might ask why we do not put the helmCharts: block in the base for our Kustomizations. The answer is fairly simple: Kustomize expands the contents of the helmCharts before manifests are forwarded to the next layer, so updating a Chart would mean updating it immediately for all derived overlays, something we typically do NOT like. It’s the same reason we use ?ref=<branch|commit|tag> in our resources: blocks, we want to be able to move overlays/environments to a newer version of our bases in a controlled manner.

If you think of helmCharts: in Kustomize as just a simpler way of pulling the manifests generated by a helm template into your Kustomize resources it is almost the same as using versioned resources: entries.

Give It A Try!

If you want to try all the goodness of kustomize-promote you can download it from the project site. It’s available there from the “releases” page.

Also make sure you have watched the video describing the first release.

Gerelateerde posts