ミリコア
- 入力
- 500m
- 結果
- 0.5 コア
1000m が 1 コアです。request が 100m なら、スケジューラーはコアの 10 分の 1 を確保します。
Kubernetes リソース計算機
ミリコアとメモリ接尾辞を変換し、レプリカ数で掛け合わせ、kubelet が付ける QoS クラスを表示します。接尾辞の比較表は Mi と M の差を目に見える形にします。静かな無駄遣いと突然の OOMKill はここから生まれます。
サンプルワークロード
QoS クラス: BurstableCPU limit は request の 5.0 倍メモリ limit は request の 2.0 倍
| 1 ポッドあたり | × レプリカ 3 個 | |
|---|---|---|
| CPU request | 0.1 | 0.3 |
| CPU limit | 0.5 | 1.5 |
| メモリ request | 128Mi | 384Mi |
| メモリ limit | 256Mi | 768Mi |
マニフェスト断片
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
# 3 replicas require
# cpu 0.3 cores requested, 1.5 at the limit
# memory 384Mi requested, 768Mi at the limitMi は M ではありません
Kubernetes は 2 進接尾辞と 10 進接尾辞の両方を受け付けますが、大きさは同じではありません。
| 接尾辞 | バイト | 接尾辞 | バイト | 差 |
|---|---|---|---|---|
| 1Ki | 1,024 | 1k | 1,000 | +2.4% |
| 1Mi | 1,048,576 | 1M | 1,000,000 | +4.9% |
| 1Gi | 1,073,741,824 | 1G | 1,000,000,000 | +7.4% |
つまり 1G は 1G、1Gi は 1Gi で、約 7% の差があります。
すべてブラウザ内で処理されます. このページは静的ファイルです。入力した内容はタブの中だけに留まり、サーバーへ送信されることはなく、閉じれば消えます。実際のトークンや設定を貼り付けても安全です。
こんなときに使います
- Deployment のサイズを決めるとき、レプリカ数がクラスター容量をどれだけ占めるか知りたいとき。
- Guaranteed にしたつもりが Burstable になっている理由を調べるとき。
- docker-compose のメモリ制限をマニフェストが期待する単位に置き換えるとき。
実例
コストに響く接尾辞
- 入力
- 1000M と 1Gi
- 結果
- 1,000,000,000 と 1,073,741,824 バイト
Mi のつもりで M と書くと、意図より約 7% 少ないメモリになります。
Guaranteed QoS
- 入力
- requests == limits
- 結果
- Guaranteed
CPU とメモリの request が limit と正確に一致する場合だけです。それ以外は Burstable で、逼迫時により早く退避されます。
よくある間違い
Mi のつもりで M と書く
512M は 512,000,000 バイト、512Mi は 536,870,912 バイトです。どちらも有効なマニフェストなので警告は出ず、ポッドだけが数字の見た目より少ないメモリを受け取ります。
CPU limit を request よりはるかに大きくする
limit が request の何倍もあると、ポッドは一気に伸びたあとノードが混んだ瞬間に強く throttle されます。アプリのバグに見えるレイテンシのスパイクが、実は CFS throttling だったという例は多いです。
request をまったく書かない
request のないポッドは BestEffort となり、ノードが逼迫したとき真っ先に退避されます。スケジューラーに判断材料も与えないため、ノードの埋まり方も偏ります。
よくある質問
request と limit の違いは何ですか？
request はポッドを配置するときにスケジューラーが確保する量、limit は実行時にカーネルが強制する上限です。request はどこに載るかを、limit はいつ throttle されるか OOMKill されるかを決めます。
QoS クラスはどう決まりますか？
すべてのコンテナで CPU とメモリの request が limit と等しければ Guaranteed、request も limit もなければ BestEffort、その中間はすべて Burstable です。退避がこの順で起こるため重要です。
CPU limit は設定すべきですか？
メモリ limit だけ設定して CPU は開けておくチームが多いです。メモリ limit 超過はコンテナを停止させますが、CPU limit 超過は throttle にとどまり、空いている容量を使わせるよりレイテンシの面で不利になることが多いためです。