Qual a diferença entre CPU/memory requests e limits, e como eles afetam scheduling, eviction e QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** são o que um container tem *garantido* (usado para scheduling); **limits** são o *teto* que ele não pode ultrapassar (imposto em runtime). Juntos, eles determinam onde os Pods são posicionados, como são throttled ou mortos sob pressão, e qual classe de **Quality of Service (QoS)** um Pod recebe.

## Requests vs limits

```text
REQUEST → a quantidade RESERVADA para o container. O SCHEDULER usa a soma dos
          requests para decidir se um node tem espaço. Este é seu piso garantido.
LIMIT   → o MÁXIMO que o container pode usar. Imposto em runtime:
          CPU acima do limit    → THROTTLED (desacelerado, não morto)
          memory acima do limit → OOM-KILLED (container terminado, depois reiniciado)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 de um core, garantido
          memory: "256Mi"
        limits:
          cpu: "500m"        # pode dar burst até 0.5 core, depois throttled
          memory: "512Mi"    # exceder isto → OOMKilled
```

## Como o scheduling usa os requests

```text
O node tem 4 CPU / 8Gi alocáveis.
O scheduler soma os REQUESTS dos Pods já posicionados; um novo Pod só cabe se seus
requests ainda couberem no que resta. (Limits NÃO são usados para posicionamento.)
→ Requests baixos demais → node em overcommit, Pods brigam por recursos.
→ Requests altos demais → capacidade desperdiçada, Pods presos em Pending (nada cabe).
```

## Classes de QoS (decidem a ordem de eviction sob pressão de memória)

```text
Guaranteed  → requests == limits para AMBOS cpu & memory (todo container)
              → o último a sofrer eviction (prioridade mais alta)
Burstable   → tem requests mas são < limits (ou parcialmente definidos)
              → sofre eviction depois do BestEffort
BestEffort  → nenhum request ou limit definido
              → o PRIMEIRO a sofrer eviction quando o node fica com pouca memória
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # uso real de CPU/memory
kubectl describe node <node>               # recursos alocados vs capacidade
```

## Orientação prática

```text
✓ Sempre defina memory requests = limits para comportamento previsível e OOM-safe em apps críticos
✓ Defina CPU requests conforme a necessidade em regime permanente; CPU limits são muitas vezes omitidos para permitir bursting
✓ Dimensione a partir do uso real (kubectl top / metrics) — não de chutes
✓ Use LimitRange / ResourceQuota para impor defaults sensatos por namespace
```

## Por que isso importa

Requests e limits são como o Kubernetes compartilha recursos finitos de node de forma justa e previsível, então entender a distinção e suas consequências é conhecimento essencial de performance e confiabilidade. O insight central é que eles servem a propósitos diferentes: **requests** são uma reserva garantida que o **scheduler** usa para posicionar Pods (somando os requests para decidir se um node tem espaço, ignorando os limits), enquanto **limits** são um teto de runtime imposto de forma diferente por recurso — exceder um limit de **CPU** faz você ser **throttled** (desacelerado), mas exceder um limit de **memory** faz o container ser **OOM-killed** e reiniciado. Errar nos requests tem custos reais dos dois lados: baixo demais e os nodes ficam em overcommit, com os Pods se matando de fome mutuamente; alto demais e a capacidade é desperdiçada enquanto os Pods ficam em Pending porque nada cabe. As três classes de **QoS** — Guaranteed (requests iguais aos limits), Burstable (requests abaixo dos limits) e BestEffort (nada definido) — determinam a ordem de eviction sob pressão de memória, com BestEffort morto primeiro e Guaranteed por último, que é exatamente o que você precisa entender para proteger workloads críticos. Conhecer a orientação prática (definir memory requests iguais aos limits para apps críticos, dimensionar a partir do uso real via `kubectl top`, impor defaults com LimitRange/ResourceQuota) transforma isso de teoria em um planejamento de capacidade sólido. Como a má configuração de recursos é uma das causas mais comuns de instabilidade, gasto desperdiçado e Pods em Pending em clusters reais, dominar requests, limits e QoS é fundamental para rodar workloads Kubernetes eficientes e estáveis.

Requests vs limits

Como o scheduling usa os requests

Classes de QoS (decidem a ordem de eviction sob pressão de memória)

Orientação prática

Por que isso importa

Perguntas relacionadas