{"id":495,"date":"2026-03-09T10:38:14","date_gmt":"2026-03-09T10:38:14","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/kubernetes-vs-docker-swarm-vs-nomad-container-orch\/"},"modified":"2026-03-18T22:31:27","modified_gmt":"2026-03-18T22:31:27","slug":"kubernetes-vs-docker-swarm-vs-nomad-container-orch","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/kubernetes-vs-docker-swarm-vs-nomad-container-orch\/","title":{"rendered":"Kubernetes vs Docker Swarm vs Nomad: Lo Que Nadie Te Cuenta Hasta Que Pierdes un Viernes"},"content":{"rendered":"

Hace unos seis meses, mi equipo ten\u00eda un problema cl\u00e1sico de startup: doce microservicios corriendo en EC2 con Docker Compose<\/a> y un script de deploy bash que tres de los cuatro ingenieros ten\u00edamos miedo de tocar. No era que no funcionara \u2014 es que cuando fallaba, fallaba de formas que tard\u00e1bamos dos horas en diagnosticar. Nadie ten\u00eda ganas de abrir ese script los lunes por la ma\u00f1ana.<\/p>\n

Decid\u00ed hacer algo que no recomendar\u00eda a nadie con deadlines ajustados: evaluar tres herramientas de orquestaci\u00f3n en<\/a> paralelo. Dos semanas<\/a> serias con cada una, un mes adicional con la finalista en staging, y despu\u00e9s la migraci\u00f3n real. Este post es lo que<\/a> encontr\u00e9 \u2014 incluyendo la parte donde cambi\u00e9 de opini\u00f3n a mitad de camino.<\/p>\n

El problema con evaluar esto “objetivamente”<\/h2>\n

Antes de entrar en comparaciones, tengo que ser honesto sobre algo: estas herramientas son tan distintas en filosof\u00eda que comparar m\u00e9tricas directas es un poco trampa. Kubernetes 1.35 y Nomad 1.9 no compiten exactamente en el mismo espacio. Uno es un sistema de orquestaci\u00f3n de contenedores<\/a> con un modelo de<\/a> recursos muy opinado; el otro es un scheduler de workloads que maneja contenedores como uno m\u00e1s entre varios tipos. Docker Swarm<\/a> es, bueno, Docker Swarm<\/a>.<\/p>\n

As\u00ed que en lugar de hacer una tabla con checkboxes, voy a contar lo que realmente<\/a> me import\u00f3: cu\u00e1nto tiempo tard\u00e9 en entender qu\u00e9 hab\u00eda fallado cuando algo romp\u00eda, qu\u00e9 tan f\u00e1cil era onboardear a un ingeniero nuevo, y si pod\u00eda dormir los viernes despu\u00e9s de<\/a> un deploy.<\/p>\n

Kubernetes 1.35: el ecosistema que te consume antes de desplegar nada<\/h2>\n

Yo ven\u00eda con experiencia b\u00e1sica en K8s \u2014 hab\u00eda usado EKS en un trabajo anterior, pero siempre con un equipo de DevOps dedicado que manejaba el plano de control. Esta vez \u00edbamos a manejarlo nosotros mismos con kOps 1.29 en AWS.<\/p>\n

El primer d\u00eda con 1.35 es impresionante en el mal sentido. No porque la herramienta sea mala, sino porque la distancia entre “tengo un contenedor corriendo” y “tengo un sistema de producci\u00f3n razonable” es brutal. Necesitas entender Deployments, Services, Ingress, NetworkPolicies, RBAC, PersistentVolumeClaims… y ninguno de esos conceptos se explica solo con mirar el otro.<\/p>\n

# Esto parece simple hasta que tienes que debuggear por qu\u00e9<\/a> el pod no arranca\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: payment-service\n  namespace: production\n  annotations:\n    # Esta annotation la a\u00f1ad\u00ed despu\u00e9s de<\/a> un incidente un viernes a las 6pm\n    kubernetes.io\/change-cause: "v2.4.1 - fix race condition en procesamiento de webhooks"\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: payment-service\n  template:\n    spec:\n      containers:\n      - name: payment-service\n        image: myrepo\/payment-service:2.4.1\n        resources:\n          requests:\n            memory: "256Mi"\n            cpu: "100m"\n          limits:\n            memory: "512Mi"\n            # Sin este l\u00edmite, un bug en prod te come el nodo entero. Aprendido por las malas<\/a>.\n            cpu: "500m"\n        readinessProbe:\n          httpGet:\n            path: \/health\n            port: 8080\n          initialDelaySeconds: 10\n          periodSeconds: 5\n<\/code><\/pre>\n
Lo que no me esperaba fue quedarme atascado en el networking. Pas\u00e9 tres d\u00edas completos entendiendo la diferencia entre ClusterIP, NodePort, LoadBalancer e Ingress. No tres d\u00edas porque la documentaci\u00f3n sea mala (es excelente), sino porque son cuatro abstracciones para el mismo problema y ninguna es la respuesta correcta en todos los casos.<\/p>\n
Y despu\u00e9s est\u00e1 la pregunta del service mesh. Cilium, Istio, Linkerd. Fui al Slack de Kubernetes (#sig-network, si alguien quiere perder horas de su vida) y sal\u00ed m\u00e1s confundido que antes. Al final us\u00e9 Cilium porque era la opci\u00f3n recomendada en la documentaci\u00f3n de kOps 1.29, pero no te<\/a> voy a mentir: a\u00fan no tengo 100% claro qu\u00e9 hace Cilium que los NetworkPolicies nativos no hacen, m\u00e1s all\u00e1 de la observabilidad. Pens\u00e9 que lo entend\u00eda, pero result\u00f3 que lo que<\/a> me importaba no era el service mesh \u2014 era el modelo de<\/a> deployment y el ciclo de debugging.<\/p>\n
Donde K8s s\u00ed te compensa el sufrimiento inicial es en observabilidad. Prometheus Operator m\u00e1s Grafana m\u00e1s Loki stack es lo mejor que he visto para diagnosticar problemas en producci\u00f3n<\/a>. Puedes decir “el pod X se reinici\u00f3 tres veces<\/a> entre las 2am y las 3am, aqu\u00ed est\u00e1n los logs y aqu\u00ed est\u00e1 la m\u00e9trica de memoria que caus\u00f3 el OOM kill” \u2014 y eso vale much\u00edsimo a las 3am.<\/p>\n
Para equipos grandes, K8s es pr\u00e1cticamente inevitable. Para un equipo de cuatro con doce servicios, est\u00e1s comprando un sistema para un problema que todav\u00eda no tienes.<\/p>\n
Docker Swarm en 2026:<\/a> no est\u00e1 muerto, pero huele raro<\/h2>\n
Fui a Swarm con prejuicios. Esperaba una herramienta desactualizada que me hiciera perder el tiempo.<\/p>\n
Lo que encontr\u00e9 fue m\u00e1s complicado. Docker Swarm<\/a> en Docker Engine 27.x funciona. El setup fue el m\u00e1s r\u00e1pido de los tres \u2014 docker swarm init<\/code>, a\u00f1adir los nodos workers, y ten\u00eda un cluster operativo en menos de veinte minutos. La sintaxis de docker-compose.yml como base para los stack files es bastante c\u00f3moda si ya conoces Docker. Ah\u00ed est\u00e1 la trampa.<\/p>\n
# docker-stack.yml \u2014 casi id\u00e9ntico a tu compose de desarrollo. Eso es la trampa.\nversion: "3.9"\nservices:\n  api-gateway:\n    image: myrepo\/api-gateway:1.8.3\n    ports:\n      - "443:443"\n    deploy:\n      replicas: 2\n      update_config:\n        parallelism: 1\n        delay: 10s\n        failure_action: rollback  # Esto s\u00ed funciona bien\n      restart_policy:\n        condition: on-failure\n        max_attempts: 3\n    # Aqu\u00ed empieza el problema: esto es<\/a> pr\u00e1cticamente todo lo que tienes.\n    # Sin NetworkPolicies granulares. Sin RBAC real. Sin admission controllers.\n<\/code><\/pre>\n
El problema no es lo que<\/a> Swarm hace. Es lo que<\/a> no hace y lo que no va a hacer, porque el desarrollo pr\u00e1cticamente se detuvo. La \u00faltima vez que revis\u00e9 el repositorio de Moby en GitHub, los issues m\u00e1s votados sobre Swarm llevaban meses sin actividad del equipo. Hay una PR de mejoras al networking overlay que lleva m\u00e1s de un a\u00f1o abierta. Eso me dice algo.<\/p>\n
La observabilidad tambi\u00e9n es floja. Puedes integrar Prometheus con las m\u00e9tricas del daemon de Docker, pero no hay equivalente al Prometheus Operator ni a los dashboards predefinidos de Grafana para Swarm. Terminas construyendo m\u00e1s infraestructura de monitoreo de la que quieres, para una herramienta que no va a crecer contigo.<\/p>\n
\u00bfCu\u00e1ndo usar\u00eda Swarm hoy? Si ya tengo un cluster en producci\u00f3n<\/a> que funciona y no tengo una raz\u00f3n concreta para migrarlo. En ning\u00fan otro caso empezar\u00eda algo nuevo con \u00e9l.<\/p>\n
Nomad 1.9: el que cambi\u00f3 mis planes a mitad de la evaluaci\u00f3n<\/h2>\n
Nomad fue el que menos conoc\u00eda. Lo hab\u00eda visto mencionado en algunos hilos de Hacker News, pero en mi mundo \u2014 startups de fintech en LATAM \u2014 nadie lo usaba, o al menos nadie hablaba de \u00e9l en p\u00fablico.<\/p>\n
Lo primero que te impacta es lo simple que es el modelo mental. Un servidor de Nomad tiene tres conceptos: Jobs, Task Groups y Tasks. Un Job describe qu\u00e9 quieres correr. Un Task Group agrupa tasks que deben ir en el mismo nodo. Una Task es la unidad de trabajo individual \u2014 puede ser un contenedor Docker, un proceso Java, un script bash, o incluso un plugin de terceros. Eso es todo. No hay doce tipos de objetos que aprender.<\/p>\n
# Este job file fue el primero que escrib\u00ed y funcion\u00f3 casi sin modificaciones en staging\njob "payment-service" {\n  datacenters = ["dc1"]\n  type        = "service"\n\n  group "api" {\n    count = 3\n\n    network {\n      port "http" { to = 8080 }\n    }\n\n    # Consul maneja el service discovery autom\u00e1ticamente \u2014 no tienes que configurar nada extra\n    service {\n      name = "payment-service"\n      port = "http"\n      check {\n        type     = "http"\n        path     = "\/health"\n        interval = "10s"\n        timeout  = "2s"\n      }\n    }\n\n    task "server" {\n      driver = "docker"\n      config {\n        image = "myrepo\/payment-service:2.4.1"\n        ports = ["http"]\n      }\n      resources {\n        cpu    = 500  # MHz\n        memory = 256  # MB\n      }\n    }\n  }\n}\n<\/code><\/pre>\n
La integraci\u00f3n con Consul para service discovery me dej\u00f3 impresionado. En K8s, el service discovery interno v\u00eda CoreDNS funciona bien, pero cuando algo falla en la resoluci\u00f3n de nombres a veces no est\u00e1 claro si el problema es DNS, el Service object, o el Endpoint. Con Nomad y Consul, el registro es visible y directo \u2014 puedo ver exactamente qu\u00e9 est\u00e1 registrado, cu\u00e1ndo, y en qu\u00e9 estado.<\/p>\n
Igual tengo que contarlo: el modelo de<\/a> networking de Nomad no incluye un overlay network integrado por defecto. Tienes opciones \u2014 CNI plugins, Consul Connect para mTLS entre servicios \u2014 pero no hay una soluci\u00f3n predeterminada como la que K8s ofrece. Tard\u00e9 d\u00eda y medio en entender que lo que yo asum\u00eda como una caracter\u00edstica incluida era algo que ten\u00eda que configurar expl\u00edcitamente. Me sent\u00ed un poco tonto, pero tambi\u00e9n… creo que prefiero que las cosas sean expl\u00edcitas.<\/p>\n
Sobre la licencia BSL de HashiCorp (ahora IBM, desde la adquisici\u00f3n en 2024): sigue siendo un punto de tensi\u00f3n real en la comunidad. Para un startup sin planes de competir con HashiCorp como proveedor de servicios gestionados, en la pr\u00e1ctica no importa. Pero si vendes infraestructura, habla con un abogado antes de comprometerte.<\/p>\n
El debugging a las 11pm: la m\u00e9trica que falta en los benchmarks<\/h2>\n
Ning\u00fan benchmark te va a ayudar a entender qu\u00e9 tan f\u00e1cil es diagnosticar un problema cuando ya son las once de la noche y tienes alertas en el tel\u00e9fono.<\/p>\n
Aprend\u00ed esto de la manera dif\u00edcil. Empuj\u00e9 un cambio de configuraci\u00f3n de<\/a> Nomad un viernes por la tarde \u2014 un ajuste de<\/a> resource limits que parec\u00eda completamente inocuo \u2014 y dos horas despu\u00e9s empezaron las alertas de que el servicio de notificaciones no procesaba mensajes. El problema result\u00f3 ser que hab\u00eda bajado demasiado el l\u00edmite de memoria y el proceso Java mor\u00eda silenciosamente. En Nomad pude ver el allocation log directamente con nomad alloc logs <alloc-id><\/code>, sin navegar entre namespaces o cambiar contextos de kubectl.<\/p>\n
Con K8s, el debugging es m\u00e1s potente pero m\u00e1s laber\u00edntico. kubectl describe pod<\/code>, kubectl logs --previous<\/code>, eventos del namespace, el dashboard de Lens si lo tienes configurado… hay muchos lugares donde puede estar la informaci\u00f3n. Con Nomad todo estaba en un lugar, aunque ese lugar tuviera menos informaci\u00f3n total.<\/p>\n
Esto no es objetivamente mejor o peor. Es una tradeoff real: K8s tiene m\u00e1s informaci\u00f3n disponible pero distribuida; Nomad tiene menos informaci\u00f3n pero m\u00e1s concentrada. Para cuatro personas, la concentraci\u00f3n gan\u00f3.<\/p>\n
Una advertencia que no puedo ignorar: no s\u00e9 c\u00f3mo se comporta Nomad con 500 nodos y cargas de trabajo de empresas muy grandes. Hay casos documentados (Cloudflare lo us\u00f3 durante a\u00f1os antes de migrar<\/a> a K8s), pero mi experiencia personal termina alrededor de 15 nodos. Tu situaci\u00f3n puede ser completamente diferente.<\/p>\n
Qu\u00e9 usar\u00eda hoy, sin rodeos<\/h2>\n
Para un equipo de cuatro personas con doce microservicios en AWS: Nomad 1.9 con Consul<\/strong>.<\/p>\n
Llevamos tres meses en producci\u00f3n<\/a> con esta combinaci\u00f3n. El tiempo de onboarding para el cuarto ingeniero del equipo fue un d\u00eda \u2014 comparado con la semana que yo mismo necesit\u00e9 para tener un criterio razonable sobre K8s. Los deploys son predecibles. El debugging nocturno (que no ha desaparecido, seamos realistas) es manejable sin necesitar abrir cinco pesta\u00f1as distintas.<\/p>\n
Esta recomendaci\u00f3n viene con una condici\u00f3n importante, no opcional: si en los pr\u00f3ximos doce meses el equipo crece a diez o m\u00e1s ingenieros, o si necesitamos networking L7 complejo \u2014 m\u00faltiples tenants, pol\u00edticas de seguridad por namespace, service mesh a gran escala \u2014 vamos a migrar a K8s. No porque Nomad no pueda manejarlo t\u00e9cnicamente, sino porque el ecosistema de K8s para esos problemas espec\u00edficos es mucho m\u00e1s maduro, y encontrar ingenieros con experiencia es significativamente m\u00e1s f\u00e1cil.<\/p>\n
Docker Swarm no entrar\u00eda en mi consideraci\u00f3n para nada nuevo. El ahorro de complejidad versus Nomad no es suficiente para compensar el riesgo de quedar atrapado en una<\/a> herramienta sin desarrollo activo.<\/p>\n
La versi\u00f3n corta: equipos peque\u00f1os con microservicios moderados \u2192 Nomad. Equipos medianos o grandes, o que crecen r\u00e1pido \u2192 K8s y acepta el costo operacional como parte del trabajo. Swarm \u2192 solo si ya lo tienes, funciona, y no tienes una raz\u00f3n concreta para cambiar.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Hace unos seis meses, mi equipo ten\u00eda un problema cl\u00e1sico de startup: doce microservicios corriendo en EC2 con Docker Compose y un script de deploy bash qu<\/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-495","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/495","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=495"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/495\/revisions"}],"predecessor-version":[{"id":774,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/495\/revisions\/774"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=495"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=495"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=495"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}