Cómo migrar a Kubernetes sin downtime: guía paso a paso

Migrar a Kubernetes puede parecer una operación de alto riesgo. La mayoría de los equipos lo abordan como un “big bang”: detener producción, migrar todo a la vez, rezar para que funcione. Hay una forma mejor.

El principio fundamental: migración incremental

La clave es tratar la migración como una serie de pasos reversibles, no como un evento único. En cada paso, Kubernetes convive con tu infraestructura actual hasta que estás seguro de que todo funciona.

Fase 1: Preparar el entorno sin tocar producción

Antes de mover una sola carga de trabajo, necesitas un clúster de staging con la misma configuración que tendrás en producción.

# Crear clúster EKS con eksctl
eksctl create cluster \
  --name evoltix-staging \
  --region eu-central-1 \
  --nodegroup-name workers \
  --node-type t3.medium \
  --nodes 2

En este punto, producción sigue corriendo igual. No has tocado nada.

Fase 2: Containerizar los servicios

Cada servicio necesita su Dockerfile. La regla de oro: un proceso por contenedor.

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "src/index.js"]

Prueba el contenedor localmente antes de subirlo a ningún registry:

docker build -t mi-servicio:latest .
docker run -p 3000:3000 mi-servicio:latest

Fase 3: El primer despliegue en staging

Un Deployment básico en Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-servicio
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mi-servicio
  template:
    metadata:
      labels:
        app: mi-servicio
    spec:
      containers:
      - name: mi-servicio
        image: mi-registry/mi-servicio:latest
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"

No omitas los resources. Sin límites, un solo pod con memoria leak puede derribar todo el nodo.

Fase 4: El corte de tráfico con zero downtime

Aquí está el núcleo de la migración sin downtime. Usamos un Load Balancer dual: el tráfico va primero al 5% en Kubernetes, el resto sigue en la infraestructura antigua.

En AWS esto se implementa con ALB Weighted Target Groups:

resource "aws_lb_listener_rule" "canary" {
  listener_arn = aws_lb_listener.main.arn

  action {
    type = "forward"
    forward {
      target_group {
        arn    = aws_lb_target_group.old.arn
        weight = 95
      }
      target_group {
        arn    = aws_lb_target_group.kubernetes.arn
        weight = 5
      }
    }
  }
}

Monitorizas métricas durante 24-48 horas. Si todo va bien, incrementas el peso gradualmente: 5% → 20% → 50% → 100%.

Si algo falla, revertir es cambiar el peso de vuelta a 0. En segundos.

Lo que no debes hacer

• No migres la base de datos al mismo tiempo. Kubernetes para los servicios stateless primero, las bases de datos después (y con mucho más cuidado).
• No ignores los health checks. Kubernetes necesita saber cuándo un pod está listo para recibir tráfico.
• No pongas secretos en las variables de entorno del Deployment. Usa Kubernetes Secrets o, mejor, AWS Secrets Manager con el CSI driver.

El resultado

Cuando terminas la migración, tienes:

• Despliegues en minutos en lugar de horas
• Rollback automático si el health check falla
• Escalado horizontal con un comando
• Infraestructura reproducible en código

¿Tu equipo está pensando en migrar a Kubernetes? Cuéntanos tu caso — hacemos esta migración en empresas de todos los tamaños.