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

El problema empez\u00f3 as\u00ed: ten\u00edamos cinco microservicios, cuatro ingenieros, y un servidor de staging que viv\u00eda en perpetuo caos. Un viernes<\/a> por la tarde decid\u00ed que ya era suficiente y me puse a evaluar orquestadores de contenedores en<\/a> serio. Spoiler: ese fin de semana no dorm\u00ed bien.<\/p>\n

Estuve tres semanas probando Kubernetes<\/a>, Docker Swarm<\/a> y Nomad en escenarios lo m\u00e1s parecidos posible a lo que<\/a> usamos en producci\u00f3n<\/a> \u2014 una API<\/a> REST en Node.js, un par de workers de procesamiento en Python, una base<\/a> de datos<\/a> Postgres con r\u00e9plica, y un reverse proxy con Nginx. No es el stack m\u00e1s glamoroso del mundo, pero es representativo de lo que<\/a> maneja la mayor\u00eda de equipos peque\u00f1os o medianos.<\/p>\n

Lo que encontr\u00e9 no fue lo que<\/a> esperaba.<\/p>\n

Por qu\u00e9 los<\/a> tres siguen siendo opciones v\u00e1lidas (aunque uno se est\u00e1 quedando atr\u00e1s)<\/h2>\n

La narrativa popular en 2026<\/a> es “Kubernetes en<\/a> DigitalOcean” rel=”nofollow sponsored” target=”_blank”>Kubernetes<\/a> gan\u00f3, los dem\u00e1s ya no importan”. Y entiendo de d\u00f3nde viene \u2014 K8s tiene el ecosistema, el soporte empresarial, y pr\u00e1cticamente todos los proveedores cloud tienen su propia versi\u00f3n managed (EKS, GKE, AKS). Pero esa narrativa ignora que Kubernetes<\/a> tiene un costo operacional real que muchos equipos peque\u00f1os no pueden asumir.<\/p>\n

Docker Swarm sigue siendo una opci\u00f3n, aunque su desarrollo se ha frenado bastante. Moby Project lo mantiene vivo, pero no han salido features significativas desde hace tiempo. Si ya usas Docker Compose<\/a> en desarrollo, Swarm te parecer\u00e1 familiar \u2014 demasiado familiar, en el<\/a> mal sentido.<\/p>\n

Nomad es donde me llev\u00e9 la mayor sorpresa. HashiCorp fue adquirida por IBM en 2024 y hubo un momento de incertidumbre, pero el producto en s\u00ed ha seguido madurando. La versi\u00f3n 1.7.x que us\u00e9 tiene mejoras de scheduling que se notan en la pr\u00e1ctica.<\/p>\n

Kubernetes: Poderoso, Pero el Precio es Real<\/h2>\n

Pas\u00e9 unos cinco d\u00edas configurando un cluster de Kubernetes en<\/a> DigitalOcean” rel=”nofollow sponsored” target=”_blank”>Kubernetes<\/a> “desde cero” usando kubeadm, y otro par de d\u00edas probando k3s \u2014 que es b\u00e1sicamente K8s pero dise\u00f1ado para ser m\u00e1s liviano. La diferencia en fricci\u00f3n inicial es enorme.<\/p>\n

Con kubeadm en tres nodos (un master, dos workers en EC2 t3.medium), el tiempo hasta tener el primer pod corriendo fue de aproximadamente 4 horas, incluyendo configurar networking con Flannel, el dashboard, y algunos namespaces b\u00e1sicos. Eso asumiendo que ya sabes lo que<\/a> est\u00e1s haciendo. Si no sabes, multiplica por tres \u2014 y eso sin contar que vas a necesitar buscar por qu\u00e9<\/a> el CNI no levanta en tu versi\u00f3n espec\u00edfica del kernel.<\/p>\n

K3s fue otra historia. Una hora, m\u00e1s o menos, y ya ten\u00eda algo funcional.<\/p>\n

Aqu\u00ed hay un ejemplo de lo que<\/a> termina siendo un Deployment sencillo en K8s. Nada especial, solo para ilustrar la verbosidad:<\/p>\n

