Los Pods son desechables, y un Pod suelto que muere se queda muerto. Un Deployment lo soluciona: declaras cuántas copias quieres y qué imagen ejecutar, y Kubernetes mantiene esa cantidad en ejecución y gestiona las actualizaciones por ti. Esta guía cubre cómo crear uno, escalarlo, actualizarlo sin tiempo de inactividad y revertirlo.

Por qué rara vez creas Pods sueltos

Si un nodo falla o se elimina un Pod, nada recrea un Pod independiente. En la práctica casi nunca creas Pods directamente. Creas un Deployment, que crea un ReplicaSet, que a su vez crea y mantiene los Pods. El Deployment añade lo que le falta al ReplicaSet: actualizaciones controladas e historial de versiones.

Escribe un Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

Hay dos secciones metadata, y conviene no confundirlas. La de arriba describe el Deployment. La que está bajo template describe los Pods que crea, y el template es simplemente un manifiesto de Pod sin nombre. El selector le dice al Deployment qué Pods le pertenecen, así que debe coincidir con las etiquetas de la plantilla, o Kubernetes rechazará el manifiesto.

kubectl apply -f deployment.yaml
kubectl get deployment,replicaset,pods

Verás un Deployment, un ReplicaSet con su nombre más un hash y tres Pods con el nombre del ReplicaSet.

Labels y selectores: cómo se encuentran los objetos

Las etiquetas son pares clave-valor que puedes adjuntar a cualquier objeto. Los selectores las consultan, y así es como Kubernetes conecta las cosas: un Deployment encuentra sus Pods, un Service encuentra sus backends y una network policy encuentra los Pods que gobierna.

kubectl get pods --show-labels
kubectl get pods -l app=web

Para ver cuánto importa un selector, quita la etiqueta de un Pod:

kubectl label pod POD_NAME app-
kubectl get pods --show-labels

El ReplicaSet ya no cuenta ese Pod como suyo, así que arranca un reemplazo para volver a tres. El Pod sin etiqueta sigue en ejecución, pero nada lo gestiona. Elimínalo con kubectl delete pod POD_NAME para que no se quede ahí.

Escala y observa la autorreparación

kubectl scale deployment web --replicas=5
kubectl get pods -w

En otra terminal, elimina un Pod y observa cómo aparece un reemplazo en un instante. Para cambiar el número de réplicas de forma permanente, edita replicas en el manifiesto y vuelve a aplicarlo, ya que kubectl scale por sí solo deja tu archivo desactualizado. No puedes deshacerte de los Pods de un Deployment eliminándolos, porque siguen volviendo. Elimina el propio Deployment, o escálalo a cero.

Despliega una versión nueva

Cambiar cualquier cosa en la plantilla del Pod, como la imagen, desencadena un rolling update:

kubectl set image deployment/web nginx=nginx:1.26
kubectl rollout status deployment/web

El Deployment crea un segundo ReplicaSet para la nueva versión y luego lo escala gradualmente mientras reduce el antiguo, de modo que siempre hay Pods atendiendo tráfico. Por defecto permite hasta un 25% de Pods adicionales (maxSurge) y hasta un 25% no disponibles (maxUnavailable) durante el cambio. Puedes ajustarlo en la especificación:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Con maxUnavailable: 0, un Pod antiguo solo se elimina cuando uno nuevo está listo. Qué significa “listo” lo deciden las readiness probes, que se cubren en una guía posterior. Cambiar el número de réplicas no es un rollout, porque no toca la plantilla del Pod.

Revierte

Kubernetes conserva los ReplicaSets antiguos, lo que hace rápido el rollback:

kubectl rollout history deployment/web
kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=1

undo vuelve a la revisión anterior y --to-revision elige una concreta. El número de revisiones antiguas que se conservan lo define revisionHistoryLimit, 10 por defecto. Una advertencia: si tus manifiestos viven en Git y algo como Argo CD los aplica, prefiere revertir el commit a rollout undo. El undo cambia el clúster pero no Git, así que ambos discrepan hasta que alguien los reconcilie.