Docker
Diferencia entre multi-container local y scheduling multi-host.
Compose modela una aplicación multi-container; un orquestador administra workloads sobre un conjunto de nodos y trabaja continuamente para acercar el estado real al estado deseado.
Compose
→ proyecto en un Engine
Orquestador
→ desired state
→ scheduler
→ varios nodos
→ reconciliación continuaLa diferencia no es el formato YAML. Es la responsabilidad operativa asumida por la plataforma.
Compose es excelente para:
Permite:
Compose habla con un Engine/contexto.
compose.yaml
→ daemon seleccionado
→ containers de ese daemonNo elige automáticamente entre diez servidores ni mueve un container cuando el servidor desaparece.
En single-host:
host falla
→ daemon inaccesible
→ todos los containers de ese host caen
→ volumes locales inaccesiblesrestart: always solo actúa si el daemon/host vuelve y puede iniciar el container. No reschedulea en otro nodo.
Un orquestador almacena una intención:
service api
replicas: 3
image: sha256:ASi una instancia muere:
actual replicas: 2
→ controller detecta diferencia
→ scheduler crea reemplazo
→ actual replicas: 3Compose ejecuta operaciones cuando invocas comandos; no mantiene un control plane distribuido reconciliando indefinidamente.
Un scheduler decide dónde ejecutar según:
Compose no administra capacidad entre hosts.
Ante fallo de nodo, un orquestador puede crear la réplica en otro nodo si:
Rescheduling del proceso no garantiza recuperación de datos locales.
Compose ofrece DNS dentro de sus networks en un Engine.
Un cluster necesita:
Overlay/networking de cluster añade MTU, cifrado, control plane y troubleshooting del underlay.
Orquestadores pueden coordinar:
Compose puede recrear services, pero no ofrece automáticamente toda la semántica de un rollout distribuido seguro.
Un orquestador/plataforma puede escalar por:
Esto requiere capacity planning y límites. Escalar API puede saturar database o proveedor externo.
Compose permite --scale, pero la decisión y distribución siguen siendo manuales y single-host.
Recrear un proceso no corrige:
Puede producir crash loops. “Self-healing” significa reconciliar instancias, no reparar la aplicación.
En cluster necesitas una entrada que descubra réplicas y retire las no ready.
internet
→ ingress/load balancer
→ healthy replicas en varios nodosCompose single-host normalmente delega esto a Caddy, Nginx, Traefik u otro proxy que debes configurar y operar.
Compose puede montar archivos, pero un orquestador suele ofrecer recursos distribuidos con:
La seguridad real sigue dependiendo del backend, identidad y rotación.
Este es el límite más importante.
Stateless:
réplica puede moverse
→ no depende de disk localStateful:
réplica se mueve
→ necesita datos correctosUn orquestador no vuelve distribuido un volume local. Necesitas:
Son posibles, pero requieren:
Mover una database de Compose a Kubernetes no elimina trabajo de DBA; cambia el mecanismo.
Un cluster puede ofrecer:
Esto importa cuando varios equipos comparten infraestructura. También aumenta complejidad del control plane.
No adoptes un cluster para una sola API con downtime aceptable si un host automatizado cumple el SLO.
Simple no significa improvisado. Compose productivo necesita monitoring, backup, TLS y automation.
No todo salto es Kubernetes.
Puedes usar:
Evalúa capacidades y operación, no popularidad.
Una image OCI es ampliamente portable como artefacto. La aplicación completa no lo es automáticamente.
Diferencias:
depends_on vs readiness/controllers;Migrar requiere traducir el modelo y probar comportamiento.
Ser stateless, configurable y observable facilita migración, pero aún existen:
Diseñar contratos explícitos reduce acoplamiento.
Compose single-host puede ser adecuado.
Un scheduler/plataforma multi-host probablemente está justificado.
container_name y host assumptions;No migres al cluster mientras la app todavía guarda sesiones en writable layer.
En Compose preguntas:
¿qué ocurre en este host/container?En cluster agregas:
La observabilidad debe crecer con la plataforma.
Multi-host solo mejora disponibilidad si distribuyes correctamente:
Tres réplicas en la misma VM no son HA. Tres nodos en una sola zona tampoco cubren pérdida de zona.
Control planes y databases distribuidas requieren quorum. Añadir nodos sin entender consenso puede producir split brain o indisponibilidad.
El scheduler no sustituye la topología interna de stateful systems.
La curva operativa se convierte en riesgo.
No existe scheduling multi-host.
Datos locales divergen o se pierden.
Las semánticas son distintas.
Cluster ocioso puede costar más que el producto.
La simplicidad ya no compensa el riesgo.
| Necesidad | Compose single-host | Orquestador |
|---|---|---|
| Desarrollo local | Excelente | Excesivo |
| Failover de nodo | Manual | Automatizable |
| Multi-host scheduling | No | Sí |
| Rolling distribuido | Manual/limitado | Integrado |
| State local | Host específico | Requiere storage adicional |
| Complejidad | Baja/media | Alta |
Troubleshooting de Docker, donde cada incidente se descompone por capas en lugar de reiniciar componentes al azar.