CPU w Kubernetes od kernela w górę

CPU w Kubernetes wygląda prosto tylko na poziomie YAML-a.

resources:
  requests:
    cpu: 500m
  limits:
    cpu: "1"

Dopóki wszystko działa, te dwie wartości wydają się wystarczające.

Problemy zaczynają się wtedy, gdy pojawia się throttling, rośnie p99, workload używa mniej CPU niż oczekiwaliśmy, node wygląda na niedociążony, a aplikacja mimo to czeka na procesor.

Żeby poprawnie diagnozować takie przypadki, trzeba zejść niżej niż Kubernetes.

Bo ostatecznie:

Pod
  |
  v
cgroup
  |
  v
Linux scheduler
  |
  v
logical CPU
  |
  v
physical core

Kubernetes nie wykonuje instrukcji aplikacji, nie przydziela threadom czasu CPU i nie implementuje schedulingu procesora.

Te mechanizmy znajdują się niżej - w kernelu Linuksa i samym hardware.

Ta seria buduje model CPU właśnie od dołu do góry: od runnable tasków i schedulera, przez cgroups, requests i limits, aż po throttling, contention, PSI, topology i praktyczną diagnostykę.

Celem nie jest nauczenie Kubernetes od podstaw.

Celem jest zrozumienie, co naprawdę dzieje się pomiędzy:

requests.cpu: 500m

a momentem, w którym konkretny thread faktycznie wykonuje instrukcje na procesorze.

Bo dopiero wtedy można poprawnie rozróżnić:

wysokie CPU usage

CPU throttling

CPU contention

CPU pressure

zły resource sizing

zły placement

i przestać traktować:

CPU = 80%

jak diagnozę.

To tylko jedna liczba opisująca jedną warstwę znacznie większego mechanizmu.

Jeżeli kiedykolwiek widziałeś Pod z pozornie poprawnym CPU usage, brak throttlingu i jednocześnie rosnące p99, ta seria jest właśnie o tym, jak przejść od takiego symptomu do konkretnego mechanizmu w kernelu.

Bez zgadywania. Bez sprowadzania wszystkiego do „za mało CPU”. Bez traktowania requests i limits jak magicznych pól w YAML-u.

Zaczynamy od najniższej warstwy: jak Linux naprawdę daje procesowi CPU.