Konrad Kowalski (rootsher)Principal Platform & Reliability Architect001000001101101100001010000000000110101110000100

Blog - Konrad Kowalski (rootsher)

posts (31)

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

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

  3. CPU in Kubernetes from the kernel up10/12

    How to debug CPU in Kubernetes without guessing

    Usage, throttling, contention and pressure are four different phenomena. A single CPU chart settles none of them - you need an order of operations.

  4. CPU in Kubernetes from the kernel up9/12

    NUMA, SMT and cache: when hardware topology starts to matter

    Two workloads can get the same CPU time and do different amounts of work. This is where the CPU abstraction ends and the physics of the machine begins.

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

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

  7. CPU in Kubernetes from the kernel up6/12

    PSI: how Linux measures real CPU pressure

    Utilisation says how much CPU a workload got. PSI measures the time it lost because it wanted to execute and had nothing to execute on.

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

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

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