В чём разница между requests и limits для CPU/памяти, и как они влияют на планирование, вытеснение и QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** — это то, что контейнеру *гарантировано* (используется для планирования); **limits** — это *потолок*, который он не может превысить (обеспечивается в рантайме). Вместе они определяют, где размещаются Pod, как их троттлят или убивают под нагрузкой и какой класс **Quality of Service (QoS)** получает Pod.

## Requests против limits

```text
REQUEST → объём, ЗАРЕЗЕРВИРОВАННЫЙ для контейнера. SCHEDULER использует сумму
          requests, чтобы решить, есть ли место на node. Это ваш гарантированный минимум.
LIMIT   → МАКСИМУМ, который контейнер может использовать. Обеспечивается в рантайме:
          CPU сверх лимита    → ТРОТТЛИТСЯ (замедляется, не убивается)
          память сверх лимита → OOM-KILLED (контейнер завершается, затем перезапускается)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 ядра, гарантировано
          memory: "256Mi"
        limits:
          cpu: "500m"        # может бёрстить до 0.5 ядра, затем троттлится
          memory: "512Mi"    # превышение → OOMKilled
```

## Как планирование использует requests

```text
Node имеет 4 CPU / 8Gi allocatable.
Scheduler суммирует REQUESTS уже размещённых Pod; новый Pod помещается, только если его
requests ещё вмещаются в остаток. (Limits НЕ используются для размещения.)
→ Слишком низкие requests → node переподписан, Pod дерутся за ресурсы.
→ Слишком высокие requests → впустую потраченная ёмкость, Pod застревают в Pending (ничего не влезает).
```

## Классы QoS (определяют порядок вытеснения при нехватке памяти)

```text
Guaranteed  → requests == limits для ОБОИХ cpu и memory (каждый контейнер)
              → вытесняется последним (высший приоритет)
Burstable   → есть requests, но они < limits (или заданы частично)
              → вытесняется после BestEffort
BestEffort  → вообще нет requests или limits
              → ПЕРВЫМ вытесняется, когда на node заканчивается память
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # фактическое использование CPU/памяти
kubectl describe node <node>               # выделенные ресурсы против ёмкости
```

## Практические рекомендации

```text
✓ Всегда ставьте memory requests = limits для предсказуемого, OOM-безопасного поведения критичных приложений
✓ Ставьте CPU requests под установившуюся потребность; CPU limits часто не задают, чтобы разрешить бёрст
✓ Подбирайте размер по реальному использованию (kubectl top / metrics) — не по догадкам
✓ Используйте LimitRange / ResourceQuota, чтобы навязать разумные умолчания на namespace
```

## Почему это важно

Requests и limits — это то, как Kubernetes честно и предсказуемо делит конечные ресурсы node, поэтому понимание различия и его последствий — существенное знание о производительности и надёжности. Ключевая мысль в том, что они служат разным целям: **requests** — это гарантированное резервирование, которое **scheduler** использует для размещения Pod (суммируя requests, чтобы решить, есть ли место на node, игнорируя limits), тогда как **limits** — это рантайм-потолок, обеспечиваемый по-разному для каждого ресурса: превышение лимита **CPU** приводит к **троттлингу** (замедлению), а превышение лимита **памяти** приводит к **OOM-kill** контейнера и его перезапуску. Ошибка в requests имеет реальную цену с обеих сторон: слишком низкие — и node становятся переподписанными, так что Pod голодают друг у друга; слишком высокие — и ёмкость тратится впустую, пока Pod сидят в Pending, потому что ничего не влезает. Три **класса QoS** — Guaranteed (requests равны limits), Burstable (requests ниже limits) и BestEffort (ничего не задано) — определяют порядок вытеснения при нехватке памяти, где BestEffort убивается первым, а Guaranteed последним, и это именно то, что нужно понимать для защиты критичных нагрузок. Знание практических рекомендаций (ставить memory requests равными limits для критичных приложений, подбирать размер по реальному использованию через `kubectl top`, навязывать умолчания через LimitRange/ResourceQuota) превращает это из теории в грамотное планирование ёмкости. Поскольку неправильная настройка ресурсов — одна из самых частых причин нестабильности, впустую потраченных денег и Pod в Pending в реальных кластерах, овладение requests, limits и QoS фундаментально для запуска эффективных, стабильных нагрузок на Kubernetes.

Requests против limits

Как планирование использует requests

Классы QoS (определяют порядок вытеснения при нехватке памяти)

Практические рекомендации

Почему это важно

Похожие вопросы