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
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
What kustomize build would do, and what it cannot resolve without the referenced files
resources: - deployment.yaml namePrefix: prod- commonLabels: env: prod
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=debugThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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.
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.