Containers
posts (7)
- CPU in Kubernetes from the kernel up12/12
Anatomy of a CPU problem: from an understated request to p99 latency
One incident end to end: a 500m request, no limit, no throttling, and p99 climbing from 35 to 180 ms. The whole path of the mechanism.
- CPU in Kubernetes from the kernel up11/12
Noisy neighbor and CPU overcommit: when one Pod breaks another
Overcommit works until bursts become correlated. An understated request is not only about placement - it is a weaker position under contention.
- CPU in Kubernetes from the kernel up8/12
Why 1 CPU does not mean one core
CPU time and CPU placement are two different mechanisms. A limit says how much you may consume; affinity and cpuset say where a task may execute.
- CPU in Kubernetes from the kernel up7/12
Requests, Limits and QoS: how Kubernetes classifies Pods
A QoS class is the result of how requests and limits are configured, not a separate CPU allocation mechanism. Guaranteed is not a dedicated core.
- CPU in Kubernetes from the kernel up4/12
CPU Limits and throttling: what a CPU limit really does
A limit does not pin a container to a core. It gives it a CPU-time budget accounted per period, and once that runs out the kernel throttles it.
- CPU in Kubernetes from the kernel up3/12
CPU Requests in Kubernetes: what they really are
A request is a declaration of demand, not a ceiling. It feeds placement in kube-scheduler and CPU weight on the kernel side.
- series · 12 parts
CPU in Kubernetes from the kernel up
A CPU model built bottom-up: from runnable tasks and the scheduler, through cgroups, requests and limits, to throttling, contention, PSI and diagnostics.