{"id":126,"date":"2026-03-09T01:43:13","date_gmt":"2026-03-09T01:43:13","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/kubernetes-vs-docker-swarm-vs-nomad-comparacin-de\/"},"modified":"2026-03-18T22:00:22","modified_gmt":"2026-03-18T22:00:22","slug":"kubernetes-vs-docker-swarm-vs-nomad-comparacin-de","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/kubernetes-vs-docker-swarm-vs-nomad-comparacin-de\/","title":{"rendered":"Kubernetes vs Docker Swarm vs Nomad: Comparaci\u00f3n Real de Orquestaci\u00f3n en 2026"},"content":{"rendered":"

Empecemos con algo concreto: ten\u00eda ocho microservicios corriendo en producci\u00f3n<\/a>, tres archivos docker-compose.yml<\/code> que nadie<\/a> entend\u00eda del todo, y un equipo de cuatro personas cansadas de hacer deploys a mano. El sistema funcionaba \u2014 m\u00e1s o menos \u2014 pero cada vez que hab\u00eda que escalar algo, alguien ten\u00eda que conectarse por SSH a un servidor y ejecutar comandos a mano. Eso no escala, y todos lo sab\u00edamos.<\/p>\n

Pas\u00e9 dos semanas<\/a> probando seriamente Kubernetes<\/a>, Docker Swarm<\/a> y Nomad. No en tutoriales de YouTube \u2014 en cargas de trabajo reales, con los mismos servicios, en entornos equivalentes. Lo que<\/a> sigue es lo que<\/a> encontr\u00e9.<\/p>\n

Cuando docker-compose deja de ser suficiente<\/h2>\n

El problema con docker-compose no es que sea malo \u2014 es que no fue dise\u00f1ado para lo que<\/a> terminamos haci\u00e9ndolo hacer. Un archivo compose para desarrollo, otro para staging, otro para producci\u00f3n<\/a> con variables de entorno hardcodeadas en alg\u00fan .env<\/code> que nadie<\/a> sabe d\u00f3nde est\u00e1. Cl\u00e1sico.<\/p>\n

Cuando tus servicios empiezan a necesitar alta disponibilidad, health checks reales, rollbacks autom\u00e1ticos y la posibilidad de distribuirse en varios nodos, necesitas un orquestador. Ah\u00ed es donde entra la elecci\u00f3n que lleva a esta pregunta eterna: \u00bfKubernetes<\/a>, Swarm, o algo m\u00e1s?<\/p>\n

La respuesta honesta es que depende del contexto \u2014 pero no de una manera vaga. Depende de cosas espec\u00edficas que puedo describir con precisi\u00f3n.<\/p>\n

Kubernetes: El sistema que te exige respeto antes de darte resultados<\/h2>\n

Kubernetes es poderoso. Tambi\u00e9n es complicado de una manera que puede sorprenderte si vienes del mundo de docker-compose up<\/code>.<\/p>\n

Empec\u00e9 con un cluster de tres nodos en GKE (Google Kubernetes<\/a> Engine) porque quer\u00eda evitar la parte de gestionar el control plane yo mismo \u2014 eso ya es una decisi\u00f3n importante que muchos ignoran al principio. Y aun as\u00ed, la curva de aprendizaje fue real.<\/p>\n

El modelo de<\/a> recursos de Kubernetes<\/a> es bueno una vez que lo entiendes. Deployments, ReplicaSets, Services, Ingress, ConfigMaps, Secrets \u2014 cada concepto tiene su lugar y su raz\u00f3n de ser. El problema es que para desplegar<\/a> un servicio simple necesitas entender todos a la vez.<\/p>\n

# kubernetes<\/a>\/api-service.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: api-service\n  namespace: production<\/a>\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: api-service\n  template:\n    metadata:\n      labels:\n        app: api-service\n    spec:\n      containers:\n        - name: api-service\n          image: gcr.io\/mi-proyecto\/api-service:v2.4.1\n          resources:\n            requests:\n              memory: "128Mi"\n              cpu: "100m"\n            limits:\n              memory: "256Mi"\n              cpu: "500m"\n          readinessProbe:\n            httpGet:\n              path: \/health\n              port: 8080\n            initialDelaySeconds: 10\n            periodSeconds: 5\n          env:\n            - name: DATABASE_URL\n              valueFrom:\n                secretKeyRef:\n                  name: db-secrets\n                  key: url\n<\/code><\/pre>\n
Esto est\u00e1 bien. Una vez que tienes la plantilla, escalar es cuesti\u00f3n de cambiar replicas<\/code> y hacer kubectl apply<\/code>. Los rollbacks funcionan. El health checking es s\u00f3lido.<\/p>\n
Ahora el “gotcha” que me cost\u00f3 un viernes<\/a> por la noche: los resource limits en Kubernetes<\/a> no son opcionales si te importa la estabilidad del cluster. Un servicio sin l\u00edmites puede consumir toda la memoria de un nodo y matar a sus vecinos. Lo aprend\u00ed de la peor manera \u2014 empuj\u00e9 un deploy<\/a>, el servicio ten\u00eda un memory leak que no hab\u00edamos detectado, y a las<\/a> 2am el cluster empez\u00f3 a tirar pods de otros servicios por OOMKilled. Pas\u00e9 tres horas restaurando cosas que no ten\u00edan nada que ver con el cambio original.<\/p>\n
Desde entonces, sin resources.limits<\/code>, no pasa a producci\u00f3n<\/a>. Sin excepciones.<\/p>\n
Donde Kubernetes<\/a> realmente brilla es en el<\/a> ecosistema. Helm para gesti\u00f3n de paquetes, ArgoCD para GitOps<\/a>, cert-manager para certificados TLS autom\u00e1ticos, Prometheus + Grafana para observabilidad \u2014 todo existe, todo est\u00e1 documentado, hay respuestas en Stack Overflow. No es que las otras opciones no tengan esto; es que Kubernetes tiene m\u00e1s, y con m\u00e1s margen.<\/p>\n
El costo real de Kubernetes no es monetario \u2014 es cognitivo. Para un equipo de cuatro personas donde no todos son especialistas en infraestructura<\/a>, mantener un cluster de Kubernetes significa que alguien tiene que ser el “Kubernetes person”. Eso es un bottleneck que muchos equipos peque\u00f1os subestiman hasta que<\/a> la persona en cuesti\u00f3n se va de vacaciones.<\/p>\n
Docker Swarm: M\u00e1s relevante de lo que<\/a> la gente admite<\/h2>\n
Cuando dije que iba a probar Docker Swarm<\/a> seriamente, un colega me mir\u00f3 como si hubiera dicho que iba a volver a usar SVN. “\u00bfSwarm? \u00bfEn 2026?<\/a>”<\/p>\n
Entiendo el escepticismo. Swarm no tiene el ecosistema de Kubernetes, y hay features que simplemente no existen. Pero para ciertos casos de uso, es genuinamente bueno \u2014 y la gente que lo descarta sin haberlo usado nunca tuvo que operar un cluster de Kubernetes con un equipo de cuatro personas.<\/p>\n
La configuraci\u00f3n es trivial comparada con Kubernetes. Si ya sabes docker-compose<\/code>, sabes el 80% de lo que<\/a> necesitas saber para Swarm. Inicializas el cluster:<\/p>\n
# En el<\/a> manager node\ndocker swarm<\/a> init --advertise-addr 192.168.1.10\n\n# En cada worker node (el token te lo da el comando anterior)\ndocker swarm<\/a> join --token SWMTKN-1-xyz... 192.168.1.10:2377\n\n# Deploy<\/a> con tu archivo compose existente\ndocker stack deploy<\/a> -c docker-compose.prod.yml mi-app\n<\/code><\/pre>\n
Y ya est\u00e1. Los servicios se distribuyen entre nodos, hay health checks b\u00e1sicos, los rollbacks existen. Para ocho servicios en tres nodos, esto funciona perfectamente bien.<\/p>\n
Lo que me sorprendi\u00f3 fue la estabilidad. Swarm es menos complejo que Kubernetes en<\/a> parte porque hace menos cosas, y menos complejidad significa menos superficie para que algo explote. En las dos semanas<\/a> que lo tuve corriendo en el<\/a> entorno de prueba no tuve ning\u00fan problema inesperado \u2014 lo cual, si vienes de operar Kubernetes, es refrescante.<\/p>\n
Las limitaciones son reales, sin embargo. Sin autoscaling horizontal autom\u00e1tico basado en m\u00e9tricas, sin admission controllers, sin la riqueza de opciones de networking que tiene Kubernetes. Si necesitas esas cosas, Swarm te va a quedar chico.<\/p>\n
Un factor que vale mencionar: el ritmo de desarrollo. Docker (ahora parte de Mirantis) sigue manteniendo Swarm, pero las actualizaciones son lentas. No est\u00e1 muerto, pero tampoco est\u00e1 creciendo. Si piensas en los pr\u00f3ximos tres a\u00f1os de tu stack, eso importa.<\/p>\n
Nomad: El que nadie<\/a> menciona y que me cambi\u00f3 la perspectiva<\/h2>\n
Nomad fue la sorpresa de esta comparaci\u00f3n. Lo conoc\u00eda de nombre \u2014 HashiCorp, los mismos de Terraform y Vault \u2014 pero nunca lo hab\u00eda usado en serio. Asum\u00ed que era una alternativa nicho para gente que no quer\u00eda Kubernetes pero tampoco quer\u00eda algo tan b\u00e1sico como Swarm. Estaba equivocado.<\/p>\n
Lo que hace Nomad diferente es conceptualmente importante: no es solo un orquestador de contenedores<\/a>. Puede ejecutar contenedores Docker, s\u00ed, pero tambi\u00e9n aplicaciones Java sin contenedorizar, scripts, trabajos batch, binarios est\u00e1ticos. Si tienes una mezcla de cargas de trabajo \u2014 y muchos equipos la tienen, aunque no lo admitan \u2014 eso es valioso de una manera que Kubernetes no replica bien.<\/p>\n
El modelo de<\/a> configuraci\u00f3n usa HCL (HashiCorp Configuration Language), el mismo que Terraform. Si tu equipo ya usa Terraform, el salto cognitivo es menor de lo que<\/a> esperar\u00edas:<\/p>\n
# jobs\/api-service.nomad\njob "api-service" {\n  datacenters = ["dc1"]\n  type        = "service"\n\n  group "api" {\n    count = 3\n\n    network {\n      port "http" {\n        to = 8080\n      }\n    }\n\n    task "api-service" {\n      driver = "docker"\n\n      config {\n        image = "gcr.io\/mi-proyecto\/api-service:v2.4.1"\n        ports = ["http"]\n      }\n\n      resources {\n        cpu    = 500  # MHz\n        memory = 256  # MB\n      }\n\n      service {\n        name = "api-service"\n        port = "http"\n\n        check {\n          type     = "http"\n          path     = "\/health"\n          interval = "10s"\n          timeout  = "2s"\n        }\n      }\n    }\n  }\n}\n<\/code><\/pre>\n
El deploy<\/a> es nomad job run api-service.nomad<\/code>. El rollback es nomad job revert api-service 1<\/code>. Limpio.<\/p>\n
Donde Nomad realmente se distingue es en la integraci\u00f3n con el resto del stack de HashiCorp. Consul para service discovery y service mesh, Vault para secrets management \u2014 juntos forman un sistema bastante completo. Si ya usas esas herramientas (y mucha gente que usa Terraform ya las usa, aunque sea sin darse cuenta), Nomad encaja naturalmente en lugar de llegar como un elemento extra\u00f1o.<\/p>\n
El ecosistema es m\u00e1s peque\u00f1o que el de Kubernetes, eso es verdad. Cuando tuve un problema con el scheduler asignando tareas de manera sub\u00f3ptima, tard\u00e9 el doble en encontrar la respuesta de lo que<\/a> me habr\u00eda costado con Kubernetes. Menos comunidad significa m\u00e1s tiempo buscando solo.<\/p>\n
Lo que realmente<\/a> importa al elegir<\/h2>\n
Aqu\u00ed est\u00e1 el patr\u00f3n que vi en las dos semanas<\/a> de prueba:<\/p>\n
Swarm<\/strong> tiene sentido<\/a> si tu equipo ya sabe Docker, no tienes especialistas en infraestructura<\/a>, y tus necesidades son relativamente estables. Tres a diez servicios, sin autoscaling complejo en el<\/a> horizonte \u2014 Swarm te da el 80% de los beneficios de Kubernetes con el 20% de la complejidad. No lo descartes por ser “viejo”. La madurez a veces es exactamente lo que<\/a> necesitas.<\/p>\n
Kubernetes<\/strong> se justifica cuando el equipo puede sostener el conocimiento \u2014 ya sea contratando a alguien que lo sepa o invirtiendo tiempo real en aprenderlo (y asumiendo que esa persona va a seguir ah\u00ed). Tambi\u00e9n cuando el ecosistema importa: GitOps con ArgoCD, service mesh con Istio, integraci\u00f3n con managed services de cloud. El costo de adopci\u00f3n se amortiza si lo usas al m\u00e1ximo. Si lo usas al 20% de su capacidad, est\u00e1s pagando complejidad que no te<\/a> da nada a cambio.<\/p>\n
Nomad<\/strong> es interesante para equipos<\/a> que ya tienen Consul y Vault \u2014 la coherencia de herramientas tiene un valor real que no aparece en ning\u00fan benchmark. Tambi\u00e9n para cargas de trabajo mixtas donde no todo lo que<\/a> corres es un contenedor<\/a> Docker. Y francamente, para cualquiera que quiera la experiencia operacional limpia de Swarm pero sin preocuparse por el ritmo de desarrollo futuro.<\/p>\n
Mi equipo termin\u00f3 con Kubernetes gestionado \u2014 GKE espec\u00edficamente \u2014 porque ya ten\u00edamos la infraestructura<\/a> en GCP y el ecosistema justificaba el costo de aprendizaje dado que vamos a escalar bastante en los pr\u00f3ximos meses. Pero si empezara de cero con un equipo peque\u00f1o trabajando en algo que no necesita escalar agresivamente, elegir\u00eda Nomad + Consul antes que Kubernetes. La experiencia operacional es m\u00e1s limpia, y no me despertar\u00eda a las<\/a> 2am por un memory leak que se comi\u00f3 el nodo entero.<\/p>\n
Lo que no recomendar\u00eda es elegir Kubernetes por defecto porque “es el est\u00e1ndar”. Es el est\u00e1ndar en equipos grandes con infraestructura<\/a> compleja \u2014 no necesariamente el est\u00e1ndar para tu situaci\u00f3n. La complejidad que trae tiene que justificarse con los problemas que resuelve, y en muchos proyectos que conozco, Swarm o Nomad hubieran sido la decisi\u00f3n correcta desde el principio.<\/p>\n
Eso es lo que<\/a> dos semanas<\/a> de prueba real me dejaron. Tu setup va a ser diferente, tus constraints van a ser otros \u2014 pero al menos tienes algo m\u00e1s que benchmarks de marketing para tomar la decisi\u00f3n.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Empecemos con algo concreto: ten\u00eda ocho microservicios corriendo en producci\u00f3n , tres archivos docker-compose.yml que nadie entend\u00eda del todo, y un equipo <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-126","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=126"}],"version-history":[{"count":27,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/126\/revisions"}],"predecessor-version":[{"id":657,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/126\/revisions\/657"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}