Kubernetes Manifest Validator

How it works

Validation runs entirely against a fixed rule set in the browser: it parses one or more ----separated documents with js-yaml, then checks each for the required apiVersion/kind/metadata.name fields, cross-references apiVersion+kind against a hardcoded list of built-in Kubernetes resource types, and walks the pod spec recursively to flag containers with no resources.requests/limits, images pinned to :latest or with no tag at all, privileged: true security contexts, and hostNetwork: true.

FAQ

Does a clean result mean my manifest will apply successfully?

No — this only checks the rules built into the tool (required fields, known kind combos, a few common smells). It doesn't run a real API-server dry-run, so it won't catch CRD schema violations, webhook rejections, or cluster-specific admission policies.

Why did it flag an apiVersion/kind combination that I know is correct?

The known-kind check only recognizes a fixed list of built-in Kubernetes resources — anything else, including valid CRDs like a cert-manager Certificate or an Argo Rollout, gets a warning to double-check spelling rather than a hard error.