Más allá de Nomad: Escapar del «impuesto de la nube» y construir una infraestructura Kubernetes independiente
El atractivo de la infraestructura simple
Durante años, mi filosofía sobre infraestructuras fue simple: reducir las piezas móviles al mínimo absoluto.
Si hubieras auditado mi repositorio de infraestructura como código (IaC) hace un par de años, habrías visto un entorno maravillosamente ágil y altamente optimizado. Usaba Terragrunt para orquestar instancias (droplets) de DigitalOcean en la región ams3. Desplegaba servidores s-4vcpu-8gb con Debian 11, adjuntaba volúmenes de bloque ext4 básicos de 10GB, y utilizaba Ansible para configurar el sistema base.
En el núcleo de esta configuración estaba HashiCorp Nomad.
Nomad era el orquestador perfecto para una consultora ágil. Era un binario único y elegante. No requería un equipo de plataforma dedicado para mantener el panel de control vivo. Programaba trabajos, gestionaba contenedores y no estorbaba.
Para complementar esta configuración, delegué completamente la observabilidad. Enviaba las métricas de Prometheus, los registros (logs) de Loki y las trazas de Tempo directamente a una cuenta gestionada de Grafana Cloud.
Era una máquina completamente codificada y sin fricciones. Funcionaba sin problemas... hasta que los requisitos del negocio superaron la arquitectura. Hoy en día, todo ese entorno ha sido desmantelado. He migrado mis cargas de trabajo en producción a un clúster de Kubernetes de 13 nodos en servidores físicos ubicados en Hetzner, impulsado por Talos Linux, Rook-Ceph y un entorno de observabilidad Grafana alojado por nosotros mismos.
Esta es la historia de por qué cambié la «simplicidad» de Nomad y los servicios en la nube gestionados por una arquitectura de Kubernetes verdaderamente independiente.
Detonante 1: La licencia BSL y las ataduras con proveedores
La primera grieta en los cimientos no fue técnica; fue legal y estratégica.
En agosto de 2023, HashiCorp alteró el panorama del código abierto al cambiar sus productos principales (incluyendo Nomad y Terraform) de la Licencia Pública de Mozilla (MPL) a la Licencia de Fuente Comercial (BSL).
En ese momento, yo estaba diseñando un servicio de alojamiento gestionado para mis clientes, con la intención de empaquetar y vender acceso aislado a un clúster robusto de Nomad. Bajo los nuevos términos de la BSL, ofrecer un servicio gestionado construido directamente sobre Nomad entraba en una zona legal gris, diseñada específicamente para proteger a HashiCorp de plataformas que hicieran exactamente lo que yo pretendía hacer (a menos que pagara tarifas de licencias corporativas exorbitantes).
Me di cuenta de que estaba construyendo mi negocio sobre terreno alquilado. No puedes ofrecer soluciones verdaderamente «independientes» a clientes europeos cuando el motor de orquestación central está sujeto a cambios de licencia repentinos y restrictivos por parte de una corporación estadounidense.
Inmediatamente cambiamos nuestro IaC de Terraform a OpenTofu, y comenzó la búsqueda de un orquestador genuinamente de código abierto. Kubernetes era la única respuesta lógica.
Detonante 2: El muro de la Alta Disponibilidad con estado
Las aplicaciones sin estado (stateless) son fáciles de gestionar. Son los datos persistentes con estado (stateful) los que rompen las arquitecturas.
Uno de mis clientes principales ejecuta una aplicación heredada en Apache/PHP. Debido a cómo está diseñada, requiere acceso persistente y compartido de lectura y escritura a un directorio específico en el disco.
En mi entorno de DigitalOcean y Nomad, estaba provisionando volúmenes de almacenamiento en bloque estándar y formateándolos como ext4. El defecto fatal aquí es que el almacenamiento en bloque estándar de la nube es de tipo ReadWriteOnce (RWO). El volumen solo puede montarse en un único nodo a la vez.
Si quería lograr Alta Disponibilidad (HA) para esta aplicación, estaba bloqueado. No podía levantar múltiples instancias de la aplicación PHP en diferentes nodos de trabajo de Nomad porque no podían compartir el mismo volumen de bloques. Si el servidor físico principal fallaba, toda la aplicación caía hasta que el volumen pudiera desconectarse y volver a conectarse en otro lugar.
Para solucionar esto, necesitaba almacenamiento distribuido de tipo ReadWriteMany (RWX).
Aunque puedes forzar plugins CSI en Nomad para manejar almacenamiento distribuido, la integración suele ser frágil. Kubernetes, sin embargo, cuenta con Rook-Ceph de forma nativa. Al pasar a Kubernetes, pude tomar discos NVMe físicos en múltiples servidores y agruparlos en un clúster de almacenamiento Ceph distribuido y altamente resiliente.
De repente, las aplicaciones heredadas podían escalar horizontalmente a través de los nodos de trabajo, compartiendo el estado sin esfuerzo. La verdadera Alta Disponibilidad por fin era posible.
Detonante 3: La trampa de la observabilidad como SaaS
Cuando eres pequeño, los productos gestionados como servicio (SaaS) parecen un superpoder. A medida que escalas, se convierten en una trampa financiera.
Inicialmente, mi código de Terragrunt se integraba directamente con Grafana Cloud. Era increíblemente conveniente enviar métricas de Prometheus y registros de Loki a sus puntos de acceso europeos. Pero a medida que mi clúster crecía y el volumen de registros y métrics aumentaba, alcancé rápidamente los límites de uso de los planes estándar.
Para mantener la visibilidad que necesitaba, mi factura mensual iba a dispararse. Estaba pagando un sobreprecio injustificado simplemente por la comodidad de que otra empresa alojara mis bases de datos de series temporales.
Al migrar a una infraestructura independiente con Kubernetes, recuperé el control de mi observabilidad. Desplegué todo el entorno LGTM (Loki, Grafana, Tempo, Mimir) de forma nativa dentro de mi clúster. Como ya no estaba limitado por las tarifas arbitrarias del SaaS, pude retener métricas de mayor resolución y un historial de registros más largo, obteniendo mejores capacidades de depuración a una fracción del coste.
La economía: Derrotar el «Impuesto de la Nube»
Alcanzar este nivel de Alta Disponibilidad y ejecutar un entorno de observabilidad tan pesado requiere una enorme potencia de cálculo. Si hubiera intentado construir esto en AWS, Azure o DigitalOcean, la factura mensual de infraestructura habría destruido los márgenes de beneficio.
Consideremos las matemáticas: En mi antigua configuración, un servidor de nivel medio en DigitalOcean (4 núcleos, 8 GB de RAM) costaba 48$ al mes.
Al pivotar hacia servidores físicos europeos mediante las subastas de hardware de Hetzner, la economía se invirtió por completo. Hoy, utilizo servidores dedicados con procesadores Intel Core i7-7700 (6 núcleos) y unos impresionantes 64 GB de RAM, todo por entre 29€ y 31€ al mes.
Por casi la mitad del precio de un servidor virtual en la nube, obtengo 8 veces más memoria, procesadores físicos dedicados y acceso directo al hardware. Como la infraestructura física es tan asequible, pude sobredimensionar la capacidad sin problemas.
Mi clúster actual de Kubernetes independiente consta de 13 nodos dedicados:
- 3 Nodos de Control (Para verdadera Alta Disponibilidad de la API de K8s)
- 3 Nodos de Almacenamiento (Dedicados a Rook-Ceph usando discos NVMe locales)
- 4 Nodos de Trabajo (Para las cargas de trabajo de las aplicaciones)
- 3 Nodos de Monitorización (Dedicados al entorno LGTM de Grafana autoalojado)
Construir un clúster de 13 nodos en alta disponibilidad con esta cantidad de memoria y almacenamiento NVMe en una nube pública costaría miles de dólares al mes. Yo lo estoy ejecutando por el coste de unas pocas máquinas virtuales premium.
El cambio de paradigma del SO: Llega Talos Linux
Quizás estés pensando: Gestionar 13 servidores físicos con Linux suena a pesadilla para un administrador de sistemas. Si hubiera seguido usando Debian 11 y Ansible para aplicar parches al sistema operativo manualmente, configurar los tiempos de ejecución de los contenedores y asegurar el acceso SSH en 13 máquinas físicas, la carga operativa habría arruinado los ahorros financieros.
Para que Kubernetes en servidores físicos fuera viable, el sistema operativo debía desaparecer. Por eso adopté Talos Linux.
Talos es un sistema operativo inmutable y controlado por API, diseñado exclusivamente para Kubernetes. No hay SSH. No hay consola bash. Todo el sistema operativo se gestiona mediante una API, que se integra perfectamente con mis flujos de trabajo en OpenTofu.
Desde el punto de vista del mantenimiento y la seguridad, es una revelación. Si un nodo de trabajo falla, no inicio sesión (login) para depurarlo. Envío un comando a la API para borrar la máquina y reiniciarla desde una imagen impecable. Este enfoque de operaciones sin intervención manual (Zero-Touch) significa que gestionar 13 máquinas físicas con Talos requiere estrictamente menos esfuerzo operativo que gestionar 3 máquinas virtuales en la nube con distribuciones de Linux tradicionales.
Conclusión: El valor estratégico de la independencia
Cambiar la simplicidad de un único binario de Nomad por un clúster de Kubernetes de 13 nodos suena contradictorio, hasta que evalúas los resultados.
Al realizar esta migración, logré tres victorias estratégicas masivas:
- Fiabilidad sin compromisos: Eliminé los puntos únicos de fallo (SPOF) para las aplicaciones con estado utilizando Rook-Ceph.
- Previsibilidad financiera: Escapé de los costes crecientes de la computación en la nube pública y de las herramientas de observabilidad SaaS, multiplicando la potencia de mi clúster y reduciendo drásticamente la factura.
- Independencia Total: Al construir sobre hardware físico europeo con software 100% libre y de código abierto (Talos, K8s, Ceph, OpenTofu), mi infraestructura es inmune a subidas de precios arbitrarias de proveedores y a trampas de licencias privativas.
Se suponía que la nube facilitaría la gestión de infraestructura. Para muchas empresas en crecimiento, simplemente la ha hecho más cara y restrictiva.
Deja de alquilar tu fiabilidad. Empieza a ser el dueño de tu infraestructura.
¿Qué es lo siguiente? Este artículo es el primero de una serie en la que detallaré mi migración hacia una infraestructura de Kubernetes independiente. En las próximas publicaciones, desglosaré la implementación técnica paso a paso, empezando por cómo utilizo infrastructura como código para provisionar los servidores físicos en Hetzner e iniciar Talos Linux desde cero. Atento a las próximas entregas.
Tecnologías
Kubernetes, Nomad, bare-metal, Talos, Ceph, Grafana