# deployment-api.yaml \u2014 versi\u00f3n m\u00ednima para una API<\/a> sin estado\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\n        image: myregistry\/api-service:1.4.2\n        ports:\n        - containerPort: 3000\n        resources:\n          requests:\n            memory: "128Mi"\n            cpu: "100m"\n          limits:\n            memory: "256Mi"\n            cpu: "250m"\n        readinessProbe:\n          httpGet:\n            path: \/health\n            port: 3000\n          initialDelaySeconds: 10\n          periodSeconds: 5\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: api-service\n  namespace: production<\/a>\nspec:\n  selector:\n    app: api-service\n  ports:\n  - port: 80\n    targetPort: 3000\n<\/code><\/pre>\n
Esto es lo<\/a> b\u00e1sico. Ya son 40 l\u00edneas de YAML para algo que no hace nada especial. Necesitas el Deployment, el Service, probablemente un Ingress separado, quiz\u00e1s un ConfigMap para variables de entorno, y si eres cuidadoso, un HorizontalPodAutoscaler. F\u00e1cilmente son 150+ l\u00edneas para una sola aplicaci\u00f3n “sencilla”. La primera vez que lo vi todo junto pens\u00e9 que alguien me estaba gastando una broma.<\/p>\n
Lo que s\u00ed me impresion\u00f3: el rollout de actualizaciones es elegante. Cambias la imagen, aplicas el deployment, y Kubernetes<\/a> hace el rolling update autom\u00e1ticamente. Si el nuevo pod no pasa el readinessProbe, se detiene el rollout. Eso me salv\u00f3 de un problema serio cuando empuj\u00e9 un bug un martes por la noche \u2014 el 30% del tr\u00e1fico ya estaba en la nueva versi\u00f3n cuando me di cuenta, pero el resto nunca lleg\u00f3 a ver el c\u00f3digo roto.<\/p>\n
El ecosistema es otro punto a favor. Helm para packages, Argo CD si quieres GitOps de verdad<\/a>, Prometheus + Grafana para m\u00e9tricas, Cert-manager para TLS autom\u00e1tico con Let’s Encrypt. Todo existe, todo est\u00e1 documentado (aunque la documentaci\u00f3n a veces asume que ya sabes mucho), y hay comunidad para casi cualquier problema.<\/p>\n
El verdadero costo no es la complejidad t\u00e9cnica \u2014 es el overhead cognitivo que no desaparece nunca. Para mantener un cluster de Kubernetes<\/a> en buen estado necesitas entender etcd, los controladores, el scheduler, RBAC, network policies… La lista no termina. En un equipo de 4 personas donde nadie es DevOps de tiempo completo, eso pesa. Y pesa cada sprint, no solo al principio. Cada vez que algo raro pasa en producci\u00f3n<\/a>, la pregunta “\u00bfes el app o es el cluster?” te roba 20 minutos antes de poder empezar a investigar de verdad<\/a>.<\/p>\n
Docker Swarm: La Opci\u00f3n Honesta para Equipos<\/a> Peque\u00f1os<\/h2>\n
Voy a ser directo: Docker Swarm<\/a> es la opci\u00f3n que nadie<\/a> quiere recomendar porque suena a “no sabes usar Kubernetes<\/a>”, pero para un equipo de menos de 5 personas con un stack moderado, funciona bien.<\/p>\n
La configuraci\u00f3n inicial toma 20 minutos. Sin exagerar.<\/p>\n
# En el<\/a> nodo manager\ndocker swarm<\/a> init --advertise-addr <IP_MANAGER>\n\n# Obtienes un token. En los workers:\ndocker swarm<\/a> join --token <TOKEN> <IP_MANAGER>:2377\n\n# Desplegar<\/a> un stack completo desde un Compose file:\ndocker stack deploy<\/a> -c docker-compose.prod.yml myapp\n<\/code><\/pre>\n
Eso es b\u00e1sicamente todo. Si ya tienes un docker-compose.yml<\/code> que funciona en desarrollo, convertirlo en un stack de Swarm es cuesti\u00f3n de a\u00f1adir algunas directivas deploy:<\/code> para definir r\u00e9plicas y pol\u00edticas de restart. No necesitas aprender un nuevo sistema de abstracci\u00f3n desde cero.<\/p>\n
En la pr\u00e1ctica, Swarm maneja bien hasta ~50 contenedores en<\/a> 5-6 nodos sin que la gesti\u00f3n se vuelva dolorosa. El overlay networking funciona sin configuraci\u00f3n adicional. Los secrets se integran de forma nativa con docker secret<\/code>. Y si un nodo muere, Swarm redistribuye los containers autom\u00e1ticamente \u2014 sin que nadie<\/a> tenga que hacer nada.<\/p>\n
Pero hay l\u00edmites claros. No hay autoscaling horizontal nativo basado en m\u00e9tricas. El rollout de updates es b\u00e1sico comparado con K8s. El soporte para stateful workloads es limitado. Y el mayor problema en 2026<\/a> es que la comunidad se est\u00e1 yendo \u2014 cuando busqu\u00e9 ayuda para un problema espec\u00edfico con persistent volumes, los foros estaban en silencio o te mandaban directo a K8s sin m\u00e1s explicaci\u00f3n.<\/p>\n
El desarrollo est\u00e1 estancado, y no de forma discreta. No est\u00e1 muerto, pero tampoco est\u00e1 vivo de forma que inspire confianza para una apuesta a largo plazo. Es como esa librer\u00eda de npm que tiene 4 a\u00f1os sin commits pero todav\u00eda funciona \u2014 en alg\u00fan momento te va a quemar.<\/p>\n
Si tu criterio principal es “quiero algo que funcione esta semana sin contratar a alguien que sepa solo de infra”, Swarm tiene su lugar. Pero si en 6 meses necesitas escalar o a\u00f1adir complejidad, probablemente vas a estar migrando.<\/p>\n
Nomad: Lo Que<\/a> No Esperaba<\/h2>\n
Honestamente, entr\u00e9 al test de Nomad con expectativas bajas. Lo hab\u00eda visto mencionado en algunos threads de Hacker News como “la opci\u00f3n para los que odian Kubernetes pero necesitan m\u00e1s que Swarm”, y eso no suena muy convincente.<\/p>\n
Cambi\u00e9 de opini\u00f3n a los dos d\u00edas.<\/p>\n
La arquitectura de Nomad es distinta. No es solo un orquestador de contenedores \u2014 puede correr binarios directos, JVM apps, Python scripts, y s\u00ed, tambi\u00e9n contenedores Docker o Podman. Para nosotros eso era irrelevante porque todo est\u00e1 containerizado, pero conceptualmente es m\u00e1s flexible.<\/p>\n
El archivo de job en Nomad (HCL, igual que Terraform) es m\u00e1s verboso que un Compose file pero mucho menos que Kubernetes YAML en la pr\u00e1ctica:<\/p>\n
# 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 = 3000\n      }\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    task "api" {\n      driver = "docker"\n\n      config {\n        image = "myregistry\/api-service:1.4.2"\n        ports = ["http"]\n      }\n\n      resources {\n        cpu    = 250  # MHz\n        memory = 256  # MB\n      }\n    }\n  }\n}\n<\/code><\/pre>\n
La integraci\u00f3n con Consul para service discovery es natural \u2014 si ya usas HashiCorp stack, todo encaja. Vault para secrets tambi\u00e9n. Yo no ten\u00eda ninguno de los dos antes, as\u00ed que tuve que configurarlos desde cero, y eso a\u00f1adi\u00f3 un par de horas.<\/p>\n
El momento que me sorprendi\u00f3 fue el canary deployment. Nomad tiene soporte nativo para canary releases y el syntax es directo:<\/p>\n
update {\n  canary       = 1     # un solo canary antes del rollout completo\n  auto_promote = false # no promover autom\u00e1ticamente, quiero confirmarlo\n  auto_revert  = true  # si el canary falla, revertir\n}\n<\/code><\/pre>\n
En K8s eso requiere Argo Rollouts o una configuraci\u00f3n manual con m\u00faltiples Deployments. En Nomad est\u00e1 en el<\/a> job spec. Tres l\u00edneas. Me gust\u00f3 eso m\u00e1s de lo que<\/a> esperaba.<\/p>\n
El gotcha que me encontr\u00e9 \u2014 y lo documento aqu\u00ed porque perd\u00ed tres horas por esto \u2014 la observabilidad out-of-the-box es limitada. La UI es decente, puedes ver el estado de los jobs y los logs de los tasks, pero para m\u00e9tricas serias necesitas integrar Prometheus con el endpoint de Nomad. Hasta ah\u00ed bien. El problema era un error de configuraci\u00f3n en el<\/a> bloque telemetry<\/code> que nadie<\/a> hab\u00eda documentado claramente, y que hac\u00eda que las m\u00e9tricas de jobs espec\u00edficos simplemente no aparecieran. Ning\u00fan error visible. Solo ausencia de datos<\/a> \u2014 el tipo de bug que te hace cuestionar si est\u00e1s configurando mal o si el software est\u00e1 fallando callado. Al final era un campo mal puesto en el<\/a> stanza de telemetry<\/code> del config de Nomad. Lo encontr\u00e9 por accidente comparando dos configs de Stack Overflow que tampoco explicaban por qu\u00e9<\/a> funcionaban.<\/p>\n
Adem\u00e1s \u2014 y esto es<\/a> relevante en 2026<\/a> \u2014 el futuro de Nomad bajo IBM\/HashiCorp no est\u00e1 100% claro para m\u00ed. El enterprise tier se ha vuelto m\u00e1s caro. La versi\u00f3n open source sigue siendo capaz, pero hay features que antes eran gratis y ahora est\u00e1n en el<\/a> tier de pago. No es un problema hoy, pero es algo que hay que tener en mente.<\/p>\n
C\u00f3mo Lo Evalu\u00e9 en N\u00fameros Reales<\/h2>\n
Para comparar operativamente, us\u00e9 el mismo stack en los tres orquestadores durante aproximadamente una semana cada uno, y med\u00ed:<\/p>\n