Kubernetes
wpisy (9)
- 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.
- 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.
- CPU w Kubernetes od kernela w górę10/12
Jak debugować CPU w Kubernetes bez zgadywania
Usage, throttling, contention i pressure to cztery różne zjawiska. Jeden wykres CPU nie rozstrzyga żadnego z nich - potrzebna jest kolejność.
- 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ć.
- 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ń.
- CPU w Kubernetes od kernela w górę6/12
PSI: jak Linux mierzy realny CPU pressure
Utilization mówi, ile CPU workload dostał. PSI mierzy czas, który stracił, bo chciał się wykonywać i nie miał na czym.
- 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.
- 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.
- 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ę.