El 8 d'octubre del 2026, Docker Engine 29.9.0 va tancar el CVE-2026-92542: un usuari sense privilegis en un node Swarm podia injectar trames Ethernet falsificades a les xarxes overlay xifrades dels nodes veïns. Aquest és el changelog de la setmana passada de l'orquestrador que mig sector dona per mort.
«Swarm és mort» es diu sempre igual, amb el to de qui repeteix una cosa evident, i gairebé sempre la diu algú que no ha obert el changelog. El que ens interessa d'ella no és que sigui injusta amb Swarm. És que el rumor en la direcció contrària —«Kubernetes és l'estàndard, posa-hi Kubernetes»— surt igual de car, i aquest es repeteix encara més.
Les cartes sobre la taula abans de continuar: operem tots dos. Tenim Docker Swarm i Kubernetes en producció, per a nosaltres i per a clients, i oferim Kubernetes gestionat. És a dir, que d'aquest post en sortim guanyant diguem el que diguem. Per això direm també quan no ens ho hauries de contractar.
Què diu el registre de canvis, que és l'únic que no opina
Swarm no és un producte que es compri a part: el mode eixam ve dins del mateix motor de Docker des de la versió 1.12, el 2016. Si tens Docker, tens Swarm. Això explica bona part de la confusió: ningú no publica «Swarm 4.0» perquè Swarm no té números de versió propis, es mou amb el motor. I el motor es mou.
Les notes de publicació de la 29.9.0 porten nou entrades que toquen el mode eixam. A més del CVE, una que convé llegir a poc a poc si tens xarxes overlay xifrades: un error en programar el xifratge del pla de dades podia fer que el trànsit d'una xarxa overlay xifrada sortís en clar cap a alguns nodes. La mateixa nota acota el dany —el node receptor descarta aquests paquets com a falsificats, de manera que la pèrdua de confidencialitat es limita a fluxos d'anada, com una consulta DNS per UDP o un SYN que no arriba enlloc—, però hi era. La resta són les coses avorrides: alliberar les associacions IPsec quan l'últim contenidor surt de la xarxa xifrada, en comptes de deixar-les acumulant-se fins a reiniciar el dimoni; tasques rebutjades quan el dimoni no pot escriure a /var/lib/docker; ports publicats accessibles per IPv6 amb el proxy d'espai d'usuari activat.
La versió anterior, la 29.8.0 del 3 de setembre, en portava vuit més: noms de servei que deixaven de resoldre's en un node per sempre si es perdia un anunci de pertinença a la xarxa, un node propagant per gossip un valor caducat del descobriment de serveis després d'actualitzacions concurrents, el repartiment de la feina periòdica de sincronització perquè deixi d'arribar a ràfegues. Qui hagi depurat una resolució de noms intermitent en un clúster sap quant fa mal cadascuna d'aquestes tres línies. I la 29.9.1 va sortir sis dies després de la 29.9.0, el 14 d'octubre.
Hi ha una segona dada, aquesta contractual i amb lletra petita. Mirantis, que va comprar el negoci empresarial de Docker el novembre del 2019, va publicar l'1 de juliol del 2025 que «Swarm tindrà suport complet fins com a mínim el 2030», i convé llegir la frase sencera: aquest compromís és dins de Mirantis Kubernetes Engine 3, la seva plataforma de pagament que orquestra amb Kubernetes i amb Swarm alhora. No és una promesa sobre el Swarm que tu executes gratis dins del motor de Docker; aquest el manté Moby, que és d'on surten les correccions de dalt. Són dues mans diferents i convé no confondre-les en citar la data.
Mantingut tampoc no significa viu en el sentit que a tu t'importa. En aquelles disset entrades no hi ha ni una sola funció nova: són correccions. La inversió recent de Mirantis en CSI, que permet a un servei amb estat tenir emmagatzematge persistent de debò, és l'excepció que confirma el ritme. El que Swarm no fa avui, probablement no ho farà mai. Aquest sí que és un bon argument per no muntar-lo. Millor que el «és mort», que a més era fals.
El calendari de l'altre costat
Kubernetes té el problema contrari, i també es mesura en dates. El projecte manté branques de publicació només per a les tres versions menors més recents —ara mateix la 1.37, la 1.36 i la 1.35, amb fi de vida el 28 d'octubre del 2027, el 28 de juny del 2027 i el 28 de febrer del 2027— i publica aproximadament tres versions a l'any. Mentre llegeixes això queda una quarta branca acabant la seva finestra: la 1.34 esgota els seus pedaços el 27 d'octubre del 2026, d'aquí a nou dies. Si el teu clúster hi va, el calendari ja no és un debat d'arquitectura.
Ja vam fer el compte complet a Kubernetes caduca cada catorze mesos, i no se salten versions, així que no el repetim aquí. El resum operatiu és el que compta per a aquesta decisió: adoptar Kubernetes és comprometre's a una finestra de manteniment del pla de control cada pocs mesos, per sempre, i a fer-les en ordre perquè no es poden saltar versions. No és un defecte del projecte —aquest ritme és el que manté l'ecosistema movent-se—, és el preu de l'entrada. El dolent no és pagar-lo: el dolent és signar-lo sense saber que ho has signat.
La pregunta que decideix no és tècnica
Al fil de torn, la discussió gira sempre al voltant de l'escala i del catàleg de funcions: autoescalat, operadors, malles de serveis, nombre màxim de nodes. Està bé per a una xerrada. Però gairebé cap de les empreses amb qui treballem no és a prop d'aquests límits: el seu problema no ha estat mai el nombre de nodes.
El que decideix és molt més prosaic, i són dues preguntes: qui farà el pròxim salt de versió de l'orquestrador? i qui contesta a les tres de la matinada quan un node deixa de respondre? Si les dues respostes són «la mateixa persona que a més desenvolupa el producte», la mida del catàleg de funcions és irrellevant. Has triat una eina que no podràs operar, i això no és un problema d'arquitectura, és una avaria amb data d'entrega.
Quan Swarm continua sent la resposta correcta
- Ningú de l'equip no porta «plataforma» al càrrec. Swarm es pot aprendre en una tarda perquè el model mental és el del Compose que ja fan servir cada dia; Kubernetes no, i fingir el contrari surt car a la primera guàrdia.
- El catàleg de serveis és estable. Deu, vint, quaranta serveis que canvien de versió, no de forma. Swarm reparteix rèpliques i fa actualitzacions graduals amb el paral·lelisme que li diguis, sense aprendre un llenguatge nou.
- Mai no has necessitat que la plataforma afegeixi rèpliques tota sola a les dues de la tarda.
El que perds triant-lo és l'ecosistema. No hi ha operadors que t'instal·lin una base de dades amb la seva lògica de recuperació, no hi ha catàleg d'extensions i bona part de l'eina nova que surt cada mes assumeix un clúster de Kubernetes a l'altre costat. Si el teu full de ruta a dos anys hi passa, muntar Swarm avui no t'evita la migració: te l'ajorna, i te la cobra més cara, perquè la faràs amb producció al damunt.
Quan Kubernetes, i què estàs signant
Kubernetes guanya clarament quan el producte ho demana: quan necessites autoescalat per mètriques reals, quan vols aïllar equips o clients en espais de noms (namespaces) amb les seves pròpies quotes i permisos, quan la teva plataforma hostatjarà coses que no escrius tu i et cal el catàleg d'operadors, o quan el client final t'exigeix una peça concreta de l'ecosistema. En aquests casos no hi ha debat i nosaltres tampoc no l'obrim.
El que sí que obrim és la factura d'operació, perquè és la part que ningú no posa a la diapositiva: tres finestres de manteniment l'any com a mínim, un inventari de complements que caduquen pel seu compte i amb el seu propi calendari, i la dependència de peces de tercers l'estat de salut de les quals gairebé ningú no audita. Del controlador d'entrada que publicava a internet bona part del sector vam descobrir que mig Kubernetes el mantenien dues persones; avui el seu repositori està arxivat en només lectura. Es va saber quan va caldre mirar-ho, no abans.
Per això, quan ens ho pregunten, acabem en una d'aquestes dues: o Kubernetes amb algú que l'operi de debò —intern o nosaltres—, o Swarm i dedicar el temps que t'estalvies al que sí que mou el teu negoci. La combinació que acaba en trucada d'urgència sempre és la mateixa: Kubernetes muntat per l'equip de producte un trimestre fluix i, després, ningú.
El que no canvia triïs el que triïs
Aquí és on gairebé tot el debat calla, i és on acaben generant-se els incidents. L'orquestrador no et regala cap d'aquestes quatre coses:
| El que continua sent teu | Què passa si no ho fas |
|---|---|
| Fixar les versions de les teves imatges | Qualsevol reinici desplega una cosa que ningú no ha provat |
| Saber qui manté cada peça | Te n'assabentes el dia de l'avís de seguretat |
| Còpies amb restauració provada | Tens un amulet, no una còpia de seguretat |
| Telemetria que avisa per símptomes | El servei fa hores que està trencat i la pantalla de monitoratge continua en verd, perquè mira la portada i no el procés. L'avís arriba per telèfon, i el dona un client. |
La primera fila ens va trencar a nosaltres el desplegament de la nostra pròpia web, i li vam dedicar un post sencer: «latest» no és una versió. Les altres tres són la feina de sempre, la que no apareix a cap taula d'orquestradors perquè no els distingeix. Despleguem tots dos amb el mateix mètode —el desplegament surt d'un repositori, amb la versió fixada i la marxa enrere assajada— precisament perquè l'orquestrador és la part intercanviable.
I l'eix amb què mesurem qualsevol disseny tampoc no canvia: la fallada és inevitable, l'avaria és una decisió de disseny. Una màquina es morirà, triïs l'orquestrador que triïs. Que això sigui paperassa de manteniment o una tarda en què ningú no factura depèn de decisions que algú va prendre mesos abans, i cap d'elles no es diu Swarm ni Kubernetes.
Fonts: el CVE-2026-92542, la fallada de xifratge del pla de dades overlay i la resta d'entrades citades són a les notes de publicació de Docker Engine 29.9.0 (8 d'octubre del 2026), 29.9.1 (14 d'octubre) i 29.8.0 (3 de setembre) — docs.docker.com. El recompte d'entrades que toquen el mode eixam (nou a la 29.9.0 i vuit a la 29.8.0) és nostre, comptant les que esmenten Swarm i les que només afecten xarxes overlay, descobriment de serveis o gossip, que són peces exclusives del mode eixam; el lector pot refer el compte a la mateixa pàgina. El compromís «fins com a mínim el 2030» dins de Mirantis Kubernetes Engine 3 i la feina en CSI, de l'anunci de Mirantis de l'1 de juliol del 2025 — mirantis.com; és una promesa d'un fabricant sobre el seu propi producte de pagament. La política de tres branques mantingudes, la cadència d'unes tres versions menors a l'any i les dates de fi de vida de 1.37, 1.36, 1.35 i 1.34, de la pàgina oficial de versions de Kubernetes — kubernetes.io, consultada el 18 d'octubre del 2026. L'orquestració integrada va arribar al motor a Docker 1.12, anunciada per Docker el 2016 — docker.com; la compra de Docker Enterprise per Mirantis es va anunciar el 13 de novembre del 2019. Les valoracions sobre quan convé cada orquestrador són nostres, surten d'operar-los tots dos en producció i no són una dada: contrasta-les amb el teu cas.
Qui farà el pròxim salt de versió del teu clúster?
Si corres la 1.34, et queden nou dies de pedaços. Operem Kubernetes gestionat i Docker Swarm amb desplegaments reproduïbles i reversibles, i ho sostenim amb suport 24/7. Si el teu cas és dels que no necessiten Kubernetes, t'ho direm.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN