Description
Without an effective memory upper limit, a workload can consume excessive node memory. A leak or malfunction can then affect the entire node.
Memory limits help prevent a workload from monopolizing node resources. Check container settings along with LimitRange defaults and supported Pod-level resource settings.
Potential impact
- One container’s excessive memory use can affect node stability.
- Other Pods may be terminated or slow down under memory pressure.
- A failure can spread beyond the application to the node.
Remediation
- Check each container’s
resources.limits.memoryand the upper limit actually applied. - Choose a limit that fits the application and adjust it periodically. A limit that is too low can cause OOM termination.
- Review requests and limits together to support scheduling and stability.
Examples
These examples compare memory settings. Configure actual stress-image arguments and required CPU requests separately, and adjust 100Mi and 200Mi to measured workload needs.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-1
spec:
containers:
- name: memory-demo-ctr
image: polinux/stress
resources:
requests:
cpu: "0.5"
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-safe
spec:
containers:
- name: memory-demo-ctr
image: polinux/stress
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
Explanation:
- Before: This manifest has no memory limit. Also check defaults applied by the cluster.
- After: A 200Mi limit and 100Mi request are specified. Exceeding the limit can terminate processes, so monitor usage and OOM events.