Kubernetes の CPU リソース (mCPU) と request/limit 設定完全ガイド

2026年5月16日

Contents

1 CPU リソースの単位と基本概念
- 1.1 CPU と millicore（mCPU）の意味
- 1.2 mCPU を活用した細かいリソース調整
2 request と limit の役割と QoS への影響
- 2.1 request/limit の基本動作と QoS クラス
- 2.2 リクエスト不足・リミット超過時の挙動
3 CPU とハードウェア（vCPU・物理コア）の関係
- 3.1 1 CPU が vCPU（論理コア）に対応する仕組みと注意点
- 3.2 ベンダー別 vCPU の特徴と落とし穴
4 実務での manifest 設定例とベストプラクティス
5 Autoscaling と CPU 設定の相互作用
- 5.1 HPA が利用する request の計算方式
- 5.2 Cluster Autoscaler との連携と最適化チェックリスト
  - 5.2.1 最適化チェックリスト
6 まとめ

スポンサードリンク

CPU リソースの単位と基本概念

Kubernetes ではコンテナが使用できる CPU を CPU と millicore（mCPU） の二つの単位で表現します。
本セクションではそれぞれの意味と、実務でどのように使い分けるべきかを簡潔に説明します。

CPU と millicore（mCPU）の意味

Kubernetes の cpu フィールドは 1 コア を 1 とし、1000 分の 1 を millicore (mCPU) として扱います。たとえば 500m は 0.5 CPU に相当し、同一ノード上に 500m の Pod が二つあれば合計で 1 CPU が割り当てられます。この細分化により、Pod が多数稼働する環境でも過不足のないリソース配分が可能です。公式ドキュメントは「要求された CPU が空き容量に収まる場合にのみスケジュールされる」ことを明記しています【Kubernetes Docs – Assign CPU Resources】。

mCPU を活用した細かいリソース調整

mCPU は 0.001 CPU 単位で指定できるため、負荷が小さいマイクロサービスでも正確にリクエストを記述できます。以下は requests と limits の組み合わせ例です。

Pod 名	requests	limits
app-a	250m	500m
app-b	750m	1

このように粒度の細かい設定を行うことで、ノード全体の CPU 利用率を高めつつ、過剰割り当てによるスロットリングや OOM のリスクを低減できます。

request と limit の役割と QoS への影響

request はスケジューラが Pod を配置する際の 最低保証、limit は実行時にコンテナが使用できる上限を表します。ここでは両者がどのように QoS クラスを決定し、クラスタ全体の安定性に影響するかを解説します。

request/limit の基本動作と QoS クラス

requests と limits の相対関係は以下の three‑class QoS にマッピングされます。
- Guaranteed：request == limit（すべてのコンテナで同一）
- Burstable：request < limit（少なくとも1つのコンテナで差がある）
- BestEffort：requests が未指定

Kubernetes は QoS に応じて OOM キラーの対象順位やスケジューラの優先度を変えるため、適切な設定は障害時のサービス継続性に直結します。以下は代表的な YAML 例です。

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: &quot;250m&quot;
      limits:
        cpu: &quot;750m&quot;

apiVersion: v1

kind: Pod

metadata:

name: burstable-pod

spec:

containers:

- name: app

image: nginx

resources:

requests:

cpu: "250m"

limits:

cpu: "750m"

リクエスト不足・リミット超過時の挙動

ノードに残り CPU が request 未満の場合、スケジューラは Pod の配置を保留します（スケジュール失敗）。一方、コンテナが limit を超えて CPU を要求すると CPU スロットリング が適用され、実行速度が抑制されます。これらの挙動は公式リソース管理ガイドラインでも確認できます【Kubernetes Docs – Resource Management for Pods and Containers】。

CPU とハードウェア（vCPU・物理コア）の関係

Kubernetes の 1 CPU はクラウド側の vCPU（論理コア） に対応しますが、プロバイダーごとに実装上の違いがあります。本セクションでは共通点と例外を整理し、設計時の注意点を示します。

1 CPU が vCPU（論理コア）に対応する仕組みと注意点

多くのパブリッククラウドは物理コアをハイパースレッディングで仮想化し、1 vCPU = 1 論理スレッド と定義しています。AWS、GCP、Azure の公式資料でも同様の記述があります（例：AWS の Compute Optimized Instances ドキュメント【AWS Docs – vCPU Definition】）。ただし、一部インスタンスタイプでは CPU クレジット制御 や Burstable プロファイル が付随し、実際に利用できる CPU 時間が変動する点に留意してください。

ベンダー別 vCPU の特徴と落とし穴

プロバイダー	代表的なインスタンスタイプ例	vCPU 定義・備考
AWS	t3.medium, c5.large	1 vCPU = 1 論理スレッド（ハイパースレッディング有）※CPU クレジット制御あり
GCP	n1-standard-2, e2-medium	1 vCPU = 1 論理コア（ハイパースレッディング有）
Azure	D2s_v3, B2ms	1 vCPU = 1 論理スレッド（ハイパースレッディング有）

同一クラスタ内で複数ベンダーのノードを混在させる場合、物理コア数と vCPU 数の比率が異なることから、リクエスト総量が実際のハードウェア容量を超えないように注意が必要です。

