Konrad Kowalski (rootsher)Principal Platform & Reliability Architect001001101001100001010011110101101011110011001011

Resource Utilization

wpisy (6)

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

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

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

    CPU Contention: kiedy proces chce CPU, ale go nie dostaje

    Bez żadnego limitu proces może stać i czekać. Wystarczy, że runnable demand przekroczy dostępną capacity - i to widać dopiero w latency.

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

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

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