
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.