When to use Kustomize and Helm

This week, I’m going to talk about the two Kubernetes deployment tools, Kustomize and Helm.

I recommend companies use Helm to install third-party packages to their Kubernetes clusters and Kustomize for their internal services. This mix of tooling provides the best trade-offs for developer experience in most cases.

Most third-party packages will have a Helm chart with a values.yaml file that allows you to tweak everything you would ever want.

Using Kustomize for your internal services lets you avoid a lot of unnecessary overhead. You won’t need to create and maintain a Helm chart. There also wouldn’t be a need to create CI/CD pipelines to build and publish the charts. Also, Kustomize is simpler to use and reason about. Helm charts tend to put a lot of complexity in their templates, which means changes are more difficult to make.

Take a look at this excerpt from a Minecraft server Helm chart:

{{- if ne (printf "%s" .Values.minecraftServer.eula) "FALSE" }}
apiVersion: apps/v1
kind: {{ ternary "StatefulSet" "Deployment" .Values.workloadAsStatefulSet }}
metadata:
  name: {{ template "minecraft.fullname" . }}
  {{- if .Values.deploymentAnnotations }}
  annotations:
    {{- range $key, $value := .Values.deploymentAnnotations }}
    {{ $key }}: {{ $value | quote }}
    {{- end }}
  {{- end }}

This complexity can make sense for a third-party Helm chart but not for your in-house services.

Kustomize’s strength, simplicity, is Helm’s weakness, and Helm’s strength, templating, is Kustomize’s weakness.

Tomorrow, we will explore how to use both tools to get the best of both worlds.