LogShare
Start sharing
Tutorial · K8s YAML Validator · 5 min read

How to Validate Kubernetes YAML Before Apply

Catch YAML syntax errors, missing required fields and risky settings such as latest tags, absent resource limits and missing probes before kubectl apply.

Most manifest problems are visible before a cluster ever sees them: an indentation slip, a missing apiVersion, a container pinned to latest, no resource requests, no readiness probe. A static check finds those in a second. kubectl --dry-run=server then confirms the parts only a real API server knows.

What you'll learn

  • Check manifest structure: apiVersion, kind, metadata.name, selectors
  • Spot the misconfigurations that cause outages later
  • Combine a static check with kubectl dry-run

Step by step

  1. Paste the manifest

    Open the Kubernetes YAML Validator and paste one document or a --- separated file. Try an example loads a Deployment with typical issues.

  2. Click Validate

    Findings are grouped: ERROR for things the API server will reject, WARNING for risky but valid settings, INFO for best-practice suggestions.

    image: nginx:latest        → WARNING pin an explicit version
no resources on container  → WARNING set requests and limits
no readinessProbe          → WARNING traffic may hit an unready pod
no securityContext         → INFO consider runAsNonRoot

  3. Fix errors first

    Errors such as a missing kind, a selector that does not match template labels, or invalid YAML must be fixed before apply will work.

  4. Confirm against the cluster

    Run kubectl apply --dry-run=server -f manifest.yaml. It validates against your cluster version, CRDs and admission webhooks, which no offline tool can.

Open the tool with this example Runs in your browser. Nothing you paste is uploaded.

Common problems

bad indentation of a mapping entry

YAML nesting is defined by spaces. A line indented differently from its siblings, or a tab character, breaks the document.

selector does not match template labels

spec.selector.matchLabels must be a subset of spec.template.metadata.labels, otherwise the Deployment cannot own its pods. The validator reports this as an error, and so does the API server.

Why warn about latest?

latest changes without notice, so two nodes can run different code and rollbacks become guesswork. Pin a version or a digest.

FAQ

Does this replace kubectl apply --dry-run?

No. It catches structural and best-practice issues instantly and offline; the server dry run is the final word.

Is my manifest uploaded?

No. Parsing and checks run in your browser; manifests often contain internal hostnames, so nothing leaves your device.