Chapter 2 · Practice 3 of 5
Be deliberate about CPU limits
Why it matters
CPU is different from memory. A container that reaches its CPU limit is throttled, not killed: the kernel slows it down. That protects neighbours, but it also means a container can be slow while the node has idle CPU sitting next to it.
The security checklist says CPU limits might be set on sensitive workloads and notes that they throttle usage and can affect autoscaling. That is the right framing: they are a tool, not a default.
| Situation | Reasonable choice |
|---|---|
| Latency-sensitive service on a shared cluster | CPU request, no CPU limit or a generous one |
| Batch job that should not starve others | CPU limit close to its request |
| Multi-tenant cluster with untrusted workloads | CPU limits enforced by policy |
Whatever you pick, always set the CPU request, because that is what the scheduler and the autoscaler use.
To check for throttling, look at the container_cpu_cfs_throttled_periods_total metric from cAdvisor, if your monitoring collects it. Steady throttling on a latency-sensitive service is a sign the limit is too low.
Avoid
- Copying the same tight CPU limit onto every container by habit
- Leaving the CPU request unset because there is no limit