Kustomize: Environments Without Templates

In one line

Kustomize customises plain YAML with overlays and patches instead of templates: one base, small per-environment differences, built into kubectl, and native to Argo CD and Flux.

0/5 · 0%

Think of it like this

A standard house plan (base) and small change orders per plot (overlays): 'this one gets a bigger garage', 'this one a different colour'. Nobody redraws the whole plan for each house.

Key ideas

01
A kustomization.yaml lists resources (plain manifests or other kustomizations) and transformations: namespace, namePrefix/nameSuffix, labels, images (change image names/tags), replicas, configMapGenerator/secretGenerator (generate ConfigMaps with a content hash suffix so pods roll when config changes), and patches (strategic merge or JSON 6902).
02
The standard layout: base/ with the full manifests, overlays/dev, overlays/prod with only the differences. kubectl kustomize overlays/prod renders; kubectl apply -k overlays/prod applies. COMPONENTS (kind: Component) package optional features (monitoring sidecar, HPA) that several overlays can include.
03
Kustomize vs Helm (Phase 7): Kustomize has no templating language and keeps YAML valid and diffable, ideal for your own apps with small environment differences. Helm is better for distributing configurable packages to others. They combine: Kustomize can inflate Helm charts, and GitOps tools render both (GitOps course, environments and overlays).

Code & diagrams

overlays/prod/kustomization.yamlyaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: shoplite-prod
resources: [../../base]
images:
  - name: ghcr.io/shoplite/api
    newTag: sha-3f2a1c9
replicas:
  - name: api
    count: 4
configMapGenerator:
  - name: api-config
    literals: [LOG_LEVEL=info, FEATURE_WISHLIST=true]
patches:
  - target: { kind: Deployment, name: api }
    patch: |
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/cpu
        value: 500m

render and applybash

kubectl kustomize overlays/prod | less          # review the final YAML
kubectl diff -k overlays/prod                    # what would change in the cluster
kubectl apply -k overlays/prod

Explain it without notes

Why does configMapGenerator add a hash suffix to the ConfigMap name?

Practice

Create a staging overlay that reuses prod's settings but with 2 replicas and a different hostname.

Trade-offs

↔
Kustomize keeps plain YAML and simple diffs, but complex conditional logic is awkward; Helm handles configurable packaging better at the cost of templating complexity.

Done when you can

I can structure base/overlays and use images, replicas, generators, and patches
I can explain when to use Kustomize vs Helm