Build & apply

kustomize build / kubectl -k.

Intermediate10 min · lesson 4 of 12

Kustomize has two ways to run. kustomize build <dir> renders the final manifests to stdout without touching the cluster — your dry run and review step. kubectl apply -k <dir> does build-and-apply in one command (Kustomize is embedded in kubectl). The habit to build first: render, read the output, then apply, because the assembled result can differ from what the small overlay files suggest.

terminal

$ kustomize build overlays/prod            # render only — review this
$ kustomize build overlays/prod | kubectl apply -f -   # explicit two-step
$ kubectl apply -k overlays/prod           # build + apply in one (kubectl built-in)
$ kubectl diff -k overlays/prod            # what would change vs the live cluster

Standalone vs kubectl

The kustomize binary and the copy embedded in kubectl can be different versions, and newer Kustomize features may not exist in an older kubectl. For anything beyond basics, install the standalone kustomize and pin its version in CI, then pipe its output to kubectl apply -f - rather than relying on kubectl -k. This keeps rendering reproducible and unlocks the current feature set. kubectl diff -k is invaluable for previewing changes against the running cluster.

The embedded kustomize lags the standalone

kubectl’s built-in Kustomize is often several versions behind the standalone release, so a kustomization that builds fine with kustomize can fail or behave differently under kubectl -k. For CI and anything non-trivial, use the pinned standalone binary and pipe to kubectl apply -f -; reserve kubectl -k for quick, basic applies where the version gap does not matter.

ConfigMap & Secret generatorsBases & overlays