Contents
スポンサードリンク
Kubernetes が扱う CPU 単位と公式定義
1️⃣ CPU の基本概念
| 表記 | 意味 |
|---|---|
1 / 1000m |
1 vCPU（論理コア） ＝ 1 ハイパースレッド |
250m |
0.25 vCPU（1/4 論理コア） |
500m |
0.5 vCPU（半分の論理コア） |
ポイント
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 |
0.25 vCPU |
500m |
0.5 vCPU |
1500m |
1.5 vCPU |
計算式
|
1 2 3 |
CPU (vCPU) = mCPU / 1000 mCPU = CPU × 1000 |
ポイント
250mのように千分の一単位で指定できるため、細かいリソース調整が可能です。設定時は必ず「/1000」換算を意識しましょう。
参考
- Kubernetes 公式ドキュメント – 「CPU リソース」[^1]
3️⃣ 物理コア・vCPU・ハイパースレッドの違いと主要クラウドベンダーの実装
| ベンダー | インスタンスタイプ例 | 物理コア数 | vCPU（論理コア） | 補足 |
|---|---|---|---|---|
| AWS | t3.large |
2 | 2 vCPU | 1 vCPU = 1 ハイパースレッド。インスタンスタイプにより 1 vCPU が 1 つの物理コアのハイパースレッド と定義されます（公式ドキュメント参照） |
| GCP | n1-standard-4 |
2 | 4 vCPU | 1 vCPU = 1 ハイパースレッド。Intel/AMD CPU の場合、2 スレッドが 1 物理コアに対応 |
| Azure | Standard_D2s_v3 |
2 | 4 vCPU | 1 vCPU = 1 ハイパースレッド（公式情報） |
ポイント
多くのクラウドは「1 vCPU = 1 ハイパースレッド」＝論理コアとして提供しています。物理コア数は半分になることが多いので、Kubernetes のリソース設計では vCPU（論理コア） を基準に考える必要があります。
参考
- AWS – EC2 インスタンスの vCPU 定義[^2]
- GCP – Compute Engine の CPU 構成[^3]
- Azure – VM の CPU と vCPU の関係[^4]
4️⃣ requests と limits の役割とスケジューラへの影響
| 項目 | 意味 |
|---|---|
| requests | スケジューラが Pod 配置時に参照する「保証リソース」 ノードの空き vCPU が requests 以上あるかで配置可否を判断 |
| limits | コンテナ実行時の上限 超過すると Linux cgroup が CPU シェアを制限し、スロットリングが発生 |
設定例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: v1 kind: Pod metadata: name: cpu-demo spec: containers: - name: app image: nginx:latest resources: requests: cpu: "250m" # 0.25 vCPU を保証 limits: cpu: "1" # 最大 1 vCPU まで使用可 |
- シナリオ A：実際の使用率が常に 0.2 vCPU →
requestsが余裕あり、スケジューラは問題なく配置 - シナリオ B：負荷が急増し 1.2 vCPU を要求 → cgroup が上限（
limits: 1）を超える分を制御し、CPU スロットリングが発生
ポイント
requestsは「予約」、limitsは「上限」と覚えておくと、リソース競合やスロットリングの原因がすぐに特定できます。
参考
- Kubernetes 公式 – 「CPU リクエストとリミット」[^1]
- Linux cgroup の CPU 制御（公式マニュアル）[^5]
5️⃣ マルチコアノードでの最適化ベストプラクティス
| 推奨項目 | 内容 |
|---|---|
| 余裕率 | ノード総 vCPU の 70 %〜80 % まで requests を合計。残りはスパイク時に確保できるバッファとして確保 |
| requests / limits 比率 | requests ≈ 30‑50 % × limits（例：250m → 500m）で Burstable QoS を意識 |
| QoS クラスの選択 | - Guaranteed : requests = limits → 高優先度ワークロード向け- Burstable : 上記比率で設定 → 通常ワークロード |
| Pod の分散配置 | topologySpreadConstraints や affinity/anti‑affinity を活用し、ノード間に均等に Pod を配置 |
| モニタリング | kubectl top pod、Prometheus + Grafana、Sysdig などで実使用率を可視化し、過剰予約や不足を検出・調整 |
ポイント
「余裕率 × QoS の組み合わせ」でスパイク時のリソース確保ができ、ノード全体のスループットが向上します。定期的にモニタリングデータをレビューし、requests/limitsをチューニングするサイクルを確立しましょう。
参考
- Kubernetes 公式 – 「Quality of Service（QoS）クラス」[^6]
- Sysdig ブログ – 「Kubernetes CPU リクエスト & リミット とオートスケーリング」[^7]
まとめ
- CPU の単位は vCPU（ハイパースレッド）。
1=1000m= 1 論理コア - mCPU (millicpu) は千分の一単位で、細かい割り当てが可能
- クラウドベンダーは基本的に vCPU = ハイパースレッド を提供。物理コア数とは別に考える必要があります（例：AWS
t3.largeは 2 vCPU） requestsはスケジューラが参照する保証リソース、limitsは実行時上限であり超過すると cgroup による CPU スロットリング が発生- マルチコアノードでは 余裕率 70 % 前後、適切な QoS 設定、Pod の分散配置 を意識したリソース設計がベストプラクティス
次のステップ
自クラスターの各 Pod に対してcpu.requestsとcpu.limitsが公式ドキュメントに沿って設定されているか確認し、余裕率や QoS クラスを見直してください。さらに詳しい最適化手順は当サイトの「Kubernetes リソース最適化完全ガイド」をご参照ください。
参考文献
| 番号 | タイトル・リンク |
|---|---|
| [^1] | 「コンテナおよび Pod への CPU リソースの割り当て」 https://kubernetes.io/ja/docs/tasks/configure-pod-container/assign-cpu-resource/ |
| [^2] | AWS – EC2 インスタンスにおける vCPU の定義 https://aws.amazon.com/jp/ec2/faqs/#What_is_a_vCPU |
| [^3] | GCP – Compute Engine の CPU 構成 https://cloud.google.com/compute/docs/cpu-platforms?hl=ja |
| [^4] | Azure – 仮想マシンの CPU と vCPU の関係 https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes |
| [^5] | Linux cgroup v2 – CPU コントロール https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu-controller |
| [^6] | Kubernetes – Quality of Service（QoS）クラス https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-of-service-pod/ |
| [^7] | Sysdig Blog – 「Kubernetes CPU リクエスト & リミット とオートスケーリング」 https://sysdig.com/blog/kubernetes-cpu-requests-limits-autoscaling/ |
スポンサードリンク