¿Cuál es la diferencia entre requests y limits de CPU/memoria, y cómo afectan al scheduling, la eviction y la QoS?

Question

IT Interview Practice · Accepted Answer

Los **requests** son lo que a un contenedor se le *garantiza* (se usan para el scheduling); los **limits** son el *techo* que no puede superar (se aplican en runtime). Juntos determinan dónde se colocan los Pods, cómo se les hace throttling o se les mata bajo presión, y qué clase de **Quality of Service (QoS)** recibe un Pod.

## Requests vs limits

```text
REQUEST → la cantidad RESERVADA para el contenedor. El SCHEDULER usa la suma de
          los requests para decidir si un node tiene sitio. Es tu suelo garantizado.
LIMIT   → el MÁXIMO que el contenedor puede usar. Se aplica en runtime:
          CPU por encima del limit    → THROTTLING (se ralentiza, no se mata)
          memoria por encima del limit → OOM-KILLED (contenedor terminado y luego reiniciado)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 de un core, garantizado
          memory: "256Mi"
        limits:
          cpu: "500m"        # puede subir hasta 0.5 core, luego throttling
          memory: "512Mi"    # superar esto → OOMKilled
```

## Cómo usa el scheduling los requests

```text
El node tiene 4 CPU / 8Gi asignables.
El scheduler suma los REQUESTS de los Pods ya colocados; un Pod nuevo cabe solo si sus
requests todavía caben en lo que queda. (Los limits NO se usan para la colocación.)
→ Requests demasiado bajos → node sobrecomprometido, los Pods pelean por los recursos.
→ Requests demasiado altos → capacidad desperdiciada, Pods atascados en Pending (no cabe nada).
```

## Clases de QoS (deciden el orden de eviction bajo presión de memoria)

```text
Guaranteed  → requests == limits para AMBOS cpu y memoria (cada contenedor)
              → el último en ser desalojado (máxima prioridad)
Burstable   → tiene requests pero son < limits (o parcialmente definidos)
              → desalojado después de BestEffort
BestEffort  → sin requests ni limits en absoluto
              → el PRIMERO en ser desalojado cuando el node se queda corto de memoria
```

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

## Guía práctica

```text
✓ Pon siempre memory requests = limits para un comportamiento predecible y a prueba de OOM en apps críticas
✓ Fija los CPU requests a la necesidad en estado estable; los CPU limits a menudo se omiten para permitir bursting
✓ Dimensiona a partir del uso real (kubectl top / métricas), no de suposiciones
✓ Usa LimitRange / ResourceQuota para imponer valores por defecto sensatos por namespace
```

## Por qué es importante

Los requests y limits son la forma en que Kubernetes reparte los recursos finitos de un node de manera justa y predecible, así que entender la distinción y sus consecuencias es conocimiento esencial de rendimiento y fiabilidad. La idea central es que sirven para propósitos distintos: los **requests** son una reserva garantizada que el **scheduler** usa para colocar Pods (sumando los requests para decidir si un node tiene sitio, ignorando los limits), mientras que los **limits** son un techo en runtime que se aplica de forma distinta por recurso: superar un limit de **CPU** provoca **throttling** (ralentización), pero superar un limit de **memoria** provoca que el contenedor sea **OOM-killed** y reiniciado. Equivocarse con los requests tiene costes reales por ambos lados: demasiado bajos y los nodes quedan sobrecomprometidos, con Pods matándose de hambre entre sí; demasiado altos y se desperdicia capacidad mientras los Pods quedan en Pending porque no cabe nada. Las tres **clases de QoS** —Guaranteed (requests iguales a limits), Burstable (requests por debajo de limits) y BestEffort (nada definido)— determinan el orden de eviction bajo presión de memoria, con BestEffort matado primero y Guaranteed el último, que es justo lo que necesitas entender para proteger workloads críticos. Conocer la guía práctica (poner memory requests iguales a limits en apps críticas, dimensionar a partir del uso real con `kubectl top`, imponer valores por defecto con LimitRange/ResourceQuota) convierte esto de teoría en planificación de capacidad sólida. Como la mala configuración de recursos es una de las causas más comunes de inestabilidad, gasto desperdiciado y Pods en Pending en clusters reales, dominar requests, limits y QoS es fundamental para ejecutar workloads de Kubernetes eficientes y estables.

Requests vs limits

Cómo usa el scheduling los requests

Clases de QoS (deciden el orden de eviction bajo presión de memoria)

Guía práctica

Por qué es importante

Preguntas relacionadas