Mój kolega Aleksander Roszig opublikował solidny wpis techniczny, który warto przeczytać, jeśli pracujesz z Kubernetes — niezależnie od poziomu doświadczenia.
Temat pozornie podstawowy: CPU request i CPU limit. W praktyce jeden z najczęstszych źródeł problemów z wydajnością w produkcyjnych klastrach.
Aleksander nie poprzestaje na "ustaw requesty i limity, bo tak trzeba" — schodzi poziom niżej i tłumaczy jak to naprawdę działa: cgroups v2, kontroler CPU, model wag (weight), model pasma (bandwidth/quota), funkcje MilliCPUToShares() i MilliCPUToQuota() prosto z kodu Kubernetesa. Wchodzi też w scheduler Linuksa, w tym EEVDF obecny już w nowszych dystrybucjach (Ubuntu 24.04+, Amazon Linux 2023, RHEL 10).
Kilka rzeczy, które warto zapamiętać z tego artykułu:
- Request to nie rezerwacja, lecz waga w rywalizacji o CPU — jeśli inny pod nie używa swoich zasobów, Twój pod może wziąć więcej.
- Limit to twardy sufit realizowany przez quota/throttling — i może szkodzić latencji bardziej niż brak limitu.
- Throttling nie zawsze jest widoczny gołym okiem — trzeba patrzeć na metryki
container_cpu_cfs_throttled_periods_totalicontainer_cpu_cfs_throttled_seconds_total. - Są scenariusze, gdzie CPU limit ma sens (multi-tenant, nieufne workloady, kontrola kosztów) — i takie, gdzie go nie potrzebujesz.
To artykuł, który powinien być lekturą obowiązkową przed każdym przeglądem konfiguracji zasobów w klastrze. 👉 Cały wpis znajdziesz tutaj: https://roszigit.com/blog/kubernetes-cpu-request-i-limit/ Zapowiedź od Aleksandra: w kolejnej części omówi zarządzanie pamięcią (memory request i limit) — warto śledzić.