5.1Swarm vs Kubernetes : cuándo pasar a la orquestación
Lo esencial en 30 segundos
- Compose = una máquina : no reparte en varios hosts, no sustituye un nodo muerto, no equilibra finamente la carga — en cuanto hagan falta multi-máquina, cero downtime o autorreparación, hay que orquestar.
- Swarm = multi-host sencillo : integrado en Docker, cercano a Compose, ideal para 2 a 5 máquinas (réplicas, actualización sin corte).
- Kubernetes = parque exigente : el estándar a gran escala (despliegues, servicios, autoescalado, secretos) pero con un aprendizaje serio — regla : Compose → Swarm → Kubernetes, por necesidad probada, nunca por moda.
Mini-caso hilado — Idir, devops junior en Alger
Idir, devops junior en Alger, ejecuta la app de su pequeña estructura en un solo servidor con Compose : funciona. Un día, le preguntan «¿por qué no Kubernetes?». En lugar de lanzarse, audita : una máquina, actualizaciones sencillas, ninguna exigencia multi-host. Veredicto : un Compose bien equipado (CI, copias de seguridad, healthchecks) basta. Aun así anota el siguiente paso : si el equipo pasa a 2 o 3 máquinas con necesidad de réplicas, será Swarm ; Kubernetes solo si el parque y los equipos lo exigen. Este caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 5.2, 5.3 y 5.4.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 5.2, 5.3 y 5.4.
1. Lo que Compose no hace
Compose brilla en una máquina : lanza, conecta y repite un stack de forma fiable. Pero no reparte los contenedores en varios hosts, no sustituye automáticamente un nodo muerto, y no equilibra finamente la carga entre réplicas. Idir lo comprueba en su servidor en Alger : mientras solo tenga un host y actualizaciones sencillas, estos límites no le molestan.
En cuanto se quiere cero downtime en varias máquinas, multi-host o autorreparación, hace falta un orquestador : un piloto multi-máquinas que coloca las réplicas, vigila y repara. La pregunta no es pues «¿qué herramienta está de moda?» sino «¿qué dolor real debo tratar?».
2. Swarm : el hermano mayor de Compose
Swarm está integrado en Docker y habla casi Compose (docker stack deploy -c compose.yml). Se aprende rápido : un manager, workers, réplicas, actualizaciones réplica por réplica. Idir ve en él el paso natural si su estructura pasa a 2 o 3 máquinas : mismos reflejos Compose, más el reparto y la actualización sin corte.
Ideal para 2 a 5 máquinas y necesidades sencillas. Su límite : un ecosistema y una finura menores que Kubernetes (sin autoescalado nativo tan avanzado, menos extensiones). Para multi-host sencillo, es una excelente relación esfuerzo/beneficio.
3. Kubernetes : el estándar exigente
Kubernetes orquesta a gran escala : despliegues, servicios con dirección estable, autoescalado, secretos, exposición avanzada. Pero exige un aprendizaje serio y un clúster que operar — o un clúster gestionado operado por un proveedor. Idir retiene la regla de escalada : Compose → Swarm → Kubernetes, un peldaño cada vez, por necesidad probada.
Un Kubernetes sin necesidad es complejidad sin beneficio : más piezas que vigilar, guardar y actualizar, sin ningún beneficio si bastaba una máquina. Se sube un peldaño cuando el dolor lo exige — nunca para aprender en producción.
¿Lo sabía?
Un Kubernetes sin necesidad es complejidad sin beneficio.
🔎 Ejemplo concreto — La parrilla de decisión de Idir
Cada peldaño responde a un dolor real.
1 máquina, despliegues sencillos -> Compose + CI + copias
2-5 máquinas, réplicas, update sin corte -> Swarm (stack deploy)
Parque, autoescalado, multi-equipos -> Kubernetes (gestionado)
Pregunta trampa : queremos K8s
-> ¿Qué necesidad precisa? Si no : Compose.Lectura : Idir sitúa su necesidad real en la escala antes de elegir.
Lección : un orquestador sin necesidad = complejidad sin beneficio.
Vocabulario de la sección
- Orquestador
- El piloto multi-máquinas : coloca las réplicas, vigila y repara.
Ejemplo sencillo: Idir compara Compose (un host) con un orquestador en cuanto hacen falta varias máquinas.
Lo que no es: un simple archivo Compose en una sola máquina.
Reflejo: ¿necesito repartir en varios hosts?
- Réplica
- Un ejemplar de un servicio, repartido por el orquestador.
Ejemplo sencillo: Idir prevé 3 réplicas de su app web en su futuro clúster.
Lo que no es: un contenedor único lanzado a mano.
Reflejo: ¿cuántos ejemplares exige mi servicio?
- Rolling update
- La actualización sin corte, réplica por réplica.
Ejemplo sencillo: Idir actualiza su app una réplica cada vez, el servicio siempre responde.
Lo que no es: detenerlo todo y relanzar a plena jornada.
Reflejo: ¿mi actualización corta el servicio?
- Nodo
- Una máquina miembro del clúster (manager o worker).
Ejemplo sencillo: Idir cuenta sus máquinas reales antes de elegir su escala.
Lo que no es: un contenedor aislado.
Reflejo: ¿cuántas máquinas tengo realmente?
- Gestionado
- Un clúster operado por un proveedor en lugar de operarlo a mano.
Ejemplo sencillo: Idir apunta a un clúster gestionado si Kubernetes se vuelve necesario.
Lo que no es: un clúster improvisado sin equipo para operarlo.
Reflejo: ¿quién opera el clúster si elijo Kubernetes?
En la práctica — Auditar su necesidad
- Liste sus máquinas y sus servicios reales (como Idir : una máquina, una app web).
- Anote sus exigencias : ¿corte aceptable? ¿multi-host? ¿autoescalado?
- Sitúese en la escala Compose / Swarm / Kubernetes.
- Escriba el siguiente paso SOLO si la necesidad lo exige.
Guion listo para decir — justificar la elección de escala
«Hoy en Alger, nuestra app corre en una máquina con actualizaciones sencillas : Compose con CI, copias de seguridad y healthchecks basta. Si pasamos a varias máquinas con necesidad de réplicas, propongo Swarm ; Kubernetes solo si el parque y los equipos lo exigen. Subimos un peldaño por necesidad probada, no por moda.»
Para decir al equipo para enmarcar la elección antes de todo cambio de herramienta.
Modelo copiar-pegar — ficha elección de escala
FICHA ELECCIÓN DE ESCALA — fecha : ___
MÁQUINAS REALES : ___ · SERVICIOS : ___
EXIGENCIAS : ¿corte OK? SÍ / NO · ¿multi-host? SÍ / NO · ¿autoescalado? SÍ / NO
ESCALA : Compose / Swarm / Kubernetes (rodear)
PRUEBA DE LA NECESIDAD : ___
SIGUIENTE PASO : ___ (solo si necesidad probada)Solo / presupuesto reducido
Idir solo : Compose + CI + copias de seguridad basta — anotar el peldaño Swarm por si acaso.
TPE / equipo reducido
Una ficha de auditoría a la vista : cada uno ve por qué nos quedamos en Compose por ahora.
PYME en Alger
Idir fija en Alger una revisión con su referente : máquinas, exigencias y siguiente paso escrito.
Equipo que empieza
Binomio : uno lista las máquinas, el otro las exigencias — decisión común, escrita.
✓ Buenas prácticas
- Agote Compose + CI antes de subir un peldaño.
- Swarm para el multi-host sencillo (2 a 5 máquinas).
- Kubernetes preferiblemente en gestionado si hace falta Kubernetes.
✗ Errores frecuentes
- Pasar a Kubernetes «para aprender» en producción.
- Creer que el orquestador guarda sus datos.
- Multiplicar las herramientas antes de que existan las necesidades.
Puntos clave
- Compose = 1 host, sencillo y robusto — no reparte ni repara en varias máquinas.
- Swarm = multi-host sencillo (2 a 5 máquinas), cercano a Compose, ideal para empezar la orquestación.
- Kubernetes = parque exigente, estándar a gran escala, aprendizaje serio.
- Se sube por necesidad probada : Compose → Swarm → Kubernetes, nunca por moda.
Reto 48h — aplique mañana
Rellene la ficha elección de escala (modelo anterior) para su app real : ¿sus máquinas y sus exigencias justifican su escala?
- Puedo situar mi necesidad en la escala Compose / Swarm / Kubernetes.
- Mi ficha de auditoría está escrita y justificada.
- Sé por qué un orquestador sin necesidad cuesta más de lo que aporta.
Preguntas frecuentes
¿Swarm está superado frente a Kubernetes?
No : integrado en Docker y mantenido, Swarm sigue siendo temible a su escala — el multi-host sencillo (unas máquinas, réplicas, actualizaciones sin corte). Menos de moda que Kubernetes, pero mucho más sencillo de aprender y operar. Elija por necesidad : Swarm para unas máquinas, Kubernetes para un parque con exigencias avanzadas.
¿Se puede seguir en Compose en producción?
Sí, en muchos casos (una o dos máquinas) con CI, healthchecks, copias de seguridad probadas y reverse proxy. La orquestación no es un paso obligado : un Compose bien equipado supera a un orquestador sobredimensionado. Solo se sube hacia Swarm o Kubernetes por necesidad probada (multi-host, cero downtime, autoescalado).
Una app en 1 servidor, actualizaciones sencillas. ¿Qué elegir?