De Docker Compose a Kubernetes — la migración que no tiene por qué ser dolorosa

La mayoría de las guías «migra de Compose a Kubernetes» se saltan la pregunta de si deberías — y luego destrozan el cómo. Te dicen que ejecutes kompose convert, empujes el YAML al clúster y des por hecho el trabajo.

La migración de verdad cubre cuatro preocupaciones: cuándo migrar, qué migrar primero, qué no traduce limpiamente, y cómo escalonar el cutover.

¿Debes migrar siquiera? No siempre. Una stack Compose de cinco servicios en una VM robusta, desplegada vía SSH y un git pull, sobrevivirá a la mayoría de clústeres Kubernetes con un décimo del coste operativo. Migra cuando necesites autoscaling que Compose no pueda proporcionar, control de acceso más granular entre servicios, o una flota más allá de ~3 nodos.

Lo que traduce limpiamente — y lo que no

# Mapeo Compose → Kubernetes
services      → Deployment / StatefulSet
ports         → Service (ClusterIP / LoadBalancer)
depends_on    → Init containers + readiness probes
volumes       → PVC + storageClass
healthcheck   → livenessProbe + readinessProbe

El 20 % que necesita replanteamiento: depends_on: service_healthy (tu app necesita lógica de retry al arrancar), volúmenes compartidos entre replicas (la mayoría del almacenamiento de bloques en la nube es ReadWriteOnce) y network_mode: host.

El artículo completo cubre:

• El plan de migración en cuatro etapas (lift-and-shift → paridad → cutover → ganar las features de K8s)
• Patrones de depends_on y la lógica de retry de app que los corrige
• El dolor del almacenamiento ReadWriteOnce y las tres rutas de escape
• El trabajo de preparación de DNS/TTL la semana antes del cutover
• Mantener la stack Compose en caliente como camino de rollback durante 72 horas
• Las features que no añadir la primera semana (Istio, etc.)

Háblanos si estás a punto de meterte en esto.