Konrad Kowalski (rootsher)Principal Platform & Reliability Architect111011101101011011000111000110100001110011001100

Resource Utilization

posts (6)

  1. 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.

  2. 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.

  3. CPU in Kubernetes from the kernel up5/12

    CPU Contention: when a process wants CPU and does not get it

    With no limit at all a process can sit and wait. All it takes is runnable demand exceeding available capacity - and you only see it in latency.

  4. 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.

  5. 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.

  6. 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.