Kubernetes の CPU・mCPU と vCPU の関係と設定ガイド

Kubernetes が扱う CPU 単位と公式定義

1️⃣ CPU の基本概念

ポイント
Kubernetes のリソース項目 cpu は、クラウド側で呼ばれる vCPU（＝ハイパースレッド）と 1:1 にマッピングされます。したがって「1 CPU = 1 コア」ではなく 「1 CPU = 1 vCPU (論理コア)」 と考えてください。

参考

• Kubernetes 公式ドキュメント – 「コンテナおよび Pod への CPU リソースの割り当て」[^1]

2️⃣ ミリCPU（mCPU）とは

Kubernetes は整数で管理できるよう、CPU を 1000 分割 した単位 ミリCPU (m) を導入しています。

計算式

ポイント
250m のように千分の一単位で指定できるため、細かいリソース調整が可能です。設定時は必ず「/1000」換算を意識しましょう。

参考

• Kubernetes 公式ドキュメント – 「CPU リソース」[^1]

3️⃣ 物理コア・vCPU・ハイパースレッドの違いと主要クラウドベンダーの実装

ポイント
多くのクラウドは「1 vCPU = 1 ハイパースレッド」＝論理コアとして提供しています。物理コア数は半分になることが多いので、Kubernetes のリソース設計では vCPU（論理コア） を基準に考える必要があります。

参考

• AWS – EC2 インスタンスの vCPU 定義[^2]
• GCP – Compute Engine の CPU 構成[^3]
• Azure – VM の CPU と vCPU の関係[^4]

4️⃣ requests と limits の役割とスケジューラへの影響

設定例

• シナリオ A：実際の使用率が常に 0.2 vCPU → requests が余裕あり、スケジューラは問題なく配置
• シナリオ B：負荷が急増し 1.2 vCPU を要求 → cgroup が上限（limits: 1）を超える分を制御し、CPU スロットリングが発生

ポイント
requests は「予約」、limits は「上限」と覚えておくと、リソース競合やスロットリングの原因がすぐに特定できます。

参考

• Kubernetes 公式 – 「CPU リクエストとリミット」[^1]
• Linux cgroup の CPU 制御（公式マニュアル）[^5]

5️⃣ マルチコアノードでの最適化ベストプラクティス

ポイント
「余裕率 × QoS の組み合わせ」でスパイク時のリソース確保ができ、ノード全体のスループットが向上します。定期的にモニタリングデータをレビューし、requests/limits をチューニングするサイクルを確立しましょう。

参考

• Kubernetes 公式 – 「Quality of Service（QoS）クラス」[^6]
• Sysdig ブログ – 「Kubernetes CPU リクエスト & リミット とオートスケーリング」[^7]

まとめ

1. CPU の単位は vCPU（ハイパースレッド）。1 = 1000m = 1 論理コア
2. mCPU (millicpu) は千分の一単位で、細かい割り当てが可能
3. クラウドベンダーは基本的に vCPU = ハイパースレッド を提供。物理コア数とは別に考える必要があります（例：AWS t3.large は 2 vCPU）
4. requests はスケジューラが参照する保証リソース、limits は実行時上限であり超過すると cgroup による CPU スロットリング が発生
5. マルチコアノードでは 余裕率 70 % 前後、適切な QoS 設定、Pod の分散配置 を意識したリソース設計がベストプラクティス

次のステップ
自クラスターの各 Pod に対して cpu.requests と cpu.limits が公式ドキュメントに沿って設定されているか確認し、余裕率や QoS クラスを見直してください。さらに詳しい最適化手順は当サイトの「Kubernetes リソース最適化完全ガイド」をご参照ください。

参考文献