¿Cómo gestionas los recursos de contenedores (CPU y memoria)?

Question

Accepted Answer

Por defecto, los contenedores pueden usar **recursos ilimitados del host** — lo que riesga que un contenedor prive a otros o bloquee el host. Docker te permite establecer **límites de recursos** (CPU, memoria) para controlar el consumo, importante para la estabilidad y el reparto justo de recursos en producción.

## El problema: uso sin límites de recursos

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## Estableciendo límites de memoria y CPU

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

Los límites de memoria (`-m`) limitan el uso (el contenedor es **eliminado por OOM** si excede el límite duro); los límites de CPU (`--cpus`) limitan el uso de CPU. Las **reservas** garantizan un mínimo.

## Monitoreo y ajuste

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## Por qué es importante

Comprender la gestión de recursos de contenedores es importante para **ejecutar contenedores de forma confiable en producción**, por lo que es un conocimiento operacional valioso.

El problema central — por defecto, **los contenedores pueden consumir todos los recursos disponibles del host** — es un riesgo real: un único contenedor defectuoso u ocupado (con una fuga de memoria o un proceso desbocado) puede **privar de recursos a otros contenedores o bloquear todo el host** (sin memoria), haciendo el host inestable.

Establecer **límites de recursos** (memoria y CPU) previene esto **aislando el consumo de recursos de los contenedores**, asegurando que un contenedor no pueda derribar a otros o al host — esencial para la estabilidad cuando se ejecutan múltiples contenedores por host (la norma en producción).

Comprender cómo establecer **límites de memoria** (con el contenedor siendo eliminado por OOM si excede el límite duro) y **límites de CPU**, más **reservas** (garantizando mínimos), es el mecanismo práctico para controlar y compartir recursos de forma justa.

Saber cómo **monitorear y ajustar** — usando `docker stats` para observar el uso real y dimensionar correctamente los límites, reconociendo `OOMKilled` (un contenedor alcanzando su límite de memoria) para diagnosticar problemas — es importante para establecer límites apropiados basados en necesidades reales.

Esto también se conecta con orquestación: **Kubernetes usa solicitudes/límites de recursos similares** que son esenciales para programación y estabilidad, por lo que comprender el concepto se transfiere a entornos orquestados.

Ya que ejecutar múltiples contenedores de forma confiable requiere prevenir contención de recursos y consumo descontrolado, y ya que los límites de recursos (límites de memoria y CPU, reservas, monitoreo) son el mecanismo para aislar contenedores y proteger la estabilidad del host, comprender la gestión de recursos de contenedores es un conocimiento valioso y prácticamente importante para despliegues de contenedores en producción — necesario para hosts multi-contenedor estables y un concepto que se extiende directamente a entornos orquestados como Kubernetes, donde la especificación de recursos es fundamental.