Kubernetes y Docker Swarm hacen lo mismo sobre el papel, repartir contenedores entre varios servidores, reiniciarlos cuando se caen y publicarlos hacia fuera. La diferencia está en cuánta gente hace falta para mantenerlos vivos. Kubernetes es el estándar del sector y da respuesta a casi cualquier necesidad, pero paga esa potencia con una curva de aprendizaje y una carga de operación que un equipo de dos personas no absorbe. Docker Swarm es mucho más limitado y también mucho más barato de sostener. Esta comparativa va de elegir en función del tamaño y la dedicación real del equipo, no del tamaño de la empresa.
Qué hace un orquestador de contenedores
Un orquestador de contenedores es el software que decide en qué servidor de un grupo se ejecuta cada contenedor, lo vuelve a levantar si falla, reparte el tráfico entre las réplicas y gestiona las actualizaciones sin cortar el servicio. Sin orquestador tienes contenedores atados a una máquina concreta; con él tienes un conjunto de máquinas que se comporta como una sola.
Esto importa cuando aparece el segundo servidor. Con un único host, Docker Compose sobra para casi todo y añadir un orquestador es complicarse la vida. En cuanto quieres que un servicio siga en pie aunque se caiga una máquina, o que las réplicas crezcan solas en las horas punta, necesitas orquestación.
Kubernetes en dos minutos
Kubernetes (K8s) nació en Google y hoy lo mantiene la Cloud Native Computing Foundation. Es la plataforma sobre la que se apoya prácticamente todo el ecosistema moderno, con los servicios gestionados de los tres grandes proveedores (EKS, AKS, GKE), distribuciones para instalar en casa y un catálogo enorme de herramientas alrededor.
Lo que aporta frente a alternativas más sencillas es escalado automático por métricas, permisos finos por espacio de nombres, gestión declarativa completa, almacenamiento persistente con controladores por proveedor, y un ecosistema donde cualquier problema ya lo ha resuelto alguien. Lo que exige a cambio es ritmo. El proyecto publica una versión menor nueva cada pocos meses (la 1.37 salió el 26 de agosto de 2026) y solo mantiene con parches las tres versiones más recientes, lo que da alrededor de un año de soporte por versión. Traducido a calendario, actualizar el clúster es una tarea recurrente, no un proyecto que se hace una vez.
Para una pyme, la vía razonable de entrar es una distribución ligera como k3s, que es Kubernetes certificado en un binario pequeño y con requisitos modestos, un servidor de 2 núcleos y 2 GB de RAM y agentes de 1 núcleo y 512 MB según su documentación. Se instala en un servidor Linux con una sola orden.
curl -sfL https://get.k3s.io | sh -
kubectl get nodesSi el segundo comando devuelve el nodo en estado Ready, ya tienes un clúster funcionando. Lo difícil viene después.
Docker Swarm en dos minutos
Docker Swarm es el modo de clúster que viene integrado en Docker Engine. No se instala nada aparte, se activa. Si tu equipo ya escribe ficheros docker-compose.yml, el salto es casi inmediato, porque el mismo formato de fichero sirve para desplegar un stack en varios nodos.
docker swarm init --advertise-addr 10.0.0.11
docker swarm join-token worker
docker stack deploy -c docker-compose.yml miapp
docker service lsDespués de esos comandos hay que comprobar dos cosas, que docker node ls muestra todos los nodos como Ready y Active, y que docker service ps miapp_web no deja tareas en estado Rejected o Failed, que es donde aparecen los errores de imagen o de volumen. El error más frecuente al empezar es publicar puertos que ya usa otro servicio, porque en Swarm el puerto se reserva en todos los nodos a la vez.
Una aclaración necesaria. Hay que distinguir el Swarm mode integrado en Docker Engine, que sigue soportado y documentado, del antiguo Docker Classic Swarm, un producto separado que ya no recibe desarrollo activo. Cuando alguien dice que Swarm «está muerto» suele estar mezclando los dos. Dicho esto, el ritmo de novedades del Swarm mode es muy bajo, y eso es a la vez su mayor virtud y su mayor riesgo, poca cosa que aprender y poca cosa que esperar.
Diferencias que de verdad pesan
| Criterio | Kubernetes | Docker Swarm |
|---|---|---|
| Puesta en marcha | Horas con una distribución ligera, días con instalación completa | Minutos, ya viene en Docker Engine |
| Curva de aprendizaje | Alta, conceptos y herramientas propios | Baja si ya usáis Docker Compose |
| Mantenimiento | Versión nueva cada pocos meses, actualizaciones planificadas | Sigue el ciclo de Docker Engine, muy pocos cambios |
| Escalado automático | Sí, por CPU, memoria o métricas propias | No, el número de réplicas se fija a mano |
| Ecosistema y contratación | Enorme, y perfiles fáciles de encontrar | Reducido, comunidad pequeña |
Qué usar según el tamaño del equipo
Nuestro criterio mira cuántas personas pueden dedicar tiempo a la plataforma de forma sostenida, más que la facturación o el número de contenedores.
Una persona, o ninguna dedicada
Ni Kubernetes ni Swarm. Con uno o dos servidores, Docker Compose y un proceso de despliegue automatizado cubren el caso con mucho menos que perder. Meter un orquestador aquí añade un sistema crítico más que nadie va a mantener, y el día que falle no habrá quien sepa dónde mirar.
De dos a cinco personas, sin especialista
Es el terreno natural de Docker Swarm. Da alta disponibilidad real, despliegues progresivos y balanceo entre nodos con un modelo mental que el equipo ya conoce, y se sostiene con unas pocas horas al mes. Si la razón para querer orquestar es «que la aplicación siga en pie si se cae un servidor», Swarm la resuelve entera.
Más de cinco personas, o alguien dedicado a plataforma
Aquí sí compensa Kubernetes, y compensa cada vez más a medida que crecen los equipos de desarrollo. Escalado automático, entornos aislados por espacio de nombres, permisos granulares y despliegues declarativos desde el repositorio. La condición es que haya alguien cuyo trabajo incluya el clúster y que tenga con quién turnarse; si esa persona es la misma que atiende los puestos y el correo, el clúster acabará dos versiones por detrás y sin actualizar.
Antes de decidir entre ambos conviene contestar la pregunta previa, que desarrollamos en si tu empresa necesita Kubernetes, porque en bastantes casos la respuesta honesta es que no.
Un escenario típico: el clúster que nadie actualizaba
Una empresa de software de unas treinta personas, con seis desarrolladores y un técnico de sistemas a media jornada, montó Kubernetes porque era lo que se hacía. Un año y medio después el clúster funcionaba, pero iba tres versiones menores por detrás, fuera ya de soporte con parches, con manifiestos escritos por tres personas distintas y sin nadie capaz de diagnosticar un fallo de red entre nodos sin abrir un ticket. Cada despliegue nuevo lo hacía la misma persona, que era también el único punto de fallo del sistema.
La salida fue reconocer para qué se estaba usando el clúster. Las cargas eran seis servicios web y dos trabajos programados, sin picos y sin necesidad de escalado automático. Se pasaron a un Swarm de tres nodos reutilizando los mismos ficheros de Compose, con almacenamiento compartido para lo que necesitaba persistencia y despliegue desde la misma canalización de integración continua que ya tenían.
Lo que cambió fue quién puede tocarlo. Los seis desarrolladores despliegan y diagnostican sin ayuda, porque el modelo es el que usan a diario en local. Las actualizaciones pasaron a ser las del sistema operativo y las de Docker Engine, y el técnico de sistemas dejó de ser el cuello de botella. Si esa empresa crece hasta necesitar escalado por métricas o aislamiento estricto entre equipos, volverá a Kubernetes con criterio, y esta vez con alguien dedicado.
Lo que usamos nosotros y por qué
Usamos los dos, con una regla clara. Docker Swarm cuando el objetivo es continuidad con pocos servicios y un equipo que no vive dentro de la plataforma. Kubernetes, normalmente en su versión ligera k3s sobre servidores propios o en el servicio gestionado del proveedor cuando el cliente ya está en la nube, cuando hay escalado real, varios entornos que aislar o un equipo de desarrollo que despliega varias veces al día.
Sobre coste conviene tener un dato encima de la mesa. Un clúster gestionado de Amazon EKS cuesta unos 0,09 euros por clúster y hora en soporte estándar y unos 0,52 euros en soporte extendido, cuando la versión ya salió del ciclo normal (0,10 y 0,60 dólares en la lista oficial de precios consultada en septiembre de 2026, al cambio del BCE del día 22). Eso son unos 64 euros al mes solo por el plano de control, sin contar los servidores. Quedarse rezagado en versiones sale seis veces más caro. En infraestructura propia no pagas esa cuota, pero el plano de control lo mantienes tú.
En ambos casos lo que marca la diferencia viene después de la instalación. Copias probadas de los volúmenes y de la configuración, monitorización con alertas que alguien lee, actualizaciones planificadas y despliegues reproducibles desde el repositorio. Es lo que cubrimos dentro del servicio de DevOps y automatización, y lo que conecta con las herramientas de la comparativa de plataformas de CI/CD.
Cómo decidirlo
Empieza por escribir para qué quieres orquestar. Si la respuesta es que el servicio no se caiga cuando falle un servidor, Swarm te vale y estarás en producción esta semana. Si la respuesta incluye escalar según la carga, aislar equipos o desplegar decenas de veces al día, Kubernetes es el camino y lo primero que hay que asegurar es quién lo va a mantener el año que viene. Si no lo tienes claro, cuéntanos tu caso y lo revisamos con tus servicios y tu equipo reales en un diagnóstico sin compromiso.
Si todavía estás en la pregunta anterior, aquí lo planteamos sin rodeos, ¿necesita mi empresa Kubernetes?