IT 技書の森

Resource Quota

Kubernetes の Namespace ごとにリソース使用量の上限を設定し、リソースの公平な配分を保証する仕組み

Kubernetesインフラ

Resource Quota とは

Resource Quota は、Kubernetes の Namespace ごとに CPU、メモリ、Pod 数などのリソース使用量の上限を設定するリソースである。マルチテナント環境で、1 つのチームやアプリケーションがクラスター全体のリソースを占有するのを防ぐ。

物理的なサーバーリソースは有限だ。Resource Quota がなければ、あるチームのバッチ処理が CPU を 100% 消費し、他チームのサービスが応答不能になる事態が起こりうる。

Resource Quota の設定例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"        # CPU リクエストの合計上限: 10 コア
    requests.memory: 20Gi     # メモリリクエストの合計上限: 20GiB
    limits.cpu: "20"          # CPU リミットの合計上限: 20 コア
    limits.memory: 40Gi       # メモリリミットの合計上限: 40GiB
    pods: "50"                # Pod 数の上限
    services: "10"            # Service 数の上限
    persistentvolumeclaims: "5"  # PVC 数の上限

この設定では、team-a Namespace 内の全 Pod の CPU リクエスト合計が 10 コアを超える Pod の作成は拒否される。

Resource Quota と LimitRange の違い

この 2 つは混同されやすいが、制御の粒度が異なる。

観点 Resource Quota LimitRange
制御対象 Namespace 全体の合計 個々の Pod / Container
役割 チーム全体のリソース上限 1 つの Pod が使えるリソースの範囲
設定例 「Namespace 全体で CPU 10 コアまで」 「1 Pod あたり CPU 最大 2 コア」
デフォルト値 設定不可 Pod にデフォルトの requests/limits を付与

実務では両方を組み合わせて使う。Resource Quota で Namespace 全体の枠を決め、LimitRange で個々の Pod のデフォルト値と上限を設定する。

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
    - default:          # limits のデフォルト値
        cpu: "500m"
        memory: 512Mi
      defaultRequest:   # requests のデフォルト値
        cpu: "100m"
        memory: 128Mi
      max:              # 1 Container の上限
        cpu: "2"
        memory: 2Gi
      type: Container

Resource Quota が必要になる場面

  • マルチテナントクラスター: 複数チームが 1 つのクラスターを共有する場合、チームごとに Namespace を分け、Quota でリソースを公平に配分する
  • 開発環境のコスト制御: 開発環境で無制限にリソースを使われると、クラスターのコストが膨らむ。Quota で上限を設けて抑制する
  • 暴走 Pod の防止: バグで無限にレプリカが増える Pod がクラスター全体を圧迫するのを防ぐ

実務での設計指針

リソース配分の考え方

クラスター全体のリソースを 100% として、各 Namespace に配分する。

クラスター全体: CPU 100 コア, メモリ 400GiB
├── team-a (本番サービス):  CPU 40, メモリ 160GiB (40%)
├── team-b (本番サービス):  CPU 30, メモリ 120GiB (30%)
├── team-c (バッチ処理):    CPU 20, メモリ  80GiB (20%)
└── 予備 (バースト用):      CPU 10, メモリ  40GiB (10%)

合計を 100% にせず、10〜20% の予備を残すのがポイントだ。予備がないと、どの Namespace もバースト的な負荷増加に対応できない。

環境ごとの Quota 設計

環境 CPU requests メモリ requests Pod 数
prod 40 コア 160GiB 200
stg 10 コア 40GiB 50
dev 5 コア 20GiB 30

開発環境は本番の 1/8 程度に抑え、コストを最適化する。

よくある落とし穴

  • Quota を設定したのに requests/limits を書かない: Resource Quota が有効な Namespace では、Pod に requests/limits を明示しないと作成が拒否される。LimitRange でデフォルト値を設定しておかないと、開発者が混乱する
  • Quota の過小設定: 通常時は問題なくても、デプロイ時に新旧 Pod が同時に存在する (Rolling Update) ため、一時的にリソース使用量が増える。デプロイ時のオーバーヘッドを考慮した余裕が必要
  • 監視の欠如: Quota の使用率を監視していないと、上限に近づいていることに気づかず、突然 Pod が作成できなくなる。Prometheus + Grafana で kube_resourcequota メトリクスを監視する

Kubernetes 公式ドキュメントの「Resource Quotas」セクションが一次情報源であり、「Kubernetes in Action」(Marko Lukša 著) でも詳しく解説されている。

現場での応用を知るには関連書籍も役立つ。

関連用語