Introduction

In Kubernetes, "what is active on the cluster" and "what Kustomize builds" are related but different views of the system. One describes the live state currently stored in the API server. The other describes the desired manifests rendered from your local configuration files.

Understanding that distinction is essential whenever you are debugging drift, reviewing changes, or trying to explain why the cluster does not match the YAML in Git.

Live State Versus Rendered State

The live cluster state is what Kubernetes is actually running right now. You inspect it with commands such as:

kubectl get deployment my-app -o yaml

That output can include:

• current spec values
• defaults added by Kubernetes
• status fields
• controller-managed metadata
• manual edits made directly on the cluster

Kustomize output is different. It is the manifest set produced from a base plus overlays before application:

kubectl kustomize overlays/prod

or:

kustomize build overlays/prod

That output is your desired configuration as rendered from files. It does not include runtime status and may not reflect drift or manual hotfixes already present in the cluster.

Why The Two Diverge

The two views drift apart whenever something changes outside the Kustomize source files or after the manifests are applied. Common reasons include:

• someone edited a resource directly with kubectl edit
• a controller mutated fields after creation
• Kubernetes defaulted values you never wrote explicitly
• the cluster is running an older rollout than the files now describe

That is why "Kustomize says X" does not guarantee "the cluster is currently running X."

The Practical Diff Workflow

If your real question is how the desired manifests compare to what is live, the most direct command is:

kubectl diff -k overlays/prod

This asks Kubernetes to compare the rendered Kustomize output with the live resources on the cluster. It is usually the fastest way to answer the operational question, because it highlights drift between desired and actual state.

You can also inspect the two sides separately:

kubectl get deployment my-app -o yaml
kubectl kustomize overlays/prod

Then compare fields such as image tags, environment variables, labels, or replica counts.

Kustomize Is Not A Runtime Source Of Truth

Kustomize is a manifest generation tool. It does not know whether pods are healthy, whether a rollout succeeded, or whether someone changed the object after deployment.

That leads to two different questions with two different sources of truth:

• "What should prod be running?" -> your Kustomize overlay or Git repo
• "What is prod actually running right now?" -> the live cluster objects

Both are important, but they answer different operational questions.

Common Pitfalls

The biggest mistake is treating Kustomize output as proof of the live state. It only shows what would be applied from the current configuration files.

Another pitfall is comparing raw source YAML directly to live YAML and being surprised by extra fields. Live objects contain status, generated metadata, and defaulted values that were never meant to appear in the source manifests.

A third issue is debugging the wrong layer. If a deployment is failing right now, the cluster is the immediate truth. If you are reviewing what should be deployed next, Kustomize is the better source.

Summary

• Live cluster state is what Kubernetes is actually storing and running now.
• Kustomize output is the desired manifest set rendered from your files.
• The two can diverge because of drift, defaults, or manual changes.
• 'kubectl diff -k is a practical way to compare desired and actual state.'
• Use the cluster for runtime truth and Kustomize for desired-configuration truth.