Kubernetes YAML Validator

Kubernetes Manifest Validation Before Apply

kubectl apply is unforgiving. Submit a manifest with a missing field or a deprecated apiVersion and you get a terse error, sometimes hundreds of lines into your YAML, with a line number that doesn't quite line up. This validator catches the structural and best-practice issues before you ever talk to a cluster, so the apply succeeds the first time.

The Three Layers of Manifest Correctness

Kubernetes manifests have three levels of "correctness":

1. YAML syntax. Balanced braces, valid indentation, no tab/space mixing. Any YAML linter catches these. (yamllint, IDE plugins.)
2. Kubernetes schema. The right top-level fields (apiVersion, kind, metadata, spec), with shapes that match what the API server expects for that kind. The API server validates this; this tool validates structurally without one.
3. Best practices. Resource limits, readiness probes, pinned image tags, labels. Apply succeeds without these, but you'll regret it operationally.

YAML linters cover #1. kubectl apply --dry-run=server covers #1 and #2. This validator covers all three statically, before any cluster contact.

Required Fields Per Kind

Every Kubernetes resource needs:

• apiVersion, the version of the API group that owns this kind. Wrong here is the most common deploy-time error.
• kind, what you're creating. Case-sensitive (Deployment, not deployment).
• metadata.name, a valid DNS subdomain (lowercase, hyphens, dots; max 253 chars). Wrong characters reject at apply.

The big trap: apiVersion drifts. extensions/v1beta1 for Deployment was removed in 1.16; it now lives at apps/v1. Same story for Ingress (moved from extensions/v1beta1 → networking.k8s.io/v1 in 1.22). Old tutorials and ChatGPT outputs are full of these. The validator flags them.

The required apiVersion-for-kind pairings the validator checks:

• Deployment, StatefulSet, DaemonSet, ReplicaSet → apps/v1
• Pod, Service, ConfigMap, Secret, Namespace, PersistentVolume, PersistentVolumeClaim → v1
• Ingress, NetworkPolicy → networking.k8s.io/v1
• Job, CronJob → batch/v1
• Role, RoleBinding, ClusterRole, ClusterRoleBinding → rbac.authorization.k8s.io/v1
• HorizontalPodAutoscaler → autoscaling/v2

Workload-Specific Checks (Deployment, StatefulSet, DaemonSet)

For workloads, the validator descends into spec.template.spec:

• containers must be present and non-empty. A common copy-paste mistake: pasting just the pod-template-metadata and forgetting the containers array.
• Each container needs name and image. Missing image = ImagePullBackOff loop on apply.
• Resource requests/limits. Without limits, a single buggy container can OOM the node. Without requests, the scheduler can't reason about placement. Warning, not error.
• Readiness probe. Without one, the Service sends traffic before the app is ready, users see 502s during rollouts. Warning.
• Liveness probe. Optional but recommended for self-healing on deadlock.
• :latest image tags. Reproducibility killer; today's latest is not tomorrow's. Warning.

Service Checks

For Services:

• selector matches workload labels. A Service whose selector doesn't match any Pod is silent: traffic goes nowhere, no error. The validator flags Services with empty or suspicious selectors.
• port and targetPort shape. Both numeric or both string (named port from the container). Mixing them is a slow-burn bug.
• type semantics. type: LoadBalancer on clusters without a cloud provider sits Pending forever; type: NodePort on a managed cluster is usually a mistake (use LoadBalancer or Ingress).

Common Mistakes the Validator Catches

The patterns we see repeatedly:

• Pasted a Pod when meant Deployment. Pods are bare and don't survive node failure. If you've got more than one replica, you want a Deployment.
• Used name instead of metadata.name. Top-level name is silently ignored; the resource gets a random name. Apply succeeds, debugging is awful.
• labels at the wrong level. Pod labels go in spec.template.metadata.labels; Deployment-level labels are separate. The selector matches Pod labels, not Deployment labels.
• replicas: "3" instead of replicas: 3. YAML happily produces a string; the API server rejects it. Type errors caught at parse time.
• CamelCase vs camelCase. Kubernetes uses camelCase in spec (readinessProbe, not ReadinessProbe). YAML doesn't care; the API server does.

Best-Practice Warnings

Beyond shape, the validator flags operational gotchas:

• No namespace specified. Falls back to default, fine for dev, sloppy for prod. Flagged as info.
• No app.kubernetes.io/* labels. The recommended label set (name, instance, version, component, part-of, managed-by) is the convention for tooling (Helm, Kustomize, Grafana dashboards). Missing them works but breaks integrations.
• hostPath volumes. Tie a Pod to a specific node's filesystem; almost always wrong outside of cluster operators.
• Privileged containers. securityContext.privileged: true should set off alarms in production.

Where This Validator Stops

Out of scope:

• OpenAPI schema validation against your cluster's version. Use kubectl validate or kubeconform.
• Policy validation (OPA, Kyverno). Use the policy engine's CLI.
• Cost analysis. Tools like kubecost handle that.
• Network reachability simulation. Use netshoot or ksniff in a test cluster.

This is a fast first-pass: catch the dumb stuff before you queue up the slow stuff.

Privacy

Validation runs entirely in your browser. Kubernetes manifests routinely contain ingress hostnames, image registry paths, environment-variable defaults, and inline configmaps, none of it leaves your tab. Open DevTools Network during a validation: zero outbound requests.