実務での manifest 設定例とベストプラクティス

YAML の resources フィールドに記述する request/limit が Kubernetes のリソース設計の中心です。ここでは具体的な書き方と、推奨設定指針の根拠を示します。

YAML での request/limit の記述方法

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: frontend
    image: nginx:latest
    resources:
      requests:
        cpu: &quot;250m&quot;   # 最低保証（スケジューラが考慮）
      limits:
        cpu: &quot;500m&quot;   # 上限（実行時に適用される上限値）

apiVersion: v1

kind: Pod

metadata:

name: web-app

spec:

containers:

- name: frontend

image: nginx:latest

resources:

requests:

cpu: "250m" # 最低保証（スケジューラが考慮）

limits:

cpu: "500m" # 上限（実行時に適用される上限値）

requests と limits を明示的に設定することで、Pod は Burstable QoS となり、HPA の計算基準としても利用可能です。

推奨設定指針（70〜80% / 120%）の根拠

リクエストは実測負荷の 70〜80 % を目安に
Kubernetes の公式ベストプラクティスでは、「リソースリクエストは平均使用率よりやや余裕を持たせる」 と推奨されています【Kubernetes Docs – Setting Requests and Limits】。実務では負荷テストで測定した CPU 平均使用率が 300 m の場合、request: 350m（≈ 80 %）と設定するとスロットリングのリスクを抑えられます。
リミットはピーク時の 120 % 程度に抑える
GKE や EKS のパフォーマンスガイドでは、「リミットは最大負荷の 1.2 倍程度まで」 とすることで、突発的なスパイクに耐えつつノード過負荷を防げると述べられています【Google Cloud – Best Practices for Resource Limits】。

このように、実測データ＋公式ガイドライン に基づく数値設定が信頼性の高い根拠となります。

設定ミスが招く過不足リスク

過小な request：スケジューラが Pod を配置できず、デプロイ遅延や HPA の誤判定が発生。
過大な limit：CPU スロットリングが頻繁に起き、レイテンシ増加やコスト上昇の要因になる。

定期的にメトリクスを確認し、request と limit を実測負荷に合わせて調整することが重要です。

Autoscaling と CPU 設定の相互作用

CPU の request/limit は Horizontal Pod Autoscaler (HPA) と Cluster Autoscaler の挙動に直接影響します。以下ではその関係と、実務で活用できるチェックリストを示します。

HPA が利用する request の計算方式

HPA は metrics.cpu.utilization（CPU 使用率）を評価するとき、Pod の request 値を基準にパーセンテージを算出します。たとえば request: 200m の Pod が 80 %（160 m）で動作している場合、HPA は「利用率 80 %」として判断し、設定した閾値を超えるとスケールアウトがトリガーされます。逆に request を過大に設定すると同じ実負荷でも利用率が低く見積もられ、スケールアウトが遅れることがあります【Kubernetes Docs – Horizontal Pod Autoscaling】。

Cluster Autoscaler との連携と最適化チェックリスト

Cluster Autoscaler はノードの 未使用 CPU が一定以下になると余剰ノードを削除し、逆に request 合計がノード容量を超える Pod が残っている場合は新規ノードを追加します。したがって request の過不足はクラスタコストに直結します。

最適化チェックリスト

項目	確認方法	推奨アクション
request が実測負荷の 70〜80 % 前後か	Prometheus の `container_cpu_usage_seconds_total` を集計し平均を算出	必要に応じて request を増減
limit がピーク負荷の 120 % 以下か	負荷テスト結果（最大 CPU 使用率）と比較	超えていれば下げ、スロットリング防止
QoS クラスが期待通りか	`kubectl get pod -o=jsonpath="{.items[*].status.qosClass}"` で確認	Guaranteed が必要なら request と limit を同一に
HPA の目標利用率と実測値の乖離	`kubectl top hpa` で現在の利用率を取得	request 調整後、再評価
Cluster Autoscaler の頻繁なスケールが無いか	クラスタイベントログ (`kube-system`) を監視	ノードサイズ・request 設定を見直す

上記項目を 定期的（例：月次）にレビュー することで、CPU 設定とオートスケーリングの整合性が保たれ、コスト最適化とパフォーマンス安定性を同時に実現できます。

まとめ

CPU は CPU と millicore（mCPU） の二単位で表現し、細かな粒度でリソースを割り当てられる。
request と limit が QoS クラスとスケジューラの振る舞いを決定し、過不足は直接サービス可用性に影響する。
1 CPU は多くの場合 vCPU（論理コア） に対応するが、プロバイダー固有の特性（クレジット制御やハイパースレッディング）を把握しておく必要がある。
設定指針は 実測負荷の 70〜80 % を request、120 % 以下を limit とし、公式ドキュメントとベンチマーク結果に基づいて根拠付ける。
HPA・Cluster Autoscaler は request の正確さに依存するため、メトリクス収集と定期的なチェックリスト活用が不可欠。

これらのベストプラクティスを継続的に適用すれば、Kubernetes クラスタの CPU 資源利用効率が向上し、サービスの安定運用とコスト最適化を同時に実現できます。