Tech Learning Daily

requests ―― スケジューラへの「保証」申告

requests は、Pod をどのノードに配置するかを kube-scheduler が判断するときに使う値だ。あるノードに Pod を置いてよいかは、そのノードの空きリソースが Pod の requests 合計を上回っているかで決まる。kubelet はこの量を「最低限このコンテナのために確保する」量として扱うが、実際にコンテナが使ってよい上限を決めるものではない。

なお limits だけを書いて requests を省略すると、Kubernetes はその limits の値をそのまま requests としてコピーする。「limits さえ書けばスケジューリングには影響しない」という理解は誤りで、結果的に requests = limits の Pod としてスケジュールされることになる。

CPU limit を超えると何が起きるか ―― CFS スロットリング

CPU の limits を超えるとどうなるか。答えは「殺されない。ただし細切れに間引かれる」だ。Linux カーネルは CFS（Completely Fair Scheduler）という仕組みで CPU 時間を一定の周期（cfs_period_us、既定で 100ms）に区切り、その周期内でコンテナの cgroup が使ってよい CPU 時間の上限（cfs_quota_us）を「limit × 周期」で計算する。たとえば limit を 500m（0.5 CPU）に設定すると、1 周期あたり 50ms しか実行が許されない。

cfs_period_us = 100000（既定 100ms）
CPU limit 500m → quota 50ms/period

┌── 1 period（100ms）──┐
│■■■■■■■■■■□□□□□□□□□□│
└──────────────────────┘
 使用 50ms      throttle 50ms

50ms を使い切ると、そのコンテナ内の全プロセスは次の周期が始まるまで実行キューから外され、待たされる。これがスロットリングであり、プロセス自体は生きたまま止まっているだけなので Pod の再起動やイベントは発生しない。だが体感としては「急に応答が固まる」形でレイテンシに直結する。

メモリ limit を超えると何が起きるか ―― OOM Killer

メモリの limits を超えた場合はまったく別の仕組みが働く。コンテナが使うメモリは cgroup によって計測されており、その cgroup の使用量が limits を超えると、Linux カーネルの OOM Killer（Out Of Memory Killer）が介入し、cgroup 内のプロセスを SIGKILL で強制終了する。CPU と違って「待てば戻ってくる」性質のものではなく、プロセスはその場で殺される。

kubelet はこの終了を検知すると、コンテナステータスの reason を OOMKilled、exitCode を 137（SIGKILL によって終了したことを示す値）として記録し、Pod の restartPolicy に従ってコンテナを再起動する。再起動を繰り返す場合、kubectl get pods の RESTARTS が増え続けているのに気づくはずだ。CPU が「絞られる」のに対し、メモリは「殺されて作り直される」——これが冒頭の問いへの答えである。

QoS クラス ―― ノード全体が逼迫したときの優先順位

requests と limits の関係は、ノード全体のメモリが逼迫したときの挙動にも影響する。requests と limits が全コンテナで一致している Pod は Guaranteed、どちらか一部でも設定されていれば Burstable、まったく設定がなければ BestEffort という QoS クラスに分類される。ノードのメモリ不足で kubelet が Pod を退避（eviction）させる必要が出たとき、真っ先に狙われるのは BestEffort、続いて requests を超過している Burstable で、Guaranteed は最後まで残される。

つまり OOMKilled は「その Pod 自身の cgroup が自分の limits を超えた」場合に起きる話であり、eviction は「ノード全体が足りない」場合に kubelet が能動的に間引く話だ。両者は別の仕組みだが、どちらも requests / limits の設定次第で自分の Pod がどれだけ優先的に守られるかが決まる、という点は共通している。