On-call notices a city API Pod is slow but still Running. Metrics show the container repeatedly hitting its CPU limit, while memory stays under the memory limit. What behavior should they expect from those limits?
Select an answer to reveal the explanation.
Short Explanation
CPU limits are like a speed governor — they hold you back but keep the engine running. Memory limits are a brick wall that can kill the process. Slow-but-alive often means throttle, not OOM.
Full Explanation
On-call notices a city API Pod is slow but still Running while metrics show the container repeatedly hitting its CPU limit and memory stays under the memory limit. In that situation CPU limits throttle the container without killing it, unlike memory limits which can OOMKill. Slowness with a Running phase is the expected symptom of CPU throttling on a municipal API under sustained load.
Claiming CPU limit breaches always OOMKill the container the same way memory limit breaches do fails the different enforcement mechanisms. Claiming exceeding a CPU limit deletes the Pod object from etcd until manually reapplied fails—throttling does not delete API objects. Claiming CPU limits are advisory only and never affect running containers fails because cgroup CPU quotas throttle runnable time under contention.
Exam caveat: raising limits without raising requests can still leave latency poor if the scheduler placed many low-request Pods on the same node; consider both fields for SLOs. Operational check: confirm limits.cpu in the Pod spec, inspect throttling metrics if available, increase CPU request and limit appropriately, and verify request latency recovers while the Pod remains Running without restarts.