Two objects with the same name
A duplicate that apply will silently resolve to whichever came last
apiVersion: v1 kind: Service metadata: name: api --- apiVersion: v1 kind: Service metadata: name: api
Paste a helm template render, a kustomize build, or any bundle with separators in it. You get one file per object, named in apply order, with the original text preserved and anything defined twice called out.
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 Split. 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.
A duplicate that apply will silently resolve to whichever came last
apiVersion: v1 kind: Service metadata: name: api --- apiVersion: v1 kind: Service metadata: name: api
One file split into the files kubectl apply -f would treat separately
apiVersion: v1 kind: Service metadata: name: api --- apiVersion: apps/v1 kind: Deployment metadata: name: api
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
kubectl apply processes documents in order and the last one wins, silently.
Instead:Split and check for duplicates before applying.
A --- inside a block scalar is content, not a separator, and a naive splitter breaks the document.
Instead:Split with a YAML parser, not a string split.
kubectl does not sort by dependency. A Deployment referencing a ConfigMap defined later in the same file still applies first.
Instead:Apply in dependency order, or rely on the controller retrying.
Splitting is the easy half. The rest is what a generated bundle hides from you, and all of it is readable from the file itself.
Every other splitter parses the YAML and dumps it out again, which deletes every comment, expands every anchor and rewrites the quoting. Here each document is the literal bytes between its separators. The parser still runs, but only to read each object's identity and to check that its idea of how many documents there are matches the split.
Same kind, same namespace, same name, twice in one bundle. kubectl applies them in order and the last one wins, with no warning and nothing in the diff. Editing the first copy then appears to do nothing at all, which is a long afternoon. Reported as critical, with the line numbers and which one currently takes effect.
kubectl apply -f on a single file processes documents top to bottom and does not sort them. A Deployment written above the Namespace it lives in works on every cluster where someone already created that namespace, and fails on the first clean install. Files come out numbered in dependency order.
kubectl get -o yaml wraps everything in a List, which is one document containing many objects; it gets unwrapped. A CRD in the same bundle as a resource of that kind cannot apply in one pass and says so. Helm conditionals that rendered empty leave documents with no kind, and those are flagged rather than written to a file.
A multi-document manifest is the normal output of helm template, kustomize build and kubectl get. Splitting one is easy; the reason to do it carefully is that the separator carries ordering and identity information that nothing else in the file records.
Three hyphens at the start of a line begins a new document. It has to be at column zero, and no scalar in block context can have a continuation line at column zero, so nothing inside a value can be mistaken for one. That is why a certificate chain in a ConfigMap splits correctly here and breaks a sed one-liner.
data:
chain: |
-----BEGIN CERTIFICATE----- <- indented, so it is
AAAA content, not a
-----END CERTIFICATE----- separator
--- <- column zero, so it is Within one file, documents are applied in the order written. Across a directory, kubectl reads the files alphabetically. That is the entire ordering guarantee you get, and it is why generated bundles are numbered. There is no dependency resolution anywhere in kubectl apply.
01-namespace-prod.yaml created first
02-serviceaccount-api.yaml
03-configmap-api.yaml
10-deployment-api.yaml by which point everything
it references exists
without the leading zero, 10- sorts before 2- Two documents defining the same object is a valid file. kubectl sends both, in order, and the object ends up as whatever the second one said. There is no warning, and kubectl diff shows the net result, so the redundant copy is invisible in review as well as at apply time.
kubectl apply -f bundle.yaml
configmap/app configured
configmap/app configured <- the same object, twice
the second wins, and nothing says so A CustomResourceDefinition and a custom resource of that kind cannot be applied together. The API server has to register the new endpoint before it can validate a resource against it, and within one apply it has not done that yet. The error names the kind, so it reads like a typo rather than a timing problem.
kubectl apply -f bundle.yaml
error: unable to recognize "bundle.yaml": no matches
for kind "Certificate" in version "cert-manager.io/v1"
kubectl apply -f 01-crd.yaml
kubectl wait --for condition=established --timeout=60s \
crd/certificates.cert-manager.io
kubectl apply -f .