Courses Infrastructure as Code & automationIntermediate · Kubernetes IaC

Kustomize: template-free overlays

Patch manifests per environment.

Intermediate12 min · lesson 16 of 23

Kustomize is the other major way to manage Kubernetes manifests, and it takes the opposite approach to Helm: instead of templating, it uses overlays. You keep a plain, valid set of "base" manifests, then define small per-environment patches that modify them — change the replica count for prod, add a label, swap an image tag. There are no template placeholders; the base is real YAML you could apply directly, and each environment is that base plus a declared set of changes. It is built into kubectl (kubectl apply -k), so there is nothing extra to install.

KUSTOMIZE: BASE + OVERLAY

base/ (common, valid YAML)

deployment.yaml

plain manifest, 1 replica

service.yaml

kustomization.yaml

lists the base resources

overlays/prod/

references ../../base

replicas-patch

override 1 -> 5

namePrefix + image tag

prod- prefix, newTag 1.4.2

result

kubectl apply -k overlays/prod

base plus prod patches, rendered

No templates — the base is real YAML; each overlay is that base plus an explicit set of patches.

directory layout

base/
  deployment.yaml        # plain, valid manifests (1 replica)
  service.yaml
  kustomization.yaml     # lists the base resources
overlays/
  prod/
    kustomization.yaml   # references base + patches
    replicas-patch.yaml  # patch: set replicas to 5 for prod
# apply prod:  kubectl apply -k overlays/prod

Base + overlay

The model is base plus overlay. The base is the common configuration; each overlay (dev, staging, prod) references the base and layers on patches — strategic-merge patches that change specific fields, plus conveniences like setting a name prefix, common labels, or image tags for the whole environment. Because the base is ordinary YAML and the patches are explicit, you can see exactly what differs per environment without mentally rendering a template. Many find this more transparent than Helm’s templating for in-house apps.

overlays/prod/kustomization.yaml

resources:
  - ../../base                  # start from the base
patches:
  - path: replicas-patch.yaml   # override specific fields for prod
images:
  - name: myapp
    newTag: "1.4.2"             # set the image tag for this environment
namePrefix: prod-              # prefix all resource names

Helm vs Kustomize

They solve the same problem differently, and teams debate which. Helm is a full package manager — templating, releases, rollbacks, a huge ecosystem of installable charts — ideal for packaging apps to distribute and for installing third-party software. Kustomize is simpler and template-free — no placeholders, valid YAML throughout, built into kubectl — often preferred for your own manifests where you want transparency over packaging features. Many teams use both: Helm to install third-party charts, Kustomize to manage their own apps. Neither is wrong; pick by whether you value packaging power (Helm) or template-free clarity (Kustomize).

Both are just producing YAML — keep it reviewable

Whether you template with Helm or overlay with Kustomize, the output is Kubernetes manifests applied to a cluster, and the same security defaults apply: render and review what actually gets deployed (helm template / kubectl kustomize print the final YAML), pin versions of anything external, and enforce your Pod Security and resource-limit standards in the output. The tooling makes manifests easier to manage; it does not make them secure. The final rendered YAML is what runs, so make sure you can see it and that it meets your policy — which the advanced policy-and-scanning lessons automate.

Helm: the Kubernetes package…Policy-as-code: OPA, Conftest &…