Docker Compose y Kubernetes no son sustitutos directos
| Criterio | Docker Compose | Kubernetes | Comentario |
|---|---|---|---|
| Desarrollo local | Excelente | Posible, normalmente más pesado | Compose tiene menor coste de entrada |
| Producción en un host | Excelente | A menudo excesivo | Docker documenta este escenario |
| HA multinodo | Sin scheduler de clúster nativo | Excelente | Kubernetes mantiene workloads entre nodos |
| Self-healing | Reinicio en el host | Excelente | Kubernetes también sustituye Pods y reacciona a fallos de nodos |
| Autoscaling | Manual | HPA | Escalado basado en métricas |
| Rolling updates | Manual | HPA | Deployment incluye RollingUpdate y rollback |
| Coste operativo | Menor | Mayor | El clúster exige más plataforma y conocimiento |
Docker Compose define de forma declarativa servicios, redes, volúmenes, configuraciones y secretos de una aplicación en contenedores. Compose Specification es el formato recomendado. [1]
Kubernetes gestiona workloads y servicios en un clúster y ofrece service discovery, load balancing, storage orchestration, rollouts, rollbacks y escalado. [8]
La pregunta real es si el proyecto necesita orquestación de clúster o si basta un host bien gestionado.
Lo que Docker Compose hace bien
Compose reúne imágenes, variables de entorno, redes, volúmenes, healthchecks, dependencias, secretos y configuraciones en un mismo modelo. [1][3]
La misma definición puede usarse en desarrollo, CI, staging y producción mediante archivos de override. Docker documenta este patrón. [2]
Esto mantiene bajo el coste operativo inicial y simplifica el despliegue.
Compose en producción: el servidor único está documentado
Docker documenta explícitamente Compose en producción y presenta un único servidor como el modelo de despliegue más sencillo. [2]
En producción suele tener sentido separar `compose.production.yaml`, adaptar puertos y variables, eliminar bind mounts de código y configurar restart policies. [2]
Si todos los contenedores están en un host, ese host sigue siendo un dominio común de fallo.
Healthchecks, dependencias y reinicios
Con `depends_on` y `condition: service_healthy`, Compose puede esperar a que una dependencia pase su healthcheck. [3][4]
El campo `restart` admite `no`, `always`, `on-failure` y `unless-stopped`. [3][7]
Esto mejora la resiliencia del proceso, pero sigue limitado al mismo Docker host.
Escalado con Compose: réplicas no equivalen a clúster
`docker compose up --scale SERVICE=N` y `docker compose scale` permiten iniciar varias instancias. [6]
En el escenario estándar documentado por Docker, Compose en producción sigue ejecutándose en un solo servidor. [2]
Compose Deploy Specification define `replicas`, `placement`, `resources`, `update_config` y `rollback_config`, pero `deploy` es opcional y una implementación puede ignorarlo si no lo soporta. [5][3]
Qué añade Kubernetes más allá de un único host
Kubernetes mantiene el estado deseado mediante controladores. Deployment es la abstracción habitual para aplicaciones stateless y administra Pods mediante ReplicaSets. [10]
La plataforma puede distribuir réplicas entre nodos, mantener su número, exponer endpoints estables mediante Services y reaccionar ante fallos. [8][10][15]
La principal diferencia está en ese control plane, no en el YAML.
Self-healing: fallo de proceso frente a fallo de nodo
| Capacidad | Docker Compose | Kubernetes | Diferencia |
|---|---|---|---|
| Reinicio de contenedor | Sí | Sí | Ambos pueden reiniciar procesos |
| Recuperación tras fallo de nodo | No | Sí | Kubernetes puede colocar el Pod en otro nodo |
| Mantener réplicas | Manual | Declarativo | Los controladores mantienen el estado deseado |
| Autoscaling por métricas | No | Sí | HPA ajusta periódicamente las réplicas |
| Endpoint estable | Red Compose | Service | Service abstrae Pods cambiantes |
| Scheduling CPU/RAM | En un host | Scheduler del clúster | El scheduler usa requests |
Compose puede reiniciar un contenedor según su restart policy mientras el host Docker siga funcionando. [7]
Kubernetes puede además sustituir Pods, mantener el número de réplicas y reprogramar workloads cuando un nodo deja de estar disponible. [12]
Readiness puede retirar un Pod no preparado de los backends de Service y liveness puede provocar un reinicio. Una sonda liveness mal diseñada puede causar fallos por sí misma. [16]
Networking y service discovery
Compose crea redes de aplicación y permite comunicación por nombre de servicio, suficiente para muchas aplicaciones de un solo host. [1]
Kubernetes Service proporciona una IP o hostname estable para un conjunto dinámico de Pods. [15]
Esta abstracción es especialmente valiosa en un clúster multinodo donde Pods e IP pueden cambiar.
Autoscaling y gestión de recursos
Compose permite escalado manual, pero no ofrece un controlador equivalente a HPA basado en métricas del clúster. [6]
HorizontalPodAutoscaler puede ajustar réplicas según CPU, memoria o métricas personalizadas. [13]
Kubernetes también admite `requests` y `limits`; el scheduler usa los requests al decidir en qué nodo ejecutar un Pod. [14]
Despliegues, rolling updates y rollback
En Compose, un despliegue típico construye o descarga una nueva imagen y recrea los contenedores afectados. Docker documenta, por ejemplo, `docker compose up --no-deps -d web`. [2]
Deployment incluye RollingUpdate, historial de revisiones y `kubectl rollout undo`. [11]
Para despliegues frecuentes con varias réplicas, Kubernetes ofrece estos mecanismos en la capa de orquestación.
Bases de datos y workloads stateful
Compose puede ejecutar bases con volúmenes si el equipo acepta el modelo de un host y gestiona backups, replicación y recuperación.
StatefulSet mantiene identidades estables de Pods y puede asociarlas a almacenamiento persistente. [17]
StatefulSet no convierte automáticamente una base en altamente disponible. Replicación, consistencia, backups y disaster recovery dependen de la base y de su arquitectura.
El coste operativo de Kubernetes forma parte de la decisión
La documentación de Kubernetes indica que un clúster de producción requiere planificación para resiliencia, accesos, disponibilidad y recursos. [9]
Kubernetes no es un PaaS completo. Logging, monitoring, alerting y otros componentes siguen siendo opcionales y extensibles. [8]
Managed Kubernetes reduce trabajo del control plane, pero el equipo sigue gestionando workloads, red, recursos, storage y troubleshooting.
Microservices no es un argumento automático a favor de Kubernetes
Kubernetes está diseñado para workloads desacoplados y dinámicos, pero dividir una aplicación en varios servicios no crea por sí solo una necesidad de clúster. [8]
Frontend, API, worker, Redis y PostgreSQL pueden seguir ejecutándose con Compose si caben en un host y los objetivos de disponibilidad lo permiten.
Los mejores criterios son tolerancia a fallos de host, réplicas, autoscaling, SLO, frecuencia de despliegue y número de equipos.
Cuándo migrar realmente a Kubernetes
| Pregunta | Compose es razonable cuando | Kubernetes tiene sentido cuando |
|---|---|---|
| Fallo de host | La recuperación externa es suficiente | El workload debe sobrevivir automáticamente al fallo de nodo |
| Escala | Todo cabe en un host | Necesitas varios nodos y autoscaling |
| Despliegues | Recreate simple o proceso propio basta | Necesitas rollouts controlados de varias réplicas |
| Equipo | Uno o pocos equipos gestionan un stack simple | Muchos equipos necesitan una plataforma común |
| Número de servicios | El número por sí solo no es problema de clúster | Las operaciones necesitan estandarización y automatización |
| Plataforma | La simplicidad operativa es prioridad | Necesitas políticas, scheduling y abstracciones de clúster |
La migración tiene sentido cuando el modelo de un solo host se convierte en una limitación operativa, no simplemente cuando `compose.yaml` crece.
Señales reales son continuidad tras fallo de nodo, distribución automática de réplicas, autoscaling, rollouts controlados de muchos servicios, plataforma compartida por varios equipos o políticas comunes de recursos y red. [8][9][12][13]
Sin estos requisitos, Kubernetes puede añadir más complejidad que valor.
Ruta práctica para un proyecto en crecimiento
Un camino habitual es Dockerfile por aplicación, Compose para desarrollo e integración y también Compose en producción mientras un host siga siendo suficiente.
Antes de migrar a Kubernetes, haz stateless lo posible, externaliza sesiones y archivos, añade health endpoints correctos y define recursos, secretos y storage.
Compose puede seguir siendo la herramienta local aunque producción use Kubernetes.
- Empieza por SLO y disponibilidad.
- Si un host basta, evalúa Compose primero.
- Si el fallo del host no puede detener la aplicación, necesitas diseño multinodo.
- Si la carga cambia dinámicamente, evalúa HPA.
- Para rollouts controlados con varias réplicas, Kubernetes aporta controladores integrados.
- No muevas la base a Kubernetes solo porque la aplicación esté allí.
- Incluye el coste de clúster, observabilidad, red y upgrades.
- Elige el modelo más simple que cumpla los requisitos.
