CPU/メモリの requests と limits の違いは何で、scheduling・eviction・QoS にどう影響しますか？

Question

IT Interview Practice · Accepted Answer

**requests** はコンテナが*保証される*量（scheduling に使われる）であり、**limits** はそれが超えてはならない*上限*（runtime で強制される）です。両者は合わさって、Pod がどこに配置されるか、逼迫下でどう throttle または kill されるか、そして Pod がどの **Quality of Service（QoS）**クラスを得るかを決めます。

## requests と limits

```text
REQUEST → the amount RESERVED for the container. The SCHEDULER uses the sum of
          requests to decide if a node has room. This is your guaranteed floor.
LIMIT   → the MAX the container may use. Enforced at runtime:
          CPU over limit    → THROTTLED (slowed down, not killed)
          memory over limit → OOM-KILLED (container terminated, then restarted)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 コア分、保証される
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 コアまでバーストでき、その後 throttle される
          memory: "512Mi"    # これを超えると → OOMKilled
```

## scheduling が requests をどう使うか

```text
Node has 4 CPU / 8Gi allocatable.
Scheduler sums the REQUESTS of Pods already placed; a new Pod fits only if its
requests still fit in what remains. (Limits are NOT used for placement.)
→ Set requests too low → node overcommitted, Pods fight for resources.
→ Set requests too high → wasted capacity, Pods stuck Pending (nothing fits).
```

## QoS クラス（メモリ逼迫下での eviction 順を決める）

```text
Guaranteed  → requests == limits for BOTH cpu & memory (every container)
              → last to be evicted (highest priority)
Burstable   → has requests but they are < limits (or partially set)
              → evicted after BestEffort
BestEffort  → no requests or limits at all
              → FIRST to be evicted when the node runs low on memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # 実際の CPU/メモリ使用量
kubectl describe node <node>               # 割り当て済みリソースと容量
```

## 実践的なガイダンス

```text
✓ Always set memory requests = limits for predictable, OOM-safe behavior on critical apps
✓ Set CPU requests to the steady-state need; CPU limits are often left off to allow bursting
✓ Right-size from real usage (kubectl top / metrics) — not guesses
✓ Use LimitRange / ResourceQuota to enforce sane defaults per namespace
```

## なぜ重要なのか

requests と limits は、Kubernetes が有限なノードのリソースを公平かつ予測可能に共有する手段であり、その区別と帰結を理解することは必須の性能・信頼性の知識です。中核の洞察は、両者が異なる目的を果たすことです。**requests** は保証された予約であり、**scheduler** が Pod を配置するのに使います（request を合算してノードに空きがあるか判断し、limit は無視する）。一方 **limits** は runtime の上限で、リソースごとに異なる形で強制されます — **CPU** limit を超えると **throttle**（減速）され、**メモリ** limit を超えるとコンテナが **OOM-kill** されて再起動されます。request を誤ると両側にコストが生じます。低すぎるとノードが overcommit され Pod が互いを飢えさせ、高すぎると容量が無駄になり何も収まらず Pod が Pending のまま座り続けます。3 つの **QoS クラス** — Guaranteed（requests が limits に等しい）、Burstable（requests が limits より小さい）、BestEffort（何も設定しない）— はメモリ逼迫下での eviction 順を決め、BestEffort が最初に、Guaranteed が最後に kill されます。これは重要な workload を守るために理解しておくべきことそのものです。実践的なガイダンス（重要なアプリではメモリの requests を limits と等しく設定し、`kubectl top` による実使用から適正サイズを求め、LimitRange/ResourceQuota でデフォルトを強制する）を知れば、これは理論から堅実なキャパシティプランニングへと変わります。リソースの設定ミスは、実際の cluster における不安定さ、無駄なコスト、Pending Pod の最も一般的な原因の 1 つであるため、requests・limits・QoS の習熟は、効率的で安定した Kubernetes workload を動かすための基礎です。

requests と limits

scheduling が requests をどう使うか

QoS クラス（メモリ逼迫下での eviction 順を決める）

実践的なガイダンス

なぜ重要なのか

関連する質問