About the Kubernetes YAML Linter
Most Kubernetes production incidents trace back to manifests that were syntactically valid but operationally wrong: no resource limits, no liveness or readiness probes, containers running as root, or images pinned to :latest. This linter checks manifests against those best practices before they reach a cluster.
It runs entirely in the browser — paste a Deployment, StatefulSet, or any workload manifest and get findings grouped by severity. Use it as a pre-review pass before your CI policy gates (OPA/Gatekeeper, Kyverno) reject the change with less friendly messages.
Frequently asked questions
Why do missing resource limits matter?
Without limits, a single pod can consume a node's entire memory and trigger OOM kills of unrelated workloads; without requests, the scheduler places pods blind, causing noisy-neighbor contention. Requests determine scheduling and QoS class; limits cap runaway usage. Production workloads should set both — deliberately.
What is the difference between liveness and readiness probes?
A readiness probe controls traffic: failing it removes the pod from Service endpoints without restarting it. A liveness probe controls restarts: failing it kills the container. Using a liveness probe where readiness was intended turns a transient slowdown into a restart loop — one of the most common self-inflicted outages.
Why is image: latest flagged?
Tags are mutable. :latest (or any mutable tag) means a pod rescheduled tonight can pull different code than the pod deployed this morning — unreproducible rollbacks and impossible debugging. Pin a digest or an immutable version tag so the manifest fully determines what runs.