Kubernetes Manifest Linter

It checks for: missing required fields (apiVersion, kind, metadata.name), image tag pinning (warns on :latest), resource requests and limits, liveness and readiness probes on Deployments, hardcoded secrets in environment variables, missing namespace, privileged containers, hostNetwork/hostPID usage, and common best practice violations.

Requests tell the Kubernetes scheduler how much CPU and memory a container needs — the scheduler uses this to place the Pod on a suitable Node. Limits cap the maximum resources a container can consume. Without them, a single runaway container can starve other workloads on the same node (noisy neighbour problem), and the scheduler cannot make good placement decisions.

A liveness probe checks if the container is still running. If it fails repeatedly, Kubernetes restarts the container. A readiness probe checks if the container is ready to receive traffic. If it fails, the Pod is removed from Service endpoints until it recovers. Both probes prevent traffic from reaching unhealthy or not-yet-ready containers.

The :latest tag is mutable — it points to different images over time. This means two nodes in your cluster may run different versions of your container, leading to non-deterministic behaviour and impossible rollbacks. Always pin to a specific tag (e.g. nginx:1.25.3) or a SHA digest (nginx@sha256:...) for reproducible, auditable deployments.

Never put passwords, API keys, or tokens directly in env: value fields — they appear in plaintext in kubectl describe output and cluster etcd. Use valueFrom.secretKeyRef to reference a Kubernetes Secret object, or use an external secret manager like HashiCorp Vault, AWS Secrets Manager, or the External Secrets Operator.

Yes. Paste multiple Kubernetes manifests separated by --- (the YAML document separator) and the linter will validate each one independently. This is useful for checking entire Helm chart output or a multi-resource deployment file at once.