Kustomize vs Helm

This article compares two approaches for applying per-environment modifications to Kubernetes manifests: Kustomize and Helm. Both solve the same problem—managing environment-specific configuration—but they use different philosophies and tooling. Understanding their differences will help you pick the right tool for your team and CI/CD pipelines.

Helm overview

Helm is a Kubernetes package manager that uses Go templating to inject values into manifests. Beyond templating, Helm provides a packaging format (charts), release lifecycle management (install, upgrade, rollback), and a registry-centric distribution model similar to apt or yum. Key Helm concepts:

Chart: a packaged Kubernetes application.
Templates: manifest files with Go templating markers ({{ ... }}).
Values: user-supplied configuration stored in values.yaml and overridden via -f or --set.
Releases: deployed instances of a chart in a cluster.

Example: Helm Deployment template

This simple Deployment template demonstrates Go templating variables. The placeholders such as {{ .Values.replicaCount }} are substituted with concrete values from values.yaml when Helm renders the chart.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "nginx:{{ .Values.image.tag }}"

Example values.yaml:

name: nginx
replicaCount: 1
image:
  tag: "2.4.4"

When you install the chart, Helm renders the template and substitutes values so that replicas becomes 1 and the container image becomes nginx:2.4.4.

Chart layout with environment-specific values

A typical Helm chart layout that supports per-environment overrides might look like:

k8s/
├── Chart.yaml
├── values.yaml
├── environments/
│   ├── values.dev.yaml
│   ├── values.stg.yaml
│   └── values.prod.yaml
└── templates/
    ├── nginx-deployment.yaml
    ├── nginx-service.yaml
    ├── db-deployment.yaml
    └── db-service.yaml

templates/ contains Kubernetes manifests with Go templating.
values.yaml provides default values.
environments/ can contain environment-specific values files that override values.yaml.

Helm merges values files in the order specified (later files override earlier ones). Examples:

helm install my-release ./k8s -f k8s/environments/values.dev.yaml
# or when upgrading:
helm upgrade my-release ./k8s -f k8s/environments/values.stg.yaml

Helm templates support conditionals, loops, functions, and hooks to provide flexible, dynamic manifests, but be mindful that raw template files are not valid YAML until rendered.

A presentation slide titled "Kustomize vs Helm" listing bullet points about Helm — that it's a package manager, offers features like conditionals, loops, functions and hooks, and that Helm templates aren't valid YAML so complex templates become hard to read.

Helm templates contain Go templating markers and therefore are not plain YAML until rendered. Complex charts with many conditionals and variables can become difficult to read and reason about.