Kustomize | DevOps QuickRef

Kustomize base/overlay patterns for environment-specific Kubernetes manifests without templating.

Kustomize composes plain Kubernetes YAML without a templating language — a base defines the common manifests, and overlays patch them per environment. kubectl has it built in via -k; no separate install required for basic use.

Directory Layout

k8s/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        └── kustomization.yaml

Base kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

Overlay — Patching Per Environment

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
 
namePrefix: prod-
 
replicas:
  - name: my-app
    count: 5
 
patches:
  - target:
      kind: Deployment
      name: my-app
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: 1Gi

Applying

kubectl apply -k overlays/production

Builds and applies an overlay directly — no separate kustomize binary needed for this.

kustomize build overlays/production

Renders the final manifests to stdout without applying anything — the fastest way to review exactly what an overlay produces.

kustomize build overlays/production | kubectl diff -f -

Shows what would change against the live cluster before applying.

ConfigMap & Secret Generators

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info
    files:
      - config.yaml
 
secretGenerator:
  - name: app-secret
    envs:
      - secrets.env

Generators add a content hash suffix

A generated ConfigMap/Secret gets a hash appended to its name (app-config-8f7d2b6c) derived from its content — Kustomize automatically updates every reference to it, so a config change correctly triggers a rolling pod restart instead of silently reusing stale mounted config.

Common Transformers

namePrefix: prod-
namespace: production
commonLabels:
  env: production
images:
  - name: my-app
    newTag: 1.4.2

Kustomize vs. Helm

Kustomize

Patches plain, valid YAML — no templating language to learn, and every base manifest is itself deployable as-is. Best when most of your config is genuinely shared and only a few fields vary per environment.

Helm

Templates YAML from a values file, and packages/versions the whole thing as a distributable chart with its own release lifecycle. Best when you're distributing an application for others to install with their own config, or need more dynamic logic than patching supports.

They compose

Many real setups use both — a Helm chart's rendered output run back through Kustomize overlays (helm template | kustomize), or ArgoCD/Flux natively support layering a Kustomize patch on top of a Helm-sourced application.