A short guide to Kubernetes YAML Validator
Find the failure before it reaches production.
Check Kubernetes manifest structure and common selector, port, and probe mistakes. Here is the practical way to prepare the input, read the output, and decide what to check next.
01
When to reach for it
Checks the supplied manifest for required apiVersion, kind, metadata.name, containers, and common selector or label mismatches. It is most useful when you are dealing with manifest rejected or service has no endpoints. Start with the smallest example that still shows the behavior.
- Look for manifest rejected, service has no endpoints, pod not ready.
- Reduce the example until one observation can change the result.
02
How to prepare the input
Paste a focused example in Kubernetes YAML. Leave out unrelated noise so the result stays easy to verify.
- Use the accepted format: Kubernetes YAML.
- Keep the facts that make the behavior reproducible.
- Do not treat missing context as a reason to invent an answer.
Example input
Safe sample
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: worker
spec:
containers:
- name: api
image: example/api:1
ports:
- containerPort: 8080Run this first to see the shape of the result. Then change one meaningful fact and confirm that the output changes with it.
03
How to read the result
Reports the structural and selector issues found in the supplied manifest. Read the finding beside the evidence that produced it. The result narrows the next check; it does not claim to have changed your system.
- Separate the observed fact from the suggested next check.
- Prefer the smallest reversible experiment that can confirm or reject the finding.
- Save the output when it belongs in an incident note, review, or handoff.
04
Know the boundary
A valid document can still describe the wrong contract, and an unsupported rule is not the same as a passing validation.