Kubernetes YAML Linter & Validator
Paste any Kubernetes manifest to validate YAML syntax, required fields, API version structure, resource specifications and catch common misconfigurations — before running kubectl apply. Supports multi-document YAML with --- separators.
kubectl apply --dry-run=server for full server-side validation.
What is a Kubernetes YAML Validator?
A Kubernetes YAML validator checks your manifest files for structural and semantic errors before you apply them to a cluster. It parses the YAML, verifies required fields like apiVersion, kind, and metadata.name, validates the resource kind against known Kubernetes API groups, and checks for common misconfigurations such as missing resource limits, absent liveness probes, or selector-label mismatches that would prevent a Deployment from ever managing any pods.
Kubernetes manifests are dense YAML documents, and small mistakes — a wrong apiVersion for a resource kind, a missing spec.selector, or an image tag pinned to latest — can cause silent failures, CrashLoopBackOff events, or security vulnerabilities in production. Validating manifests locally or in CI before running kubectl apply catches these issues in seconds instead of discovering them during an incident.
When to Use This Tool
- Before
kubectl applyin any environment: Validate your manifest to catch YAML syntax errors, wrong API versions, and missing required fields before touching a real cluster — especially important when working on staging or production namespaces. - During CI/CD pipeline setup: Integrate manifest validation as a gate in your pipeline so that pull requests with invalid Kubernetes YAML are rejected before they can be merged, reducing the risk of broken deployments.
- During code review of infrastructure changes: When reviewing another engineer's Kubernetes manifest PR, use the validator to quickly surface structural issues — such as containers missing resource limits or Deployments with no readiness probe — that are easy to miss during manual review.
- When upgrading Kubernetes versions: Validate existing manifests against updated API versions (for example, migrating from deprecated
extensions/v1beta1Ingress tonetworking.k8s.io/v1) to identify resources that need updating before the old API versions are removed.
How It Works
The tool uses a lightweight YAML parser built in JavaScript to parse your manifest into a structured object, then applies a rule engine that checks each resource kind against its expected apiVersion, validates required top-level fields, and runs kind-specific checks. For workloads (Deployments, StatefulSets, DaemonSets), it inspects the pod template spec for container definitions, resource requests and limits, readiness and liveness probes, and security context settings. Multi-document YAML (using --- separators) is supported and each document is validated independently. All processing runs entirely in the browser with no data sent to any server.
Frequently Asked Questions
What Kubernetes resources does this validator check?
The validator checks Deployments, StatefulSets, DaemonSets, ReplicaSets, Services, Ingresses, ConfigMaps, Secrets, PersistentVolumeClaims, Jobs, CronJobs, HorizontalPodAutoscalers, ServiceAccounts, Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, Namespaces, and more. For each resource kind, it validates the required fields, verifies the correct apiVersion, and applies kind-specific rules — for example, checking that a CronJob has a valid five-field cron schedule, or that an HPA references a valid scaleTargetRef with minReplicas not greater than maxReplicas.
Does this replace kubectl --dry-run?
This tool provides instant client-side validation for YAML syntax, required field structure, API version correctness, and Kubernetes best practices without requiring access to a Kubernetes cluster. It is ideal for fast feedback during development. For complete validation — including server-side admission webhook checks, custom resource definition (CRD) schema validation, RBAC policy enforcement, and namespace quota verification — you should also run kubectl apply --dry-run=server against a representative cluster. Use both tools together: this validator for fast local feedback, and server-side dry-run as a final gate in CI/CD.
Why should I always set resource requests and limits in Kubernetes?
Resource requests tell the Kubernetes scheduler how much CPU and memory a pod needs, which it uses to find a node with sufficient available capacity. Without requests, pods may be scheduled onto already-overloaded nodes, leading to poor performance or OOM kills. Resource limits act as a hard cap, preventing a single misbehaving container from consuming all resources on a node and starving neighboring workloads. The Kubernetes documentation and most organizational security policies require both requests and limits to be set, and many clusters enforce this via a LimitRange or OPA/Gatekeeper admission policy. Setting them also enables the Horizontal Pod Autoscaler to make accurate scaling decisions based on actual resource utilization.