El trío que todo principiante debe entender

Si acabas de entrar a Kubernetes, lo primero que debes dominar son tres objetos: Pod, ReplicaSet y Deployment. Están conectados en cascada y juntos explican el 80% de cómo corre una aplicación dentro de un cluster.

Pod: la unidad mínima de despliegue

Un Pod es la pieza más pequeña que Kubernetes sabe programar en un nodo. Dentro de un Pod vive uno o varios contenedores que comparten red, almacenamiento efímero y ciclo de vida. Todos los contenedores de un Pod corren siempre juntos en la misma máquina y se ven entre sí por localhost.

La regla práctica es: un Pod por cada proceso principal. Poner dos contenedores en el mismo Pod solo se justifica cuando uno apoya al otro de forma inseparable, por ejemplo un sidecar que recoge logs o un proxy que añade TLS.

Los Pods son efímeros: mueren, cambian de IP y no se actualizan en sitio. Por eso casi nunca los creas directamente.

ReplicaSet: mantener N copias vivas

Un ReplicaSet es un objeto cuya única misión es asegurar que siempre haya exactamente N Pods iguales corriendo. Si matas uno, crea otro. Si añades un nodo nuevo, puede mover réplicas para balancear. Si defines 5 y alguien borra 2, sube a 5 otra vez.

En la práctica tampoco creas ReplicaSets a mano. Son un engranaje interno del siguiente objeto.

Deployment: lo que sí vas a escribir

El Deployment es la capa de más alto nivel y la que usarás a diario. Un Deployment gestiona ReplicaSets por ti y añade lo más importante: actualizaciones seguras. Cuando cambias la imagen de tu aplicación, el Deployment crea un nuevo ReplicaSet con la nueva versión, levanta pods poco a poco, y mientras tanto va bajando los del ReplicaSet anterior. Eso es un rolling update.

Además te permite volver atrás con kubectl rollout undo si la versión nueva falla.

YAML mínimo

Así se ve un Deployment sencillo con 3 réplicas de nginx:

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

La parte template es literalmente la plantilla de Pod que se usará. El selector le dice al Deployment qué Pods son suyos mediante la etiqueta app: web. Las etiquetas son el pegamento de Kubernetes: casi todo se conecta por labels.

Cómo se relacionan en orden

El flujo es claro:

1. Tú creas un Deployment.
2. El Deployment crea un ReplicaSet.
3. El ReplicaSet crea y vigila los Pods.
4. Cuando actualizas la imagen, el Deployment crea un nuevo ReplicaSet y migra los Pods poco a poco.

Errores típicos al empezar

• Crear Pods sueltos con kubectl run y preguntarse por qué no reviven al morir.
• Tocar un ReplicaSet a mano: el Deployment lo sobrescribe.
• Olvidar etiquetas o ponerlas distintas entre selector y template.
• No definir resources, lo que hace que el scheduler no pueda planificar bien.

Domina este trío y el resto de Kubernetes se vuelve mucho menos intimidante.