How to Validate Kubernetes YAML

Validate documents before contacting a cluster

Paste manifests into the Kubernetes YAML Validator and select Validate Kubernetes. SyntaxDock parses YAML, checks resource envelopes and supported built-in schemas, and reports targeted security and reliability concerns. Processing stays in your browser; represented URLs and cluster endpoints are never contacted.

YAML and multiple documents

Use --- between resources. Indentation, duplicate keys and malformed sequences can prevent later schema checks. Each non-empty document has a resource identity; a YAML parse error anywhere in the stream prevents schema and lint checks until the YAML is fixed. Diagnostics identify the document and source position when available; select one to focus the affected location.

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-settings
  namespace: demo
data:
  MODE: "example"
---
apiVersion: v1
kind: Service
metadata:
  name: example-web
spec:
  selector:
    app: example-web
  ports:
    - port: 80
      targetPort: 8080

The Service selector refers to labels on Pods, not a Pod name. This example contains no workload, so it cannot demonstrate reachable endpoints.

Understand apiVersion, kind and the pinned schema

Group, version and kind identify a resource type. For example, apps/v1 with Deployment differs from core v1 with Service. SyntaxDock uses the pinned Kubernetes v1.36.3 OpenAPI v3 snapshot documented in the tool. It does not discover the version or enabled APIs of your cluster.

A supported schema can identify incorrect field types and required fields. Alpha and beta API availability may still depend on feature gates. A type being present in the snapshot does not guarantee that your API server accepts it.

Review labels and selectors in context

When reviewing workloads, compare the workload selector with its Pod-template labels. Check namespaces and Service selectors as well. Matching labels describe intended relationships; static validation cannot prove that matching Pods exist, are ready, or run successfully. Review related resources together, and use cluster-side inspection for operational state.

Security and reliability checks

Review floating image tags, missing resource requests or limits on regular containers, privileged containers, privilege escalation, host networking and sensitive host-path mounts. Diagnostics are aids for configuration review, not a full policy engine or security certification. Warnings can describe valid manifests whose operational trade-offs still need attention.

Custom resources and server-side limits

Arbitrary custom resources cannot be fully checked without their CRD schemas. SyntaxDock retains YAML and resource-envelope diagnostics and reports the schema limitation. It does not fetch CRDs or schemas from URLs in a manifest.

OpenAPI validation cannot reproduce admission controllers, authorization, quotas, defaulting, mutation, cluster configuration or runtime state. Use kubectl apply --dry-run=server -f manifest.yaml in your own trusted environment when you need an API-server check; that command contacts your cluster. It is separate from SyntaxDock's local workflow. See Kubernetes API concepts for server request behavior.