Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100001111000110111100111010000000000000011001010

Containers

wpisy (7)

  1. CPU w Kubernetes od kernela w górę12/12

    Anatomia problemu CPU: od zaniżonego requestu do p99 latency

    Jeden incydent od początku do końca: request 500m, brak limitu, brak throttlingu, a p99 rośnie z 35 do 180 ms. Cała ścieżka mechanizmu.

  2. CPU w Kubernetes od kernela w górę11/12

    Noisy neighbor i CPU overcommit: kiedy jeden Pod psuje drugi

    Overcommit działa, dopóki bursty nie są skorelowane. Zaniżony request to nie tylko placement - to także słabsza pozycja przy contention.

  3. CPU w Kubernetes od kernela w górę8/12

    Dlaczego 1 CPU nie oznacza jednego rdzenia

    CPU time i CPU placement to dwa różne mechanizmy. Limit mówi, ile wolno zużyć; affinity i cpuset mówią, gdzie task może się wykonywać.

  4. CPU w Kubernetes od kernela w górę7/12

    Requests, Limits i QoS: jak Kubernetes klasyfikuje Pody

    QoS class jest wynikiem konfiguracji requestów i limitów, nie osobnym mechanizmem przydzielania CPU. Guaranteed to nie dedykowany rdzeń.

  5. CPU w Kubernetes od kernela w górę4/12

    CPU Limits i throttling: co naprawdę robi limit CPU

    Limit nie przypina kontenera do rdzenia. Daje mu budżet CPU time rozliczany w okresach, a po jego wyczerpaniu kernel throttluje.

  6. CPU w Kubernetes od kernela w górę3/12

    CPU Requests w Kubernetes: czym naprawdę są

    Request to deklaracja zapotrzebowania, nie sufit. Wchodzi do placementu w kube-schedulerze i do wagi CPU po stronie kernela.

  7. seria · 12 części

    CPU w Kubernetes od kernela w górę

    Model CPU od dołu do góry: od runnable tasków i schedulera, przez cgroups, requests i limits, po throttling, contention, PSI i diagnostykę.