What Are Kustomize Overlays?
Learn how Kustomize overlays layer environment-specific patches on a shared base — structure, patch types, and a real YAML example.
Expected Interview Answer
A Kustomize overlay is a directory containing its own `kustomization.yaml` that references a shared `base` set of manifests and layers environment-specific patches — like replica counts, resource limits, or image tags — on top, without duplicating or templating the base YAML.
The typical layout is `base/` holding the canonical, environment-agnostic manifests (Deployment, Service, ConfigMap) plus a `kustomization.yaml` listing those resources, and sibling `overlays/dev`, `overlays/staging`, `overlays/prod` directories each with their own `kustomization.yaml` that sets `resources: [../../base]` and then declares `patches` (strategic-merge or JSON6902) for that environment’s differences. Running `kustomize build overlays/prod` or `kubectl apply -k overlays/prod` composes base plus patches into the final manifest set, so the prod-only replica count or the staging-only environment variable is expressed as a small, readable diff rather than a full copy of the manifests. This keeps the base as a single source of truth: a fix to the container port or a shared label only needs to change in one place and every overlay picks it up automatically. Overlays can also add `namePrefix`, `namespace`, `commonLabels`, or `images` transformers to rewrite the base consistently per environment.
- Single base manifest, no duplication across environments
- Environment differences show up as small, reviewable diffs
- No templating language — every file stays valid, real YAML
- Composable transformers (namePrefix, commonLabels, images) apply per overlay
AI Mentor Explanation
A Kustomize base is like a standard training program the academy writes once for all age groups, and each overlay is a specific age group’s coach adding a few real tweaks — shorter boundary ropes for under-14s, a heavier ball for under-19s — directly onto a copy of that same program. The base program never gets copy-pasted and rewritten for every group; each overlay just references it and layers its own real adjustments. If the academy fixes a drill in the base program, every age group’s overlay picks up the fix automatically next session. This is exactly how a prod overlay adds more replicas on top of the same base Deployment used by dev.
Step-by-Step Explanation
Step 1
Create the base
Write plain, valid manifests plus a base/kustomization.yaml listing them as resources.
Step 2
Create an overlay directory
e.g. overlays/prod/kustomization.yaml with resources: [../../base].
Step 3
Add patches
Declare strategic-merge or JSON6902 patches, plus transformers like namePrefix, commonLabels, or images.
Step 4
Build and apply
kustomize build overlays/prod (or kubectl apply -k overlays/prod) composes base + patches into final manifests.
What Interviewer Expects
- Clear mental model of base + overlay directory structure
- Knowledge of strategic-merge vs JSON6902 patch types
- Understanding that overlays reference, never copy, the base
- Awareness of transformers like namePrefix, commonLabels, and images
Common Mistakes
- Duplicating the full manifest into each overlay instead of patching
- Confusing overlays with Helm values files
- Forgetting the overlay kustomization.yaml must list the base as a resource
- Not knowing kubectl apply -k builds and applies overlays directly
Best Answer (HR Friendly)
“An overlay is a small folder of patches that sits on top of a shared base set of Kubernetes files. Instead of copying and maintaining the full YAML for each environment, we keep one base and let dev, staging, and prod each apply just their own small differences — like replica count or resource limits. That way a fix to the shared base automatically applies everywhere, and reviewing an environment change is just reviewing a tiny diff.”
Code Example
# overlays/staging/kustomization.yaml
resources:
- ../../base
namePrefix: staging-
commonLabels:
environment: staging
images:
- name: myapp
newTag: staging-latest
patches:
- target:
kind: Deployment
name: myapp
patch: |-
- op: replace
path: /spec/replicas
value: 2
Follow-up Questions
- What is the difference between a strategic-merge patch and a JSON6902 patch?
- How would you share a ConfigMap generator across multiple overlays?
- How does kustomize build differ from kubectl apply -k?
- How would you validate an overlay before applying it to production?
MCQ Practice
1. What does an overlay reference in its kustomization.yaml?
An overlay lists the base directory under resources and layers its own patches on top, without duplicating the base.
2. Which command composes and applies a Kustomize overlay directly?
kubectl has native Kustomize support via the -k flag, which builds and applies the overlay in one step.
3. Why are overlays preferred over duplicating full manifests per environment?
Overlays express only the delta per environment, so a base fix propagates everywhere and diffs stay small and reviewable.
Flash Cards
What does an overlay contain? — A kustomization.yaml referencing a base plus environment-specific patches.
Two patch types in Kustomize? — Strategic-merge patches and JSON6902 patches.
Command to apply an overlay directly? — kubectl apply -k <overlay-dir>.
Main benefit of overlays? — One shared base, small readable per-environment diffs, no duplication.