¿Qué son los Deployments y los ReplicaSets, y cómo funcionan los rolling updates y los rollbacks?

Question

IT Interview Practice · Accepted Answer

Un **Deployment** es el controller estándar para ejecutar apps stateless. Gestiona **ReplicaSets**, y un ReplicaSet mantiene en ejecución un número determinado de Pods idénticos. Tú editas el Deployment; él orquesta los **rolling updates** y **rollbacks** por ti.

## La jerarquía

```text
Deployment  → declara el estado deseado + la estrategia de actualización (lo que TÚ gestionas)
   └── ReplicaSet  → garantiza que existan N Pods idénticos (uno por versión de la app)
          └── Pod  → Pod → Pod ...  (las copias realmente en ejecución)

En cada versión nueva, el Deployment crea un ReplicaSet NUEVO y traslada los Pods hacia él.
```

## Un manifest de Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # como mucho 1 Pod caído durante la actualización
      maxSurge: 1            # como mucho 1 Pod extra por encima del número deseado
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: cambio de versión sin downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # dispara un rolling update
kubectl rollout status deployment/web            # observa el progreso
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (inicio: 4 Pods viejos)
      █████       levanta 1 nuevo (v2), ahora 5 en total (surge)
      ███ █       los viejos bajan a 3, el nuevo está Ready
      ...traslada gradualmente...
  v2: ████        (fin: 4 Pods nuevos, el ReplicaSet viejo escalado a 0)
El tráfico solo va a los Pods que pasan su readiness probe → sin downtime.
```

## Rollback cuando una release sale mal

```bash
kubectl rollout history deployment/web       # lista las revisiones
kubectl rollout undo deployment/web          # revierte a la revisión anterior
kubectl rollout undo deployment/web --to-revision=3
```

Como el ReplicaSet viejo se conserva (escalado a 0), un rollback es rápido: Kubernetes simplemente vuelve a escalar hacia arriba el ReplicaSet anterior y hacia abajo el nuevo.

## Escalado (scaling)

```bash
kubectl scale deployment/web --replicas=10   # cambia el número deseado
```

## Por qué es importante

Los Deployments son el caballo de batalla para ejecutar aplicaciones stateless en Kubernetes, así que entenderlos y su relación con los ReplicaSets es conocimiento esencial y de uso diario. La estratificación es la clave: gestionas un **Deployment**, que posee **ReplicaSets** (uno por versión), y cada ReplicaSet garantiza que un número determinado de Pods idénticos esté en ejecución: una cadena de bucles de reconciliación que en conjunto aportan auto-recuperación y un recuento de réplicas estable. La verdadera potencia está en cómo el Deployment maneja el cambio: un **rolling update** crea un ReplicaSet nuevo y traslada los Pods de viejo a nuevo de forma gradual, gobernado por `maxSurge` y `maxUnavailable`, de modo que se preserva la capacidad y —combinado con readiness probes que deciden qué Pods reciben tráfico— la release ocurre **sin downtime**. Como el ReplicaSet anterior se retiene (escalado a cero en vez de eliminado), un **rollback** es rápido y seguro: `kubectl rollout undo` simplemente vuelve a escalar hacia arriba la versión vieja y hacia abajo la mala, que es exactamente a lo que recurres cuando una release se comporta mal. Entender estos mecanismos —además de cómo escalar (`kubectl scale`) e inspeccionar el progreso (`kubectl rollout status/history`)— es fundamental para publicar software de forma segura en Kubernetes, y refleja el modelo declarativo, dirigido por controllers, que define cómo opera la plataforma en producción.

La jerarquía

Un manifest de Deployment

Rolling update: cambio de versión sin downtime

Rollback cuando una release sale mal

Escalado (scaling)

Por qué es importante

Preguntas relacionadas