CKAD Practice Question 8: OOMKilled Memory Limit
Certified Kubernetes Application Developer (CKAD) · Test 1 · question 8 of 10
A container is declared with requests: {memory: 256Mi, cpu: 200m} and limits: {memory: 512Mi, cpu: 500m}. Under load its Pod restarts every few minutes. kubectl describe pod reports:
Last State: Terminated Reason: OOMKilled Exit Code: 137
The node it runs on reports more than 20 GiB of free memory, and no eviction events appear on the node. What is happening, and what is the correct remedy?
Show answer and explanation
Answer:
A memory limit is enforced by the kernel cgroup around that single container. When its working set grows past 512Mi the OOM killer terminates the process (reported as Reason: OOMKilled with exit code 137) no matter how much memory the node still has. The fix is to raise limits.memory to match the application's real working set, or to reduce that working set (smaller caches, heap or GC tuning). Raise the request alongside it so the scheduler actually reserves what the container needs.
Option A describes a different failure. Node-pressure eviction produces a Pod with Reason: Evicted and a node condition plus eviction events, none of which the stem shows, and the node has ample free memory.
Option B misclassifies the Pod. A container with both requests and limits set, where the requests are lower than the limits, is Burstable; BestEffort means no requests or limits at all. QoS class also governs eviction ordering under node pressure, not per-container OOM kills.
Option C inverts the roles of the two fields. requests is used only for scheduling and for cgroup shares; it never caps consumption. limits is the enforced ceiling, so raising the request alone would change placement without preventing the kill.
Reference: Resource Management for Pods and Containers