Free lesson · CKAD Prep Program · Module 3: Application deployment
Differentiate Environments with Kustomize
Staging and production differ in a dozen small ways that must never drift into copy-paste. Kustomize keeps one base plus small per-environment overlays, built into kubectl itself.
11 min reading
Objectives
- Explain base plus overlays without copying manifests per environment
- Patch names, replicas and images per environment from one base
- Inject config with ConfigMap generators instead of hand-written files
- Build and diff an overlay before applying it anywhere
Why this matters
Three copied manifest trees rot at different speeds: the staging fix that never reaches production, the production secret that leaks into the staging repo. Overlays express environments as patches on one base, so the common shape has exactly one author and each environment declares only its differences.
Concepts
A base holds the shared manifests plus a kustomization.yaml listing resources. An overlay references the base and adds patches: name prefixes or suffixes per environment, replica counts, image tags, strategic-merge or JSON patches for surgical edits. kubectl apply -k <overlay-dir> builds then applies; kubectl kustomize <overlay-dir> (or kustomize build) renders the final manifests for reading and diffing without touching the cluster.
ConfigMap and Secret generators deserve special attention: instead of hand-writing data files, the overlay generates them from literal values or env files, with content-hash suffixes that roll dependents automatically when data changes. Common labels and annotations across an overlay keep selectors and ownership consistent.
Worked example
One deployment base, staging with two replicas plus debug label, production with five:
base/
deployment.yaml # replicas: 1, image: shop:3.2
kustomization.yaml # resources: [deployment.yaml]
overlays/staging/kustomization.yaml:
resources: [../../base]
namePrefix: staging-
replicas: [{ name: shop, count: 2 }]
commonLabels: { env: staging }
overlays/prod/kustomization.yaml:
resources: [../../base]
namePrefix: prod-
replicas: [{ name: shop, count: 5 }]
commonLabels: { env: prod }kubectl kustomize overlays/staging shows the built staging manifests for inspection; kubectl diff -k overlays/staging previews against the cluster; kubectl apply -k overlays/prod ships production. Same base, two honest differences, zero copies.
Exam notes
Paths in kustomization.yaml are relative to the file, not your shell: run from anywhere but write paths from the kustomization. Name prefixes rename everything including selectors consistently, which is why cross-references keep working. And always build or diff before apply: the overlay you imagined and the manifests generated are two different things until rendered.
Quick check
A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Given a fictional base deployment, write staging and prod overlays that differ in replica count, image tag and one label. Show the build output excerpt that proves each difference, then state which command you would run to preview prod against the live cluster.
Pass criteria
Two overlays with all three differences each; build excerpt shows the differing fields; preview command is diff -k with the correct overlay path.