Description
Kubernetes uses memory requests when scheduling Pods. If a request is lower than actual needs, too many workloads may be placed on one node and resource planning can become inaccurate.
When a memory limit is set without a request, Kubernetes copies the limit to the request if admission has not supplied another default request. Omission therefore does not always mean a zero memory request. Check the values on the created Pod.
Potential impact
- Requests that are too low can allow excessive workload placement on a node.
- Understated needs can increase resource contention and OOM risk.
- Requests that are too high can waste capacity or leave Pods unschedulable.
Remediation
- Set
resources.requests.memoryfrom measured usage and adjust it periodically. - Review memory requests and limits together, remembering that a request is not a usage ceiling.
- Check Pod requests after defaults such as LimitRange have been applied, and validate them with load testing.
Examples
These are memory-setting excerpts. Configure stress-image arguments and required CPU requests separately. The values 100Mi and 200Mi are examples.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo-ctr-1
image: polinux/stress
resources:
limits:
memory: "200Mi"
requests:
cpu: "0.5"
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo-ctr
image: polinux/stress
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
Explanation:
- Before: The memory limit is 200Mi, so the memory request also becomes 200Mi unless another default request is applied.
- After: A 100Mi request and 200Mi limit are explicit. Check that the request accommodates normal load.