Docker Swarm no está muerto: qué eliges de verdad frente a Kubernetes

El 8 de octubre de 2026, Docker Engine 29.9.0 cerró el CVE-2026-92542: un usuario sin privilegios en un nodo Swarm podía inyectar tramas Ethernet falsificadas en las redes overlay cifradas de los nodos vecinos. Ese es el changelog de la semana pasada del orquestador que medio sector da por muerto.

«Swarm está muerto» se dice siempre igual, con el tono de quien repite algo evidente, y casi siempre la dice alguien que no ha abierto el changelog. Lo que nos interesa de ella no es que sea injusta con Swarm. Es que el rumor en la dirección contraria —«Kubernetes es el estándar, pon Kubernetes»— sale igual de caro, y ese se repite todavía más.

Las cartas boca arriba antes de seguir: operamos los dos. Tenemos Docker Swarm y Kubernetes en producción, para nosotros y para clientes, y ofrecemos Kubernetes gestionado. O sea, que de este post salimos ganando digamos lo que digamos. Por eso vamos a decir también cuándo no deberías contratárnoslo.

Qué dice el registro de cambios, que es lo único que no opina

Swarm no es un producto que se compre aparte: el modo enjambre viene dentro del propio motor de Docker desde la versión 1.12, en 2016. Si tienes Docker, tienes Swarm. Eso explica buena parte de la confusión: nadie publica «Swarm 4.0» porque Swarm no tiene números de versión propios, se mueve con el motor. Y el motor se mueve.

Las notas de publicación de la 29.9.0 llevan nueve entradas que tocan el modo enjambre. Además del CVE, una que conviene leer despacio si tienes redes overlay cifradas: un error al programar el cifrado del plano de datos podía hacer que el tráfico de una red overlay cifrada saliera en claro hacia algunos nodos. La propia nota acota el daño —el nodo receptor descarta esos paquetes como falsificados, así que la pérdida de confidencialidad se limita a flujos de ida, como una consulta DNS por UDP o un SYN que no llega a nada—, pero ahí estaba. El resto son las cosas aburridas: liberar las asociaciones IPsec cuando el último contenedor sale de la red cifrada, en vez de dejarlas acumulándose hasta reiniciar el demonio; tareas rechazadas cuando el demonio no puede escribir en /var/lib/docker; puertos publicados accesibles por IPv6 con el proxy de espacio de usuario activado.

La versión anterior, la 29.8.0 del 3 de septiembre, traía otras ocho: nombres de servicio que dejaban de resolverse en un nodo para siempre si se perdía un anuncio de pertenencia a la red, un nodo propagando por gossip un valor caducado del descubrimiento de servicios tras actualizaciones concurrentes, el reparto del trabajo periódico de sincronización para que deje de llegar a ráfagas. Quien haya depurado una resolución de nombres intermitente en un clúster sabe cuánto duele cada una de esas tres líneas. Y la 29.9.1 salió seis días después de la 29.9.0, el 14 de octubre.

Hay un segundo dato, este contractual y con letra pequeña. Mirantis, que compró el negocio empresarial de Docker en noviembre de 2019, publicó el 1 de julio de 2025 que «Swarm tendrá soporte completo hasta al menos 2030», y conviene leer la frase entera: ese compromiso es dentro de Mirantis Kubernetes Engine 3, su plataforma de pago que orquesta con Kubernetes y con Swarm a la vez. No es una promesa sobre el Swarm que tú ejecutas gratis dentro del motor de Docker; ese lo mantiene Moby, que es de donde salen las correcciones de arriba. Son dos manos distintas y conviene no confundirlas al citar la fecha.

Mantenido tampoco significa vivo en el sentido que a ti te importa. En esas diecisiete entradas no hay una sola función nueva: son correcciones. La inversión reciente de Mirantis en CSI, que permite a un servicio con estado tener almacenamiento persistente de verdad, es la excepción que confirma el ritmo. Lo que Swarm no hace hoy, probablemente no lo hará nunca. Ese es un buen argumento para no montarlo. Mejor que el «está muerto», que además era falso.

El calendario del otro lado

Kubernetes tiene el problema contrario, y también se mide en fechas. El proyecto mantiene ramas de publicación solo para las tres versiones menores más recientes —ahora mismo la 1.37, la 1.36 y la 1.35, con fin de vida el 28 de octubre de 2027, el 28 de junio de 2027 y el 28 de febrero de 2027— y publica aproximadamente tres versiones al año. Mientras lees esto queda una cuarta rama terminando su ventana: la 1.34 agota sus parches el 27 de octubre de 2026, dentro de nueve días. Si tu clúster va por ahí, el calendario ya no es un debate de arquitectura.

Ya hicimos la cuenta completa en Kubernetes caduca cada catorce meses, y no se saltan versiones, así que no la repetimos aquí. El resumen operativo es el que cuenta para esta decisión: adoptar Kubernetes es comprometerse a una ventana de mantenimiento del plano de control cada pocos meses, para siempre, y a hacerlas en orden porque no se pueden saltar versiones. No es un defecto del proyecto —ese ritmo es lo que mantiene el ecosistema moviéndose—, es el precio de la entrada. Lo malo no es pagarlo: lo malo es firmarlo sin saber que lo has firmado.

