How to Validate Kubernetes YAML Manifests Before Deploying

Kubernetes YAML is notoriously unforgiving. A misplaced indentation, a misspelled field name, or a wrong API version can cause a deployment to fail silently, partially apply, or produce cryptic error messages that take time to decode.

The worst time to discover a YAML error is when you are deploying to production. Validating manifests before kubectl apply catches these issues early and prevents failed deployments.

Why Kubernetes YAML Validation Matters

YAML is sensitive to indentation

YAML uses indentation to express structure. An extra two spaces turns a field into a nested child of the field above it. Kubernetes silently ignores unknown fields in many cases, which means a misconfigured field may not produce an error — it simply has no effect.

API versions change between Kubernetes releases

Kubernetes deprecates and removes API versions over time. A manifest using apiVersion: extensions/v1beta1 for a Deployment worked in Kubernetes 1.15 but fails in 1.22 where that API version was removed. Validators check your apiVersion against the schema for your target cluster version.

Complex nesting is easy to get wrong

A Deployment wraps a ReplicaSet spec which wraps a Pod spec. The container definition is three levels deep. Missing any level of nesting produces a valid YAML document that fails Kubernetes schema validation.

What Gets Validated

A Kubernetes YAML validator checks:

• API version and kind — Is this a recognized Kubernetes resource type?
• Required fields — Does the manifest have all required fields (e.g., metadata.name, spec.selector for a Deployment)?
• Field types — Are string fields strings, integer fields integers, boolean fields booleans?
• Enum values — Are fields like imagePullPolicy set to one of the allowed values (Always, Never, IfNotPresent)?
• Structural validity — Are nested fields in the right place?

Common Kubernetes YAML Errors

Wrong selector / label mismatch

A Deployment's spec.selector must match the Pod template's metadata.labels. If they do not match, the Deployment cannot manage its Pods:

# This will fail — selector doesn't match template labels
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-application  # Mismatch!

Missing resource limits

While not a schema validation error, missing resource limits is flagged by most validators as a best practice issue. Without limits, a single container can consume all node resources:

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Deprecated API versions

# Removed in Kubernetes 1.22
apiVersion: networking.k8s.io/v1beta1
kind: Ingress

# Current
apiVersion: networking.k8s.io/v1
kind: Ingress

Wrong port protocol

ports:
  - containerPort: 8080
    protocol: TCP  # Must be TCP, UDP, or SCTP

Using the DevHexLab Kubernetes YAML Validator

Paste your manifest (or multiple manifests separated by ---) into the validator. Select your target Kubernetes version. The validator checks the manifest against the official Kubernetes OpenAPI schema for that version.

Multi-document YAML

Most Kubernetes applications have multiple resources. Separate them with ---:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
---
apiVersion: v1
kind: Service
metadata:
  name: my-app

The validator processes each document independently.

Understanding validation output

Each finding includes:

• Path — the YAML path to the invalid field (e.g., spec.template.spec.containers[0].resources)
• Message — what the validator found wrong
• Severity — error (deployment will fail) or warning (best practice violation)

Integrating Validation into CI

Add YAML validation to your CI pipeline to catch errors before pull requests are merged:

# GitHub Actions example
- name: Validate Kubernetes manifests
  run: |
    kubeval --kubernetes-version 1.29.0 k8s/*.yaml

Tools like kubeval, kubeconform, and kube-score can be used in CI pipelines alongside the browser-based validator for quick iteration.

Conclusion

Validating Kubernetes YAML before applying it prevents deployment failures, catches API version deprecation early, and enforces best practices around resource limits and health checks. The DevHexLab Kubernetes YAML Validator lets you check manifests instantly in the browser without installing any tooling.