A payment container’s memory limit is 256Mi. Under a traffic spike the process allocates beyond that limit and the container exits with reason OOMKilled. What caused that termination?
Select an answer to reveal the explanation.
Short Explanation
Memory limits are a hard wall: climb over them and the kernel OOM-kills that container. CPU limits slow you down instead of staging that same kill. Check the limit and the app’s real footprint together.
Full Explanation
When a payment container's memory limit is 256Mi and under a traffic spike the process allocates beyond that limit, the container exits with reason OOMKilled because it exceeded its memory limit and the runtime invoked the OOM killer for that cgroup. That termination is memory enforcement. Civic payment services must size limits for peak, bound in-memory caches, or both, or they will flap under seasonal load.
Claiming CPU throttling always surfaces as OOMKilled when limits.cpu is set fails—CPU limits throttle time slices; they do not kill processes the way memory cgroup overages do. Claiming the Pod was BestEffort so any memory use triggers immediate cluster-wide eviction of every replica overgeneralizes QoS behavior and eviction scope. Claiming Insufficient cpu scheduling events rewrite running containers as OOMKilled confuses Pending scheduling messages with runtime termination reasons.
Exam caveat: distinguish container-level OOMKilled from node MemoryPressure eviction events that may terminate Pods to protect the node. Operational check: kubectl describe for lastState.reason OOMKilled, compare limits.memory to observed usage, raise the limit or fix the application footprint, roll the Deployment, and retest under a comparable traffic spike.