kubectl kustomize: Usage, Options & Common CI Errors
Render a kustomize overlay to plain YAML you can inspect.
kubectl kustomize builds a kustomization directory into final manifests and prints them, without touching the cluster. It is the render half of the -k workflow, ideal for validating an overlay in CI.
What it does
kubectl kustomize DIR processes the kustomization.yaml - applying patches, name prefixes, common labels, image overrides, and merging bases - and emits the resulting YAML to stdout. kubectl apply -k DIR does the same build and then applies it. Rendering first lets you diff, lint, or pipe the output before any cluster change.
Common usage
kubectl kustomize overlays/prod
kubectl kustomize overlays/prod | kubectl apply -f -
kubectl apply -k overlays/prod # build + apply in one step
kubectl kustomize overlays/prod | kubectl diff -f -Common errors in CI
"error: unable to find one of \"kustomization.yaml\" ... in directory" means you pointed at the wrong path or the file is named non-canonically. "field is unknown" / "unknown field" in kustomization.yaml usually means a syntax change between kustomize versions - the kustomize bundled in kubectl can lag standalone kustomize, so a feature that works locally may fail in CI; pin matching versions. A patch that targets a resource not present in the base fails the build; ensure the base actually contains the object your overlay patches.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes