Kubernetes YAML Linter & Validator

The Rollout That Showed No Error At All

A representative story: a payments service Deployment is edited to bump its replica count, the change merges, and kubectl apply reports success — no error, no warning. Twenty minutes later, on-call notices that kubectl get deployments still shows 0/0 ready replicas, and no new pods exist anywhere in the namespace. The manifest looked correct on review: spec.selector.matchLabels read app: payments-api, and the pod template's labels read app: payments-svc — a one-character difference in a label value from an earlier rename that never got fully propagated. The Kubernetes API server accepts this Deployment object without complaint, because a selector/template label mismatch is not a schema violation — it's a Deployment that is technically valid YAML but structurally incapable of ever managing a single pod, and nothing in kubectl apply's output says so. Pasted into a validator that specifically checks selector-to-template label agreement, the mismatch surfaces in seconds instead of during a stalled rollout at 2 a.m.

Validating One File vs. an Entire GitOps Repository

Checking a single manifest pasted into a browser tab is near-instantaneous — the lightweight JavaScript YAML parser and rule engine run entirely client-side and return results before you'd finish reading them. That workflow is for the individual-file case: reviewing one PR, sanity-checking one file before an ad hoc kubectl apply. It doesn't scale to validating an entire GitOps repository with hundreds of manifests across dozens of namespaces on every commit — that volume belongs in a CI job running a command-line validator (or the same rule set exposed as a pre-commit hook) across the whole tree in one pass, with this browser tool reserved for the fast, interactive loop of fixing one flagged file at a time after the bulk scan points at it. Multi-document YAML using --- separators is supported here too, so a single paste can still validate a handful of related resources — a Deployment plus its Service and ConfigMap — together, which covers the common case of reviewing one logical change without needing the full-repo tooling.

Manifest Habits That Prevent the 2 a.m. Page

• Always set both requests and limits on every container: A missing resource block lets the scheduler place a pod anywhere regardless of actual need, and lets one runaway container starve every other workload on its node.
• Never leave a Deployment without a readiness probe: Without one, Kubernetes considers a pod ready the instant its process starts, routing live traffic to an instance that hasn't finished initializing yet.
• Validate before merge, not before apply: Running the check as a required CI status on the pull request catches the error while it's still a five-minute fix, rather than after it's already in the default branch and someone else has applied it.
• Re-validate after any Kubernetes version bump: An API version that was merely deprecated on your last cluster version — like extensions/v1beta1 Ingress — can be removed outright on the next one, turning a warning into a hard failure at the worst possible time.

A Browser Check vs. a Real API Server

This tool and kubectl apply --dry-run=server check different things and are meant to be used together, not as substitutes. The browser validator catches YAML syntax errors, missing required fields, incorrect apiVersion pairings, and structural best-practice violations instantly, with no cluster access required — ideal for the write-fix-recheck loop during authoring. It cannot catch anything that depends on live cluster state: admission webhook rejections, CustomResourceDefinition schema validation for CRDs your cluster defines, RBAC policy denials, or namespace resource quota violations, all of which only the API server itself can evaluate. The practical sequence: use this validator for fast local iteration while writing the manifest, then run server-side dry-run as the final gate in CI before a real apply, catching the cluster-specific class of errors the browser tool structurally cannot see.

Mistakes That Slip Past a Quick Read-Through

• An image tag pinned to latest: Passes every schema check silently, but means a pod restart can pull a completely different image version than the one currently running, without any manifest change to explain it.
• A CronJob schedule with a typo'd field count: A five-field cron expression with an extra or missing field is easy to miss visually but changes the job's trigger time completely, or fails outright depending on the parser.
• A Service selector that doesn't match any pod labels: Structurally valid on its own, and only becomes visible as a problem when the Service has zero endpoints — which nothing in the Service manifest itself will tell you.
• Copy-pasted metadata.name values across environments: Reusing the exact same manifest for staging and production without templating the name or namespace risks a production apply accidentally overwriting a staging resource, or vice versa.

Frequently Asked Questions