La pregunta que decide no es técnica

En el hilo de turno, la discusión gira siempre alrededor de la escala y del catálogo de funciones: autoescalado, operadores, mallas de servicio, número máximo de nodos. Está bien para una charla. Pero casi ninguna de las empresas con las que trabajamos está cerca de esos límites: su problema nunca ha sido el número de nodos.

Lo que decide es mucho más prosaico, y son dos preguntas: ¿quién va a hacer el próximo salto de versión del orquestador? y ¿quién contesta a las tres de la mañana cuando un nodo deja de responder? Si las dos respuestas son «la misma persona que además desarrolla el producto», el tamaño del catálogo de funciones es irrelevante. Has elegido una herramienta que no vas a poder operar, y eso no es un problema de arquitectura, es una avería con fecha de entrega.

Cuándo Swarm sigue siendo la respuesta correcta

Lo que pierdes eligiéndolo es el ecosistema. No hay operadores que te instalen una base de datos con su lógica de recuperación, no hay catálogo de extensiones y buena parte de la herramienta nueva que sale cada mes asume un clúster de Kubernetes al otro lado. Si tu hoja de ruta a dos años pasa por ahí, montar Swarm hoy no te evita la migración: te la aplaza, y te la cobra más cara, porque la harás con producción encima.

Cuándo Kubernetes, y qué estás firmando

Kubernetes gana claramente cuando el producto lo pide: cuando necesitas autoescalado por métricas reales, cuando quieres aislar equipos o clientes en espacios de nombres (namespaces) con sus propias cuotas y permisos, cuando tu plataforma va a hospedar cosas que no escribes tú y te hace falta el catálogo de operadores, o cuando el cliente final te exige una pieza concreta del ecosistema. En esos casos no hay debate y nosotros tampoco lo abrimos.

Lo que sí abrimos es la factura de operación, porque es la parte que nadie pone en la diapositiva: tres ventanas de mantenimiento al año como suelo, un inventario de complementos que caducan por su cuenta y con su propio calendario, y la dependencia de piezas de terceros cuyo estado de salud casi nadie audita. Del controlador de entrada que publicaba a internet a buena parte del sector descubrimos que medio Kubernetes lo mantenían dos personas; hoy su repositorio está archivado en solo lectura. Se supo cuando hubo que mirarlo, no antes.

Por eso, cuando nos preguntan, acabamos en una de estas dos: o Kubernetes con alguien que lo opere de verdad —interno o nosotros—, o Swarm y dedicar el tiempo que te ahorras a lo que sí mueve tu negocio. La combinación que acaba en llamada de urgencia siempre es la misma: Kubernetes montado por el equipo de producto un trimestre flojo y, después, nadie.

Lo que no cambia elijas lo que elijas

Aquí es donde casi todo el debate se calla, y es donde acaban generándose los incidentes. El orquestador no te regala ninguna de estas cuatro cosas:

La primera fila nos rompió a nosotros el despliegue de nuestra propia web, y le dedicamos un post entero: «latest» no es una versión. Las otras tres son el trabajo de siempre, el que no aparece en ninguna tabla de orquestadores porque no los distingue. Desplegamos los dos con el mismo método —el despliegue sale de un repositorio, con la versión fijada y la marcha atrás ensayada— precisamente porque el orquestador es la parte intercambiable.

Y el eje con el que medimos cualquier diseño no cambia tampoco: el fallo es inevitable, la avería es una decisión de diseño. Una máquina se va a morir, elijas el orquestador que elijas. Que eso sea papeleo de mantenimiento o una tarde en la que nadie factura depende de decisiones que alguien tomó meses antes, y ninguna de ellas se llama Swarm ni Kubernetes.

Fuentes: el CVE-2026-92542, el fallo de cifrado del plano de datos overlay y el resto de entradas citadas están en las notas de publicación de Docker Engine 29.9.0 (8 de octubre de 2026), 29.9.1 (14 de octubre) y 29.8.0 (3 de septiembre) — docs.docker.com. El recuento de entradas que tocan el modo enjambre (nueve en la 29.9.0 y ocho en la 29.8.0) es nuestro, contando las que mencionan Swarm y las que solo afectan a redes overlay, descubrimiento de servicios o gossip, que son piezas exclusivas del modo enjambre; el lector puede rehacer la cuenta en la misma página. El compromiso «hasta al menos 2030» dentro de Mirantis Kubernetes Engine 3 y el trabajo en CSI, del anuncio de Mirantis del 1 de julio de 2025 — mirantis.com; es una promesa de un fabricante sobre su propio producto de pago. La política de tres ramas mantenidas, la cadencia de unas tres versiones menores al año y las fechas de fin de vida de 1.37, 1.36, 1.35 y 1.34, de la página oficial de versiones de Kubernetes — kubernetes.io, consultada el 18 de octubre de 2026. La orquestación integrada llegó al motor en Docker 1.12, anunciada por Docker en 2016 — docker.com; la compra de Docker Enterprise por Mirantis se anunció el 13 de noviembre de 2019. Las valoraciones sobre cuándo conviene cada orquestador son nuestras, salen de operar los dos en producción y no son un dato: contrástalas con tu caso.