Introduction

kubectl kustomize only builds and prints the rendered manifests. It does not send anything to the cluster by itself. To actually deploy the generated resources, you must either pipe that output into kubectl apply -f - or use the built-in shortcut kubectl apply -k.

That distinction is the whole answer to the confusion. Rendering and applying are two separate steps unless you explicitly choose the command that combines them.

The Two Correct Apply Patterns

If your kustomization is in ./overlays/prod, these commands are the practical options:

kubectl kustomize ./overlays/prod | kubectl apply -f -

kubectl apply -k ./overlays/prod

The second form is usually cleaner for normal deployment. The first is useful when you want to inspect or post-process the rendered YAML in the middle of a shell pipeline.

What kubectl kustomize Actually Does

This command:

kubectl kustomize ./overlays/prod

reads the kustomization.yaml, resolves resources, patches, generators, and overlays, and writes the final YAML to standard output. That is all. It does not modify the cluster.

Think of it as "show me the final manifests," not "apply this configuration."

Use apply -k for the Normal Workflow

For ordinary cluster deployment, kubectl apply -k is usually the best choice:

kubectl apply -k ./overlays/prod

It keeps the intent clear: build the kustomization from that directory and apply it to the cluster.

That is generally preferable to storing rendered YAML files in your repository, because the kustomization stays the source of truth.

Useful Preview Commands

Before applying, it is often helpful to inspect or compare the rendered output:

kubectl kustomize ./overlays/prod
kubectl diff -k ./overlays/prod

A common workflow is:

1. kubectl kustomize to inspect the generated manifests
2. kubectl diff -k to compare them with the live cluster
3. kubectl apply -k to deploy

That gives you both visibility and a clean apply step.

Typical Directory Layout

Kustomize usually works with a base plus one or more overlays:

1base/
2  deployment.yaml
3  service.yaml
4  kustomization.yaml
5
6overlays/
7  prod/
8    kustomization.yaml

A simple overlay might look like this:

1resources:
2  - ../../base
3
4namePrefix: prod-
5
6images:
7  - name: my-app
8    newTag: "1.4.2"

Then you apply the overlay directory, not one of the individual YAML files:

kubectl apply -k ./overlays/prod

When the Piped Form Is Useful

The pipe form still has real value. For example, you may want to save the rendered output for review:

kubectl kustomize ./overlays/prod > rendered.yaml
kubectl apply -f rendered.yaml

Or pass it through another tool before applying. The important part is that the final step still has to be apply.

Common Pitfalls

The biggest mistake is assuming kubectl kustomize deploys automatically. It does not. It only renders.

Another common issue is pointing -k at the wrong directory. The target should be the directory containing the relevant kustomization.yaml, not a raw manifest file.

Developers also sometimes mix -f and -k conceptually. -f applies files or stdin, while -k tells kubectl to build a kustomization directory first.

Finally, if the cluster result looks wrong, inspect the rendered YAML with kubectl kustomize before blaming Kubernetes. The problem is often in the kustomization output rather than in apply itself.

Summary

• 'kubectl kustomize renders manifests but does not apply them.'
• Use kubectl apply -k <dir> for the normal build-and-deploy workflow.
• The equivalent piped form is kubectl kustomize <dir> | kubectl apply -f -.
• Use kubectl diff -k to preview changes before applying them.
• Point -k at the directory containing the kustomization.yaml you actually want to deploy.