KubernetesでCPU limitsを使うのはやめよう：アプリが遅くなりコストが膨らむ
For the love of god stop using CPU limits in Kubernetes
KubernetesのCPU limitsは、ノードに空きCPUがあってもアプリを毎秒何度もフリーズさせ、レイテンシを悪化させ、コスト増につながる。同じアプリをCPU limitあり・なしで比較した実証結果によると、limitなしではテールレイテンシが維持され、CPU負荷の高い起動処理が約2倍速くなる。CPU requestsはアプリのシェアを保証するため、limitsの代わりにrequestsを維持し、memory limitsはノード保護のため残すべき。本分析では、スロットリングの仕組み、CFSの公平な共有、ノイジーネイバー問題、コストモデルなどを詳説する。
CPU limitsは、ノードに空きCPUがある場合でも、アプリを1秒間に何度もフリーズさせる。
HNでの議論
43- conradludgate
CPU limitsがパフォーマンスを悪化させるという点には同意するが、この記事の論旨はあまり説得力がないと思う（そしてLLMっぽい言い回しが多くて読む気が削がれる）。CPU requestが保証だと言及しているが、それはどうやって強制されるのか？32コアのマシンで32個のポッドがそれぞれ1cpuを要求している場合、そのうちの1つが不当なシェアを使うのを何が防ぐのか？Linuxスケジューラに頼っているだけだと思う。16個のポッドが1cpu、1個のポッドが16cpuの場合、Linuxスケジューラは16cpuのポッドに多くの時間を与えることを保証するのか？それともcgroupsに戻るのか。
- sjbzbeiks
これは紙面上では常に良さそうに聞こえ、非常に一般的な言説だが、実際のプロダクションのエスカレーションに直面すると、多くのソフトウェアがスレッドプールの自動設定や、いくつかのランタイム（例えばGoやJava、少なくとも記事で言及されている.NET）の設定をlimitsに依存しているという非常に一般的な問題がある。確かに通常はフラグで設定できるが、人々がそれを知り、伝え、強制する必要がある。要するに、limitsが自動的に設定してくれていることを、アドホックな設定で置き換えることになる。つまり、これは全チームが必要な情報を完璧に伝達できる環境を前提にしている。実際には、スレッドプールが4つではなく256スレッドで実行されることで、エッジケースでワークロードが劣化する。
- dwedge
プロンプトをくれ
- iljanevo
KubernetesのCPU limitsはメモリの問題やOOMKillも引き起こすことがある。メモリリークのように見えるが、通常の修正はメモリ制限を増やすことだが、実際の原因はCPU limitである。簡単な証明はこちら：https://github.com/inevolin/k8s-cpu-limits-analyzed#how-cpu-...
- aairey
これがどうして「ニュース」なのか？2018年にはすでにそうだった。また、スケジューラのオーバーヘッドについても言及がない。そして、メンテナンスのオーバーヘッドが最悪だ。