Kustomize

Kustomize solves a similar problem to Helm — the same base app needs slightly different settings per environment — with a deliberately different approach: no templating language at all, just patches over plain YAML. It ships built into kubectl (kubectl apply -k), no install required.

Bases and overlays

A base is an ordinary set of manifests plus a kustomization.yaml listing them as resources:. An overlay references that base and adds patches: — surgical edits like "bump replicas to 3" or "use this image tag instead" — without touching or duplicating the base files themselves. You might have base/, overlays/dev/, overlays/prod/, each overlay patching only what differs for that environment.

This is the opposite design choice from Helm's {{ .Values.x }} placeholders sprinkled through every file: Kustomize's base files are 100% valid, plain Kubernetes YAML you could kubectl apply directly with no tool at all. The overlay is where environment-specific differences live, expressed as patches, not as parameterized templates.

Patches, and how they can go quietly wrong

A patch targets a resource (by kind/name) and a field path to change. The failure mode here is different from Helm's "renders empty" — a patch with a field path that doesn't exactly match the real resource doesn't necessarily error. It can end up adding a new, wrong field alongside the real one, leaving the object looking patched when it isn't. kubectl kustomize <dir> renders the final YAML with zero cluster contact — same idea as helm template — and is how you catch this before kubectl apply does (or, as you'll see in this lesson's lab, before the API server's own schema validation does).

No templates means no values, and no release history

Because there's no templating language, there's also no values.yaml equivalent and no revision/rollback concept — Kustomize doesn't track "releases" the way Helm does. Fixing a bad overlay is just editing the patch and re-running kubectl apply -k, same as any other manifest change.

Helm vs. Kustomize: when to reach for which

Helm fits best when you're distributing something to other people (a chart with real configurability, a version, a repo to publish to) — this cluster's own Ingress controller, Traefik, is already running as a Helm release for exactly that reason; most third-party addons you'll install from here on ship as charts too. Kustomize fits best for your own app's environment differences, where you'd rather keep every file as plain, readable YAML and express "what's different in prod" as an explicit, reviewable patch instead of a templating mini-language.