What Is a Kubernetes YAML Validator?
A Kubernetes YAML validator checks your K8s manifests for structural errors, missing required fields, deprecated API versions, and best-practice violations before you apply them to a cluster. Catching these problems before kubectl apply prevents failed deployments, crashed pods, and hard-to-debug rollout errors. This validator runs entirely in your browser — your YAML never leaves your machine, making it safe for proprietary configurations.
What This Validator Checks
- Required fields: Every resource needs apiVersion, kind, and metadata.name. Missing any of these is the most common cause of rejected manifests.
- Deprecated APIs: Detects old API versions such as apps/v1beta1, apps/v1beta2, extensions/v1beta1, policy/v1beta1, and batch/v1beta1, and suggests the current replacement (for example, apps/v1 for Deployments or networking.k8s.io/v1 for Ingress).
- Container best practices: Flags images using the :latest tag, missing resource limits and requests, and missing liveness/readiness probes.
- Reliability settings: Single-replica Deployments, missing namespace, and missing labels that break selectors and network policies.
- Multi-document files: Validates every document separated by --- in one pass, the way Helm templates and kustomize outputs are commonly shipped.
How to Validate Kubernetes YAML
- Paste your manifest into the editor, upload a .yaml file, or try one of the built-in examples.
- Click Validate YAML. The manifest is parsed client-side and each resource is checked against the rules above.
- Review the results panel: errors must be fixed, warnings are best-practice recommendations. Click a resource in the tree to jump between findings.
- Fix your manifest and re-validate until only green checks remain, then apply it with kubectl.
Why Validate Before kubectl apply?
The API server rejects malformed manifests at apply time, but structural errors are only the first failure layer. A syntactically valid Deployment can still schedule pods that crash-loop because of a missing probe, exhaust node memory because limits were never set, or silently fail an upgrade because it targets an API version removed in your cluster's release. The deprecated-API problem is the classic case: manifests written for older clusters keep working for months or years, then break during a Kubernetes upgrade. Checking manifests as part of development — the same way you lint code — catches these issues while they are still cheap to fix.
Client-side validation also complements, not replaces, server-side tools like kubeconform or kubectl's --dry-run=server: it gives instant feedback with zero setup, no cluster access required, and no risk of sending confidential manifest data to third-party services.