Kustomize Explained
Template-free configuration customization for Kubernetes
Kustomize lets you customize Kubernetes YAML without templates.
Instead of injecting variables into Go templates (like Helm), you write
plain, valid YAML and declare
how to patch and overlay it
for different environments. It's built into kubectl since v1.14.
Three Core Concepts
Canonical Directory Structure
resources:
- deployment.yaml
- service.yaml
- configmap.yaml
resources: - ../../base namespace: dev patches: - path: replicas-patch.yaml
kubectl apply -k overlays/dev/ reads the overlay's kustomization.yaml, resolves the base, applies patches, and sends the merged YAML to the cluster. No intermediate files generated.
Two Ways to Patch
Kustomize supports two patching strategies. Both modify the base without touching the original files.
Write a partial resource that gets deep-merged into the base. Only specify the fields you want to change.
apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 2 template: spec: containers: - name: api image: myapp:latest
apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 5 template: spec: containers: - name: api resources: limits: memory: 512Mi
apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 5 # changed template: spec: containers: - name: api image: myapp:latest # kept resources: # added limits: memory: 512Mi
An array of operations (add, remove, replace) applied
to specific JSON paths. Use when strategic merge can't express your change.
- op: replace path: /spec/replicas value: 5 - op: add path: /metadata/labels/env value: prod - op: remove path: /spec/template/spec/containers/0/env/2
patches: - path: json-patch.yaml target: kind: Deployment name: api
- • Changing field values (replicas, image, etc.)
- • Adding new fields to existing objects
- • The patch is easy to read as YAML
- • Removing items from arrays
- • Inserting into specific array positions
- • Targeting resources by label/annotation
Generators & Transformers
Beyond patches, kustomization.yaml has built-in generators that create resources and transformers that modify all resources at once.
Generators
configMapGenerator: - name: app-config literals: - LOG_LEVEL=info - DB_HOST=postgres.svc files: - config.json
secretGenerator: - name: db-credentials literals: - username=admin - password=s3cret type: Opaque
app-config-h8f2k). This forces Deployments referencing the ConfigMap to roll out a new version automatically — no manual restart needed.
Transformers
namespacenamespace: production
namePrefix / nameSuffixnamePrefix: prod- nameSuffix: -v2
commonLabelslabels fieldcommonLabels: app: my-app env: prod
commonAnnotationscommonAnnotations: team: platform managed-by: kustomize
imagesimages: - name: myapp newTag: v2.1.0
replacementsvars)replacements: - source: ... targets: [...]
kubectl apply -k overlays/dev/
Build & apply in one step
kustomize build overlays/dev/
Preview rendered YAML (stdout)
kustomize build . | kubectl apply -f -
Pipe build output to kubectl
kustomize build . | kubectl diff -f -
Preview changes before applying
kubectl kustomize overlays/dev/
Same as kustomize build (built-in)
kustomize edit set image myapp:v2
Update image tag in kustomization.yaml
kustomize create
Create a new kustomization.yaml
kustomize edit add resource deploy.yaml
Add a resource to kustomization.yaml
kustomize edit set namespace prod
Set namespace transformer
kustomize edit fix
Migrate deprecated fields to latest API
kustomize build --enable-helm
Enable Helm chart inflation
kustomize build --load-restrictor none
Allow loading files outside root
Related Topics
Helm Charts
Chart structure, templating engine, release lifecycle, and everything you need to package Kubernetes applications.
GCP IAM
Identity & Access Management — principals, roles, hierarchy, service accounts, and policy evaluation in one mental model.
RabbitMQ
Producers, exchanges, queues, and consumers. Route messages reliably between services with animated flow diagrams.