Description
A LimitRange checks configured resource request and limit bounds for Pods, containers or PVCs in a namespace, and can supply default container requests and limits. Without one, consistent resource policy may be harder to enforce, but check workload settings and other admission policies as well. Its role differs from ResourceQuota, which constrains aggregate namespace consumption.
Potential impact
- Excessive requests or missing resource settings can reach the environment.
- Overly strict or inconsistent constraints can prevent legitimate Pods from being created.
Remediation
- Configure LimitRange object types, minimum/maximum values and default container requests and limits according to namespace workload needs. Review required CPU, memory and PVC storage constraints separately.
- Test effective admission values and creation of legitimate workloads. Existing Pods are not automatically changed when the policy is added; review them separately and configure ResourceQuota if aggregate usage must be limited.
Examples
The mypod namespace must exist. Replace the image address with an actual verified image. The 200m–800m CPU range is illustrative; check the effective default requests and limits as well.
Before
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: mypod
spec:
containers:
- name: app
image: images.my-company.example/app:v4
No resource settings or LimitRange are shown for this Pod. Check existing namespace policies too.
After
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-min-max-demo-lr
namespace: mypod
spec:
limits:
- type: Container
min:
cpu: "200m"
max:
cpu: "800m"
---
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: mypod
spec:
containers:
- name: app
image: images.my-company.example/app:v4
A LimitRange constrains container CPU only. This does not also configure memory or PVC storage constraints.