Si administrás un cloud propio, tarde o temprano aparece la misma pregunta: ¿necesito la maquinaria completa de Kubernetes o me alcanza con algo más liviano? En 2026 la comparación tiene nombres y versiones concretas: Nomad 2.0, el orquestador de HashiCorp que corre como un único binario, contra Kubernetes 1.35, que sigue sumando features a costa de más piezas para operar. No hay un ganador absoluto: hay contextos. Esta nota compara arquitectura, operación diaria, footprint, licencia y el veredicto con matices.
Nomad es un orquestador de cargas de trabajo de HashiCorp (hoy parte de IBM) que despliega, escala y supervisa contenedores, binarios, aplicaciones Java y hasta VMs desde un solo binario, sin base de datos externa. Kubernetes es la plataforma de orquestación de contenedores de la CNCF: un plano de control con API server, etcd, scheduler y controller manager. Ambos resuelven el mismo problema —correr cargas de forma declarativa en un clúster— con filosofías opuestas.
¿Qué problema resuelven un orquestador como Nomad o Kubernetes?
Los dos automatizan el ciclo de vida de tus cargas: deciden en qué nodo corre cada tarea, la reinician si se cae, la reprograman si un nodo muere y te dan una forma declarativa de describir el estado deseado. La diferencia no está en qué hacen, sino en cuánto tenés que operar para lograrlo.
- Kubernetes apunta a ser un "sistema operativo de la nube". Trae DNS interno, API de Ingress, API de Secrets y un ecosistema enorme de la CNCF. Esa amplitud es su fuerza y, a la vez, su carga operativa.
- Nomad sigue la filosofía Unix: hacer una cosa bien. Es solo un scheduler. Si querés service mesh, secretos o red avanzada, los agregás con Consul, Vault u otras piezas, pero no vienen impuestos.
¿Qué cambió en Nomad 2.0 en 2026?
Nomad 2.0.0 salió el 17 de abril de 2026 y su cambio más visible es el modelo de versionado, no una ruptura de arquitectura. Según las release notes oficiales de Nomad, la versión abandona el semver clásico y adopta el modelo V.M.F (Version-Modification-Fix) de IBM, con feature releases en abril y octubre y parches mensuales; el soporte extendido llega hasta abril de 2032.
- Migración de almacenamiento Raft a WAL. Un comando nuevo migra el backend interno de BoltDB a Write-Ahead Log, pensado para clústeres con mucha escritura.
- Aislamiento de filesystem más estricto. Desde 2.0.1, los directorios de logs de los task drivers con aislamiento (como Docker) se montan de solo lectura.
- Control de ejecución de jobs. El campo
max_run_durationpara jobs batch y system batch, con métricas asociadas, llegó en 2.0.3. - Deprecaciones a tener en cuenta. Los parámetros
server.retry_join,retry_interval,retry_maxystart_joinquedan deprecados para removerse en 2.1.0; hay que migrar aserver.server_join.
Lo importante: la propuesta de valor de Nomad no cambió. Sigue siendo un único binario para clientes y servidores, sin servicios externos para coordinación ni storage, como describe la documentación oficial de HashiCorp.
¿Qué trae Kubernetes 1.35 y qué deja afuera?
Kubernetes 1.35 está planificada para diciembre de 2025 y su titular es la limpieza de deuda técnica: elimina y deprecia funcionalidades legacy que arrastraba hace años. De acuerdo con el sneak peek oficial de Kubernetes, estos son los cambios que más impactan en un clúster self-hosted:
- cgroup v1 removido, no deprecado. El kubelet directamente no arranca en nodos con cgroup v1. cgroup v2 es estable desde la 1.25, así que la migración ya debería estar hecha.
- Modo ipvs deprecado. Se marca para remoción futura; la recomendación es migrar a
nftables, estable desde la 1.33. - Fin de containerd 1.x en el horizonte. La 1.35 es la última versión que soporta containerd 1.x: hay que pasar a 2.x antes de la 1.36.
Si venís siguiendo el blog, esto amplía lo que ya cubrimos en "Kubernetes 1.35 deja afuera cgroup v1, ipvs y containerd 1.x". La lectura que importa para esta comparación es que cada release de Kubernetes trae migraciones obligatorias: son parte del costo de operarlo.
Nomad 2.0 vs Kubernetes 1.35 lado a lado
Esta tabla resume las diferencias de fondo. Ninguna fila decide sola: pesan distinto según tu equipo y tu infraestructura.
| Criterio | Nomad 2.0 | Kubernetes 1.35 |
|---|---|---|
| Arquitectura | Un solo binario, cliente y servidor | Plano de control multi-componente (API server, scheduler, controller manager) |
| Dependencias externas | Ninguna (Raft embebido, sin etcd) | Requiere etcd |
| Cargas soportadas | Contenedores, binarios, Java, VMs (driver QEMU nativo) | Contenedores; VMs vía plugin (KubeVirt) |
| Curva de aprendizaje | Días, para equipos generalistas | Meses; suele requerir perfiles de plataforma/SRE |
| Footprint | Bajo; corre en hardware modesto | Alto; overhead de plano de control y agentes |
| Ecosistema | Acotado; se extiende con Consul/Vault | Enorme (CNCF), integraciones para todo |
| Licencia | BSL 1.1 (source-available) | Apache 2.0 (open source, Linux Foundation) |
¿Cuánto cuesta operar cada uno en el día a día?
El costo real no aparece en el "Día 1" del despliegue, sino en el "Día 2" del mantenimiento. Según el análisis Kubernetes vs Nomad 2026 de CloudOptimo, ahí es donde las filosofías se separan de verdad.
- Kubernetes tiene un "impuesto operativo" alto. Deprecaciones frecuentes de API y upgrades obligatorios de clúster que, en palabras del análisis de CloudOptimo (2026), pueden "frenar el desarrollo de producto durante semanas".
- Nomad lo puede llevar un equipo lean. El mismo informe señala que puede ser gestionado por desarrolladores generalistas, con aprendizaje medido en días.
- El plano de control gestionado tiene precio. Los servicios gestionados de Kubernetes suelen cobrar una tarifa por hora del plano de control (del orden de US$0,10/hora en varios de ellos, según CloudOptimo), más el compute extra de agentes de logging, red y seguridad.
¿Cuándo conviene Nomad y cuándo Kubernetes?
La respuesta corta: elegí por equipo y por tipo de carga, no por hype. Nomad gana en simplicidad para equipos chicos y cargas mixtas; Kubernetes gana en ecosistema y estandarización para organizaciones con capacidad de plataforma.
- Nomad 2.0 es mejor si... tenés un equipo chico sin SRE dedicado, corrés cargas mixtas (contenedores + binarios legacy + alguna VM), operás en el borde o con hardware limitado, o ya usás el stack de HashiCorp. En un cloud propio donde bancar etcd duele, el binario único es una ventaja concreta.
- Kubernetes 1.35 es mejor si... tu mundo es microservicios containerizados, necesitás integraciones de la CNCF, querés una skill estandarizada en el mercado laboral, o exigís gobernanza open source bajo la Linux Foundation.
Un matiz honesto: el argumento más fuerte contra Nomad en 2026 no es Kubernetes en sí, sino Kubernetes gestionado. Cuando el proveedor cloud se encarga del plano de control, de los upgrades y de etcd, buena parte de la ventaja de Nomad en simplicidad operativa se diluye. La comparación cambia según si te lo autogestionás vos o no. Si querés arrancar liviano con Kubernetes sin todo el peso, mirá también nuestra nota "K3s: instalar un clúster ligero de Kubernetes en un servidor".
¿Qué licencia tiene cada orquestador?
Kubernetes es Apache 2.0, plenamente open source y gobernado por la Linux Foundation. Nomad es source-available bajo BSL 1.1, no open source estricto. Es una diferencia de fondo si te importa la gobernanza.
- El cambio de Nomad es previo a IBM. Según el material oficial de HashiCorp, la BSL 1.1 se adoptó el 10 de agosto de 2023 para todos sus productos; la adquisición de HashiCorp por parte de IBM (US$6.400 millones) se cerró después.
- Qué permite la BSL. Uso no productivo libre, y uso comercial con condiciones; el código transiciona a open source en la Change Date o al cuarto aniversario del release, lo que ocurra primero.
- Para el 99% de los equipos no cambia nada. Salvo que ofrezcas un servicio gestionado de Nomad que compita con HashiCorp, podés usarlo en producción sin problema.
Preguntas frecuentes
¿Nomad necesita etcd como Kubernetes?
No. Nomad usa Raft embebido en su propio binario y no requiere etcd ni ninguna base de datos externa. Ese es justamente uno de sus argumentos de simplicidad frente a Kubernetes, que sí depende de etcd para el plano de control.
¿Nomad puede correr cargas que no sean contenedores?
Sí. Nomad soporta de forma nativa contenedores Docker, binarios sueltos, aplicaciones Java (JAR) y máquinas virtuales mediante su driver QEMU. Kubernetes está centrado en contenedores y necesita plugins como KubeVirt para VMs.
¿Es Nomad open source?
No en sentido estricto. Desde agosto de 2023 se distribuye bajo Business Source License 1.1 (source-available), mientras que Kubernetes sigue siendo Apache 2.0, plenamente open source bajo la Linux Foundation.
¿Qué elimina Kubernetes 1.35 que pueda romper mi clúster?
Remueve por completo el soporte de cgroup v1: el kubelet no arranca en nodos que lo usen. Además deprecia el modo ipvs (migrá a nftables) y anuncia que es la última versión con soporte de containerd 1.x.
¿Cuándo salieron Nomad 2.0 y Kubernetes 1.35?
Nomad 2.0.0 se publicó el 17 de abril de 2026, según sus release notes oficiales. Kubernetes 1.35 está planificada para diciembre de 2025, según el sneak peek oficial del proyecto. Verificá siempre la versión de parche actual en los sitios oficiales antes de desplegar.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
