kubectl kustomize: Command Reference for CI/CD
Render a kustomize overlay to plain YAML for review or apply.
kubectl kustomize builds a kustomize directory and prints the rendered manifests to stdout, without touching the cluster. It is the render half; apply -k is render-and-apply. This reference covers both and a per-environment CI flow.
Common flags and usage
- kustomize <dir>: render an overlay to stdout (no cluster access)
- apply -k <dir>: render and apply in one step
- --enable-helm: allow the helmCharts kustomize feature
- Pipe rendered output into apply, diff, or a policy check
- Overlays under overlays/<env> layer onto a shared base
Example
# Render, preview the diff, then apply the prod overlay
kubectl kustomize overlays/prod > /tmp/rendered.yaml
kubectl diff -f /tmp/rendered.yaml || true
kubectl apply -f /tmp/rendered.yaml --server-sideIn CI
Rendering to stdout first lets you run policy or lint checks on the exact YAML before it reaches the cluster, and feed it to kubectl diff for a review-friendly preview. apply -k is the shorthand when you do not need the intermediate artifact.
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 nodesKey takeaways
- kustomize renders to stdout; apply -k renders and applies.
- Rendering first lets you lint, diff, and policy-check the exact YAML.
- Per-environment overlays layer onto one shared base.