Kubernetes YAML Linter
Lint Kubernetes Deployments, Services, ConfigMaps, and Ingresses. Flags deprecated APIs, missing resource limits, :latest images, and secrets stored in ConfigMaps.
About this tool
Kubernetes manifests have a lot of valid-but-bad shapes. They parse,
they apply, they even run — but they create operational pain. Common
examples: a Deployment with no resource limits (one greedy pod can
starve the node), an image pinned to :latest (no
reproducibility), a Service with a selector that matches nothing (no
endpoints, traffic is dropped), a ConfigMap holding what should
really be a Secret (cleartext credentials in etcd).
The linter walks every document in your file (multi-doc YAML
separated by --- works), classifies each by
kind, and runs kind-specific checks. Per-document
issues are surfaced with the document number, the resource kind and
name, and the field path — paste a 500-line manifest and find the
one bad bit fast.
Use this for editor-time quality, not for cluster-time validation.
For schema correctness against a specific Kubernetes API server,
kubectl apply --dry-run=server or
kubeconform are the right tools.
Frequently asked questions
Is this a replacement for kubeval / kubectl validate?
No — those validate against the cluster API schema for a specific Kubernetes version, which catches more than a static check can. This linter catches the common quality issues those tools do not warn about (missing limits, latest tags, secrets in ConfigMaps, deprecated apiVersions).
Does it support multi-document YAML?
Yes. Documents separated by `---` are parsed independently and reported with a doc number. Service-to-workload selector matching is checked across documents in the same file.
What deprecated APIs does it know about?
extensions/v1beta1 (removed 1.16), apps/v1beta1 + apps/v1beta2 (1.16), networking.k8s.io/v1beta1 (1.22), rbac.authorization.k8s.io/v1beta1 (1.22), autoscaling/v2beta1 (1.22), autoscaling/v2beta2 (1.26), batch/v1beta1 (1.25), policy/v1beta1 (1.25). Each maps to its replacement.
Why does it flag :latest?
Because deployments using :latest are not reproducible. A pod restart pulls whatever the registry currently calls latest, which can differ from what the original deployment used. Pin to a tag or digest.
What is the ConfigMap secrets check?
ConfigMap data is stored unencrypted and viewable by any RBAC subject with read access. If a key name suggests a secret (password, token, api-key, credential), the value almost certainly belongs in a Secret instead.