Kubernetes YAML Validator
Inspect one or more Kubernetes manifests for object identity, workload templates, containers, selectors, labels, environment values, common API versions, and other mistakes worth catching before cluster-aware validation.
Multi-document YAML separated with --- and Kubernetes List objects are supported.
0 lines
Manifest Findings
Findings are grouped per object so one valid resource does not hide a broken resource later in the same YAML stream.
Document-by-document Kubernetes findings will appear here.
No cluster is contacted
YAML parsing stays in your browser. The manifest is not sent to a validation service or Kubernetes cluster. Installed CRDs, admission policies, namespace rules, server-side defaults, feature gates, and the target API-server version therefore remain outside the local result. Site-wide analytics or advertising scripts, if enabled, are separate from this inspection.
“The YAML Is Valid” Is Only the Beginning
Kubernetes manifests pass through several layers of interpretation. First the YAML must parse. Then the document has to describe a recognizable Kubernetes object. The resource schema must accept its fields and value types. Admission rules can modify or reject it. Finally, controllers and workloads still have to behave correctly in the cluster.
A generic YAML parse covers only the first layer. Local Kubernetes-aware checks can catch relationships such as selectors, Pod templates, volumes, mounts, env sources, and common API versions, but the target API server remains authoritative for its installed schemas and policy.
Read a Deployment as a Chain of Relationships
kind: Deployment
spec:
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:alpineThe selector and Pod-template labels are related: the Deployment needs to recognize the Pods it manages. The template then needs a Pod spec, and the Pod spec needs usable container definitions. A typo in any one of those places can make a manifest structurally wrong even though every colon and indentation level is valid YAML. Kubernetes defines label-key/value syntax and selector semantics in its labels and selectors documentation.
apiVersion and kind Tell Kubernetes Which Schema to Use
A Kubernetes object normally identifies itself with apiVersion and kind. A Deployment using apps/v1 and a CronJob using batch/v1 are interpreted through different API schemas. Custom resources add schemas that only exist when their CRDs are installed in the target cluster.
Only a focused set of built-in workload relationships is evaluated locally. Unknown kinds are not automatically errors; they may be valid custom resources whose schemas exist only through CRDs in the target cluster.
YAML Types Can Quietly Produce the Wrong Kubernetes Value
Some Kubernetes fields are strings even when their contents look numeric or boolean. An environment variable written as value: 123 can become a YAML number, while the Kubernetes env value field expects text. Writing value: "123" makes the intended type explicit.
The same issue appears in labels, annotations, ConfigMap data, and Secret stringData, where accidental YAML booleans or numbers can cause validation failures. Those high-value type mismatches are reported while the original YAML remains untouched.
Container Names, Volumes, and Mounts Form Another Local Graph
Container names must be unique within a Pod, and a volumeMount refers to a volume by name. If the mount says name: app-data while the Pod defines name: data, the relationship is broken. These checks stay local to each Pod template so similarly named volumes in another resource do not accidentally satisfy the reference.
Environment Sources and Secret Data Have Their Own Rules
Current Kubernetes allows environment-variable names to contain printable ASCII characters except =. An enventry can hold a literal string or one valueFrom source;envFrom selects a ConfigMap or Secret source. Ordering also matters when values reference earlier variables. The Kubernetes environment-variable guide describes these runtime rules.
Secret data values are standard base64 strings, whilestringData accepts plain strings and overwrites a matchingdata key when written. Base64 is encoding, not encryption. Kubernetes' own Secret guidance recommends treating manifests containing credentials as sensitive.
Structural Validity and Workload Safety Are Different Questions
Kubernetes intentionally supports powerful features such as privileged containers, host namespaces, and hostPath volumes. They can be necessary for node agents or infrastructure workloads, but they also reduce isolation. A few obvious cases are marked for review instead of being declared invalid.
A full security review also needs RBAC, Pod Security admission, image provenance, capabilities, seccomp/AppArmor, network policy, secret handling, service accounts, supply-chain controls, and the policies of the target cluster.
Jobs and Long-Running Controllers Do Not Share Every Pod Rule
Deployments, StatefulSets, DaemonSets, and ReplicaSets manage continuously running Pods and use restartPolicy Always. Jobs and CronJobs are completion-oriented workloads, where Pod templates use OnFailure or Never instead. The nested structure also differs: CronJob contains a Job template, which then contains a Pod template.
Following those nesting relationships keeps a missing CronJob schedule or nested Pod template close to the path that needs fixing.
Multi-Document Files and List Objects Need Per-Object Results
A single YAML file can contain several resources separated by ---. Kubernetes List objects can also wrap several items. A single “valid” badge for the whole file is not very useful when object one is fine and object four has the problem.
Findings stay attached to each document, and List items are expanded for inspection while retaining their source location in the result path.
Render Templates Before Validating the Manifest They Produce
Helm, Jinja-style systems, CI templates, and other generators can contain placeholders that are not the final Kubernetes manifest. Validating template source as though it were already rendered YAML can create misleading parser errors—or worse, validate a shape that changes after rendering.
When template markers are detected, the result records that fact. For production checks, render the same values and chart/template inputs used by the deployment pipeline, then validate the rendered objects.
The API Server Knows Things a Browser Cannot Know
Kubernetes server-side field validation uses the schemas available to the actual API server and can detect unknown or duplicate fields. Admission webhooks and policies can add organization-specific requirements after ordinary schema checks, while CRDs add resource types and validation rules that are not present in the pasted YAML. Kubernetes documents the strict, warn, and ignore validation modes in the kubectl apply reference.
When you need to know whether the target cluster would accept the manifest, a useful next step is kubectl apply --dry-run=server -f manifest.yaml. A server-side dry run submits the request for server processing without persisting the resource.
A server-side dry run submits the request for normal server processing without persisting the resource, which is the closest check available before an actual write.