La Gran Mentira de Kubernetes: Desmontando el Hype con la Suite de HashiCorp

La Mentira

Nos han vendido una mentira industrial.

Te han repetido hasta el cansancio que, para desplegar software moderno, necesitas la complejidad de Google. Te han dicho que si no usas Kubernetes (K8s), tu infraestructura es "legacy", irrelevante o amateur. Te han convencido de que sacrificar 4GB de RAM solo para mantener vivo el plano de control es "el costo de hacer negocios".

La realidad es más oscura: Kubernetes es un monstruo de sobre-ingeniería diseñado para venderte nubes costosas y horas de consultoría eterna.

La "Herejía" que propongo hoy es simple: No necesitas esa complejidad. Puedes tener orquestación, descubrimiento de servicios, balanceo de carga y escalado automático consumiendo una fracción de los recursos y con una curva de aprendizaje humana.

Hoy vamos a desmontar el mito. Vamos a levantar una infraestructura completa usando la "Vía HashiCorp" (Nomad & Consul) sobre un entorno hostil (WSL2), y vamos a probar su resistencia con fuego real (k6).

La Estrategia: "Componentes que hacen una sola cosa"

En lugar de capas infinitas de abstracción opaca, usaremos componentes que siguen la filosofía UNIX: hacer una cosa y hacerla perfecta.

1. El Cerebro (Nomad): Orquestación simple. Un solo binario. Sin etcd, sin nodos maestros que devoran memoria.

2. El Mapa (Consul): Service Discovery. Si un microservicio respira, Consul sabe dónde vive.

3. El Enrutador (Fabio): Un balanceador de carga que se configura solo leyendo el mapa de Consul. Cero configuración manual.

4. El Músculo (Quarkus): Microservicios Java que arrancan en milisegundos, no en minutos.

5. El Terreno (WSL2): El campo de batalla. Un entorno Linux real, sin la pesadez de una VM tradicional.

Fase 1: El Monolito Frágil (Lo que la mayoría hacemos)

Para entender la solución, primero debemos ver el problema. La mayoría de los desarrolladores desplegamos así: Un nodo. Un puerto fijo. Una base de datos.

Este es nuestro archivo monolith.nomad. Es funcional, pero es un castillo de naipes. Al menos funciona para un "Hola Mundo".

group "backend" {
    count = 1  # El punto único de fallo
    network {
      port "http" { static = 8080 } # Puerto rígido
    }
    # ...

Si ejecuto esto, funciona. Puedo llamar a localhost:8080 y Quarkus responde. Pero, ¿qué pasa si el proceso falla? ¿Qué pasa si recibo más tráfico del que un solo hilo puede manejar?

Hice la prueba. Lancé un ataque con k6 y maté el proceso manualmente. Resultado: Connection Refused. El servicio murió instantáneamente (obviamente). Tiempo de inactividad total. Pérdida de dinero.

Esta es la fragilidad que te obliga a buscar "orquestadores". Y aquí es donde K8s te atrapa. Pero hay otra salida.

Fase 2: La Evolución (El Clúster Resiliente)

Aquí es donde rompemos la Matrix. Vamos a transformar ese monolito en un sistema distribuido, tolerante a fallos y auto-balanceado.

Para lograrlo en WSL2 (que tiene una red notoriamente aislada), tuve que usar una técnica poco documentada. Tuve que romper la cuarta pared.

En lugar de crear redes virtuales complejas (Overlay Networks) como hace K8s con Flannel o Calico, le ordenamos a nuestros contenedores que se anuncien con la IP real del host.

El Código de la Victoria (stack.nomad):

service {
  name = "api-quarkus"
  address_mode = "host" #   La clave de la simplicidad. Sin proxys.
  
  tags = [
    "urlprefix-/api",   #  Fabio lee esto y enruta el tráfico. Magia.
    "quarkus"
  ]
}

Al desplegar esto, ocurren tres cosas simultáneamente:

1. Nomad levanta 3 réplicas de Quarkus en puertos aleatorios.

2. Consul detecta que están vivas (Health Check).

3. Fabio ve la etiqueta urlprefix-/api y automáticamente empieza a repartir tráfico entre las 3.

Sin reiniciar el balanceador. Sin escribir archivos de configuración de Nginx. Sin YAMLs de 500 líneas.

Estado de los nodos:

Estado del balanceador:

La Prueba de Fuego: Benchmark con k6

Las palabras se las lleva el viento. Los datos no. Sometí al clúster evolucionado a una prueba de estrés para demostrar la diferencia.

Escenario de Ataque:

• Virtual Users: 50 concurrentes golpeando el API sin piedad.

• Duración: 60 segundos.

• Evento Caótico: Durante la prueba, asesiné manualmente uno de los contenedores de Quarkus.

Los Resultados:

Mientras yo mataba nodos, Fabio redirigía el tráfico instantáneamente a los supervivientes. Nomad detectaba la muerte y levantaba un reemplazo en segundos. El usuario final (k6) jamás se enteró del caos que ocurría tras bambalinas.

Y todo esto, corriendo en mi laptop, consumiendo menos recursos que dos pestañas de Chrome.

Conclusión

La mentira de Kubernetes es hacerte creer que la complejidad es necesaria para escalar. No lo es. La complejidad es necesaria para venderte soluciones a problemas que ellos mismos crearon.

La suite de HashiCorp (Nomad + Consul) representa el retorno a la ingeniería sensata: piezas pequeñas, bien conectadas, que entiendes y controlas. He logrado en una tarde, y con un solo archivo de configuración, lo que en K8s requiere un equipo de DevOps dedicado.

El código está disponible en mi repositorio. La puerta de salida de la "Matrix" está abierta.

¿Te atreves a cruzarla?

🔗 Repositorio del Proyecto

El código fuente del proyecto, con los archivos nomad, las instrucciones de cómo levantar el entorno y las pruebas de estress, se encuentran aquí:

https://github.com/apuntesdejava/nomad-quarkus-reference-arch/