Kubernetes Manifest Validator

A Kubernetes manifest is a YAML (or JSON) file that describes the desired state of a Kubernetes resource — such as a Deployment, Service, ConfigMap, or Pod. kubectl apply -f manifest.yaml submits it to the API server, which reconciles the cluster to match that desired state.

Every Kubernetes resource requires four top-level fields: apiVersion (e.g. apps/v1), kind (e.g. Deployment), metadata (which must contain at least name), and usually spec. Missing any of these will cause kubectl apply to reject the manifest.

Without resource limits (resources.limits.cpu and resources.limits.memory), a single misbehaving pod can consume all node resources and evict other workloads. The scheduler also cannot make accurate placement decisions. Setting both requests (soft minimum) and limits (hard cap) is a Kubernetes best practice required for QoS guarantees.

The :latest tag is mutable — it can point to a different image each time it's pulled, making deployments non-reproducible. In production, always pin to an immutable digest or a specific semantic version tag (e.g. nginx:1.25.3) to ensure consistent rollouts and easy rollbacks.

A readiness probe tells Kubernetes when a container is ready to accept traffic — failing pods are removed from Service endpoints. A liveness probe tells Kubernetes when a container is unhealthy and should be restarted. Without probes, traffic can reach containers that aren't ready, and stuck containers won't be automatically recovered.

Yes. Kubernetes manifests support multiple resources separated by --- (YAML document separator). This validator handles multi-document YAML, validating each resource independently and showing results grouped by document.