Kubernetes Kustomize Build

Build a kustomization against resources you paste alongside it. This page has no filesystem, so a resources: entry naming a path is named and skipped rather than treated as empty, which would produce a plausible and completely wrong result.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Build. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A kustomization with no resources file

What kustomize build would do, and what it cannot resolve without the referenced files

resources:
  - deployment.yaml
namePrefix: prod-
commonLabels:
  env: prod

Patches and generators

The order transformations apply in, which is fixed and not the order you write them

resources:
  - base
images:
  - name: api
    newTag: 1.2.3
configMapGenerator:
  - name: settings
    literals:
      - LOG_LEVEL=debug

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Expecting patches to apply in the order written

    Kustomize has a fixed transformer order: generators, then transformers, then patches, then name and label transformers. Your file order does not change it.

    Instead:Read the ordering rather than inferring it from the file.

  2. Using commonLabels on an existing Deployment

    It adds labels to spec.selector too, which is immutable. The apply fails and the fix is to recreate the Deployment.

    Instead:Use labels with includeSelectors: false, or set the selector once and never change it.

  3. Referencing a resource file that is not committed

    kustomize build fails on a missing path, and in CI that surfaces as a build error rather than a missing file.

    Instead:Keep resources relative and committed.

Transformers run in kustomize's order, not the file's

Patches first, then name prefixes and suffixes, then labels and annotations, then images and replicas. A namePrefix therefore lands on a name a patch may already have changed, which is the commonest surprise in a layered overlay.

commonLabels reaches the selector, and a selector is immutable

kustomize adds commonLabels to spec.selector.matchLabels as well as to the metadata. On a Deployment that already exists, changing a commonLabel therefore changes an immutable field and the apply is rejected: the object has to be deleted and recreated. The newer `labels:` list with includeSelectors set to false exists for exactly this, and is what to use for anything that might change.

What is skipped, and why it is skipped loudly

Remote and path bases, components, and generators reading files all need a filesystem or a network, and this page has neither. Each is reported by name with the reason. The generator `literals:` form IS built, because it needs nothing else. The name suffix hash is marked rather than computed, because kustomize derives it with a FNV-1a variant over a canonical encoding and a different hash here would give a name that looks right and does not match.

What this cannot see

Anything on disk, which is most of a real overlay. Treat this as a way to understand what a kustomization does to resources you can see, not as a replacement for `kustomize build`. The output is re-serialised from the parsed tree, so comments and key order are not preserved.