ModernCalcs

Kubernetes YAML Validator

Check a Kubernetes manifest for missing required fields, invalid names, and the classic selector/template label mismatch.

No structural issues found
Parsed 2 document(s) with no structural errors.

Kubernetes YAML Validator: Catch Manifest Mistakes Before kubectl apply

A mismatched selector and template label, a container missing an image, or an invalid resource name are all mistakes that kubectl apply rejects with an error — after you've already switched context to your cluster. This validator checks the structural rules that apply to any Kubernetes manifest, entirely offline.

Formula
spec.selector.matchLabels ⊆ spec.template.metadata.labels

Every Deployment, StatefulSet, DaemonSet, and Job must satisfy this, or the API server rejects the object.

The Selector/Template Label Trap

It's easy to update a Deployment's pod template labels without remembering to update spec.selector.matchLabels to match — but Kubernetes requires the selector to be a subset of the template's labels, and this field is immutable after creation. Catching the mismatch before you apply saves a confusing 'field is immutable' error on an update.

Universal Required Fields

Every Kubernetes object — regardless of kind — needs apiVersion, kind, and metadata.name at minimum. Missing any of these means the API server can't even identify what resource type you're trying to create, let alone validate its spec.

Container-Level Checks

Inside a workload's pod template, every container needs a name and an image — Kubernetes won't schedule a pod without them. This validator also checks that any declared containerPort is a valid TCP/UDP port number (1-65535), catching typos like a port pasted with an extra digit.

Practical Examples

Catching a Selector Mismatch

A common Deployment editing mistake.

  • 1.selector.matchLabels: { app: web }
  • 2.template.metadata.labels: { app: webapp }
  • 3.Error: selector must be a subset of template labels — mismatch on "app"

Validating Multi-Document Manifests

A Deployment and Service in one file.

  • 1.Document 1: Deployment (validated for containers, selector)
  • 2.Document 2: Service (validated for selector, ports)
  • 3.Both validated independently, separated by ---

What Gets Checked

  • apiVersion, kind, metadata.name: required on every object
  • DNS-1123 naming: lowercase, alphanumeric, '-'
  • Containers: name, image, valid ports
  • Selector/template label match for workload kinds
  • Service ports: valid port numbers

Good Use Cases

  • Reviewing a manifest before a real kubectl apply
  • Debugging a confusing 'selector does not match template labels' error
  • Auditing a multi-document manifest file for missing fields
  • Learning Kubernetes manifest structure with immediate feedback

Frequently Asked Questions

Does this replace 'kubectl apply --dry-run' or 'kubectl --validate'?

No — those talk to your actual cluster's API server and validate against the live OpenAPI schema, including CRDs and admission webhooks. This tool checks a common, high-value subset of structural rules locally, without a cluster, before you even have kubectl configured.

Why does the selector/template label check matter so much?

It's one of the most common real-world Kubernetes mistakes: spec.selector.matchLabels must be a subset of spec.template.metadata.labels for Deployments, StatefulSets, DaemonSets, and Jobs. If they don't match, the Kubernetes API server rejects the manifest outright with an often-confusing error — this validator catches the mismatch before you get there.

Does it support multiple resources in one file?

Yes. Kubernetes manifests are commonly split into multiple YAML documents separated by '---' in a single file, and each document is validated independently.

What does the DNS-1123 name check mean?

Kubernetes resource names must be lowercase alphanumeric characters or '-', and can't start or end with a '-' — this is the DNS-1123 subdomain naming convention, since resource names are used in DNS records and labels internally.

Does this validate CustomResourceDefinitions (CRDs)?

It checks the universal required fields (apiVersion, kind, metadata.name) that apply to any Kubernetes object, including CRDs, but it can't validate a CRD's custom spec schema since that's defined by the CRD itself, not a fixed standard.

Is my manifest uploaded anywhere?

No — parsing and validation both happen locally in your browser using a bundled YAML parser, with no cluster access and no upload.