LimitRange
Does ZopNight manage LimitRange?
LimitRanges inject default requests and limits into pods that declare none and reject those outside min/max bounds. The scope is per pod, where ResourceQuota caps the namespace total. ZopNight records each LimitRange's limits list per namespace; namespaces without one are where the missing-requests findings (RC-1700 through RC-1702) keep coming from.
Rules that fire on LimitRange
No active rule family targets LimitRange today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A LimitRange sets per-pod and per-container resource policy inside one namespace: default requests and limits injected into containers that declare none, and minimum/maximum bounds that reject outliers at admission. It is the quiet counterpart to ResourceQuota: quota governs the namespace total, LimitRange governs each individual pod.
Defaults applied at admission, not at runtime
When a container ships without requests or limits and the namespace has a LimitRange with defaults, the admission path writes those defaults into the pod spec before scheduling. Nothing is enforced retroactively: pods created before the LimitRange existed keep whatever they had, which is why adding one to a mature namespace changes behavior only as pods churn. Discovery records the limits list of each LimitRange per namespace, meaning the per-type default, defaultRequest, min, and max entries.
The connection to missing-requests findings
The workload rules flag Deployments, StatefulSets, and DaemonSets whose containers lack CPU or memory requests (RC-1700 through RC-1702 on EKS) because the scheduler places such pods blind. A LimitRange is the namespace-level remedy for the same disease: instead of chasing every manifest, defaults guarantee no pod lands unrequested. Namespaces that trigger frequent missing-requests findings and show no LimitRange in inventory are the ones where a single object would retire a whole class of finding.
Bounds that catch mistakes before nodes do
The min and max sides work as sanity rails. A max memory limit stops a fat-fingered 64Gi request from reserving a whole node for one pod; a min stops zero-request pods from packing so densely they starve each other. Both fail fast at admission with an explicit error, which is far cheaper to debug than the eviction storms and noisy-neighbor incidents the same mistakes cause at runtime.
kubectl get limitrange -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,LIMITS:.spec.limitsOne object per namespace is usually enough
A single LimitRange with conservative defaults (modest request, sane limit, generous max) covers the typical namespace. The review this inventory enables is coverage, not tuning: list namespaces carrying real workloads, subtract those with any LimitRange at all, and the remainder is where unbounded pods are still possible.