Dices qué quieres, el clúster lo mantiene

Qué resuelve Kubernetes

Docker corre contenedores en una máquina. En producción hacen falta varias: para aguantar más usuarios y para que la caída de una no tumbe el servicio. Alguien tiene que decidir en qué máquina va cada contenedor, reemplazar los que mueren, repartir el tráfico y actualizar sin apagar todo. Kubernetes (k8s) es ese «alguien»: un orquestador de contenedores.

Un clúster tiene dos partes:

• El plano de control: el API server (la puerta de entrada; kubectl habla con él), etcd (la base de datos donde se guarda el estado deseado), el scheduler (elige el nodo de cada pod) y los controladores (comparan lo deseado con lo real y corrigen la diferencia).
• Los nodos de trabajo: las máquinas que corren los contenedores. En cada una, el kubelet arranca lo que le asignan y avisa cómo va.

La idea central es declarativa: describes en YAML el estado que quieres («tres copias de tienda:1.0») y lo envías con kubectl apply -f. Los controladores repiten sin parar el mismo ciclo: observar, comparar, actuar. Si un contenedor muere, lo real deja de coincidir con lo deseado, y lo reemplazan.

Pod, ReplicaSet y Deployment

Un Pod es la unidad mínima: uno o más contenedores que comparten red e IP y siempre van juntos. Los pods son desechables: cuando uno muere no se «revive», se crea otro nuevo con otro nombre y otra IP. Por eso casi nunca se crean a mano.

Un Deployment describe una aplicación: qué imagen, cuántas réplicas y cómo actualizarla. Por debajo crea un ReplicaSet, que mantiene exactamente ese número de pods. Las etiquetas (labels) unen todo: el Deployment cuida los pods cuyas etiquetas coinciden con su selector, así que las del template deben coincidir.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tienda
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tienda          # cuida los pods con esta etiqueta…
  template:                # …y así son los pods que crea
    metadata:
      labels:
        app: tienda
    spec:
      containers:
        - name: tienda
          image: tienda:1.0
          ports:
            - containerPort: 8080

kubectl apply -f tienda.yaml                 # crea o actualiza lo descrito
kubectl get pods -o wide                     # pods, su estado y su nodo
kubectl describe pod NOMBRE                  # detalle y eventos (por qué no arranca)
kubectl logs NOMBRE                          # lo que escribió el contenedor
kubectl scale deployment tienda --replicas=5

Rolling update y rollback

Al cambiar la imagen (kubectl set image deployment/tienda tienda=tienda:2.0 o editando el YAML y aplicándolo), el Deployment crea un ReplicaSet nuevo y hace una actualización gradual: levanta algunos pods nuevos, espera a que estén listos, apaga algunos viejos, y repite. Con maxSurge y maxUnavailable se decide cuántos de más y de menos se permiten a la vez. Siempre hay pods atendiendo.

Si los pods nuevos no arrancan (por ejemplo, entran en CrashLoopBackOff: arrancan, fallan y se reinician una y otra vez), la actualización se atasca en lugar de seguir: los pods viejos siguen atendiendo. Cada cambio queda como una revisión; kubectl rollout undo vuelve a la anterior.

Antes de leer la respuesta