Why Unvalidated Manifests Fail at Runtime
kubectl applies manifests without deep semantic validation. A Deployment with a missing required field or an unsupported API version is accepted and stored in etcd, then fails when the controller tries to act on it. The error appears in pod events or controller logs, not at apply time. Linting catches these before they reach the cluster.
Resource Limits Are Not Optional
Containers without CPU and memory limits can consume all resources on a node, starving other workloads. Most production clusters enforce resource quotas via LimitRange or ResourceQuota objects, which will reject pods without limits anyway. Linters flag missing resource requests and limits as an error.
Avoid the `:latest` Tag
Using :latest for container images breaks reproducibility — two deployments of the same manifest may run different code. It also defeats Kubernetes's image pull policy optimization. Always pin to a specific digest or version tag. Linters warn about :latest and untagged images.
Namespace Best Practices
Deploying to the default namespace mixes application workloads with system resources and makes RBAC harder. Use named namespaces per application or environment. Manifests missing a namespace field default to whatever the current kubectl context has configured — often not what you intend.
Other Common Issues
apiVersionusing deprecated or removed API groups for the target cluster version.imagePullPolicy: Alwaysin production (unnecessary latency).- Liveness probes with thresholds too sensitive (causes restart loops).