Montar un clúster de Kubernetes “de verdad” para pruebas de rendimiento suele implicar dos opciones poco apetecibles para muchos administradores de sistemas: o saturar la infraestructura corporativa o invertir en un entorno específico que se dispara de precio. Por eso resulta llamativo el enfoque de un laboratorio construido sobre un Hetzner EX44 dedicado (Intel i5-13500 de 14 núcleos / 20 hilos, 64 GB de RAM y 2 NVMe) por unos 39 €/mes, usando Proxmox como hipervisor y Terraform como capa de infraestructura como código.
En la novena entrega de una mini-serie técnica, el proyecto entra en un punto especialmente interesante para perfiles de sysadmin: pasar de una única VM a seis nodos listos para Kubernetes, con cero clics en la interfaz web de Proxmox y toda la lógica encapsulada en código y plantillas de Cloud-Init.
El objetivo es claro: disponer de un stage/perf lab reproducible para experimentar con Kubernetes y Kubespray, probar cambios de red, CNI, upgrades y cargas sintéticas… sin tocar producción.
El contexto: un laboratorio de Kubernetes sobre bare metal low-cost
La base del laboratorio es un servidor dedicado Hetzner EX44, una máquina relativamente asequible que, bien exprimida, permite simular un entorno de clúster multi-nodo:
- CPU: Intel i5-13500 (14c / 20t)
- RAM: 64 GB
- Almacenamiento: 2× NVMe
- Hipervisor: Proxmox VE
- Coste aproximado: 39 €/mes
Sobre este host se orquesta todo con Terraform y el provider de Proxmox, de forma que cada VM, su disco, su Cloud-Init y su red queden descritos de manera declarativa. La meta de esta fase concreta es llegar a un diseño estándar de 3 nodos de control y 3 nodos worker, todos con configuración homogénea y parámetros del kernel adaptados a Kubernetes.
La piedra en el camino: Terraform, Proxmox y la latencia hacia la API
Antes de poder desplegar ese layout de 6 VMs, el proyecto se topó con un problema que muchos administradores han sufrido de alguna forma: operaciones de Terraform que se quedaban eternamente en “Still creating…”, drift parcial de estado e inconsistencias entre lo que Terraform creía haber creado y lo que realmente existía en Proxmox.
La causa no estaba en el código HCL, sino en algo mucho más mundano: la latencia variable entre el portátil que ejecutaba Terraform y la API de Proxmox. En momentos de pico de RTT, algunas llamadas se completaban “a medias”, el provider perdía la pista de ciertos recursos y el estado quedaba contaminado.
Para diagnosticar el problema se recurrió a herramientas conocidas en el arsenal de cualquier sysadmin: mtr para trazar la ruta y medir los saltos hasta el CPD de Hetzner. El patrón se repetía: picos de latencia en momentos concretos y rutas no siempre estables.
La solución fue pragmática y efectiva: mover la ejecución de Terraform a un VPS de Hetzner Cloud alojado en el mismo centro de datos que el dedicado. De ese modo, las llamadas al API de Proxmox pasaron a tener una latencia mínima y estable, los timeouts desaparecieron y los clones de VMs volvieron a ser consistentes.
Para cualquier administrador de sistemas, la lección es clara: cuando se automatizan hipervisores remotos con Terraform, la ubicación del ejecutor importa. Ejecutar los plans “desde casa” puede ser suficiente para entornos pequeños, pero en cuanto el número de recursos crece, puede ser preferible acercar la automatización al propio CPD.
Cloud-Init al servicio de Kubernetes: ajustes mínimos, impacto máximo
Resuelto el problema de la latencia, la siguiente pieza clave del laboratorio ha sido convertir Cloud-Init en el punto central de preparación de los nodos. Antes de pedirle a Kubespray que despliegue Kubernetes, los sistemas operativos de las VMs deben cumplir ciertos requisitos:
- Habilitar el módulo de kernel
br_netfilter
Kubernetes necesita inspeccionar tráfico en bridges para aplicar políticas de red. Sin este módulo, muchas configuraciones de red simplemente no funcionan como se espera. - Permitir el reenvío de IP (IP forwarding)
Los nodos del clúster actúan como routers para el tráfico entre pods y servicios. Por tanto, parámetros comonet.ipv4.ip_forwarddeben estar activados desde el arranque. - Asegurar que el tráfico puenteado pasa por iptables
Ajustes comonet.bridge.bridge-nf-call-iptables=1ynet.bridge.bridge-nf-call-ip6tables=1permiten que las reglas de firewall afecten al tráfico que circula por los bridges, algo relevante incluso si luego se migrará a soluciones como Cilium. - Desactivar la swap
Kubernetes, por defecto, no tolera swap activa. Si el sistema arranca con swap habilitada, kubelet se niega a iniciar, salvo que se fuerce expresamente ese comportamiento. En un laboratorio que pretende imitar producción, lo razonable es seguir la recomendación oficial y trabajar sin swap.
Estos cambios, que muchos administradores aplican manualmente con scripts de “post-instalación”, se han integrado directamente en las plantillas de Cloud-Init que Terraform genera para cada VM. Así, cada nodo arranca ya con:
- los módulos adecuados cargados,
- los parámetros
sysctlpreparados, - la swap deshabilitada de forma persistente,
- y el resto del sistema listo para que Kubespray haga su trabajo sin quejas.
Aunque el plan contempla el uso de Cilium como CNI en fases posteriores, la configuración basada en bridges e iptables no entra en conflicto con esta elección: Cilium ya no depende del modelo clásico de bridging, y mantener activados estos parámetros es totalmente inocuo.
Layout del clúster: 3 control planes + 3 workers, todo en código
A partir de estas piezas, el laboratorio llega a un punto que resulta especialmente atractivo para perfiles de administración de sistemas: un layout completo de 6 VMs en Proxmox completamente descrito en Terraform.
Entre las características destacables:
- 3 nodos de plano de control y 3 nodos worker, con el mismo perfil de CPU/RAM/disco (ajustado a los recursos totales del EX44).
- Direcciones IP estáticas y predecibles para cada nodo, tanto a nivel de red de Proxmox como en el propio sistema operativo.
- Plantillas de Cloud-Init separadas en ficheros
.tftpl, generadas por Terraform para cada VM. - Hostnames coherentes, alineados con el inventario que consumirá Kubespray.
- Mismo tipo de máquina virtual para todo el clúster: q35, UEFI, virtio para disco y red, etc.
Terraform se apoya en for_each para generar automáticamente el conjunto de nodos, de modo que añadir un cuarto worker o cambiar el número de máquinas en el plano de control se reduce a ajustar un mapa o una lista en el código. Nada de “copiar/pegar VM” desde la interfaz de Proxmox.
El resultado es un entorno donde:
- no hay que entrar a la consola web de Proxmox para crear VMs,
- cada creación es repetible y auditada en Git,
- y cualquier cambio de diseño (por ejemplo, más RAM por nodo o más disco para etcd) se describe como un cambio de código.
Beneficios operativos para el sysadmin: de la improvisación a la reproducibilidad
Para un medio orientado a administración de sistemas, el valor de este tipo de laboratorio va más allá del “juguete” de home-lab. Algunos puntos especialmente relevantes:
- Pruebas de rendimiento realistas
Al trabajar sobre un dedicado con recursos definidos, es posible medir el impacto real de distintas configuraciones de Kubernetes, CNI, almacenamiento o ingress sin la interferencia de la capa de virtualización de un proveedor público. - Escenarios de fallo controlados
Se pueden simular caídas de nodos, pérdida de disco, problemas de red o upgrades fallidos y volver al punto de partida con un simpleterraform destroy && terraform apply. - Documentación viva en forma de código
El propio HCL de Terraform y las plantillas de Cloud-Init funcionan como documentación técnica actualizada sobre cómo debería estar montado el entorno. No depende de wikis olvidadas ni de pasos manuales. - Alineamiento con buenas prácticas de IaC
La gestión de un hipervisor on-prem (o en un dedicado barato) con Proxmox y Terraform encaja bien en entornos corporativos donde ya se trabaja con Ansible, GitLab CI, pipelines de despliegue y controles de cambio.
Lo que viene: NAT, acceso y Kubespray
Aunque esta parte de la serie se centra en preparar las VMs, el siguiente desafío ya está sobre la mesa: cómo acceder de forma cómoda y segura a seis nodos que se encuentran detrás de NAT en Hetzner.
Para muchos administradores, esto implicará pensar en:
- un bastion host o nodo de salto,
- túneles SSH o VPN,
- reglas de firewall específicas para restringir el acceso,
- y cómo exponer, si es necesario, el plano de control de Kubernetes o los servicios del clúster.
Solo después de resolver ese puzzle de conectividad el laboratorio entrará en la fase que muchos esperan: el provisionamiento completo con Kubespray, con etcd, control planes, workers, CNI y add-ons desplegados sobre la base ya preparada.
Preguntas frecuentes sobre el laboratorio Kubernetes en Proxmox para sysadmins
¿Por qué elegir Proxmox + Terraform en vez de montar el clúster directamente sobre bare metal sin virtualización?
Para un laboratorio orientado a pruebas y repetibilidad, la capa de Proxmox ofrece flexibilidad: permite recrear nodos “limpios” en minutos, cambiar parámetros de hardware virtual, tomar snapshots y probar escenarios sin tener que reinstalar el sistema físico. Además, Terraform facilita versionar toda la topología.
¿Tiene sentido un clúster de 3 control planes + 3 workers en un servidor con 64 GB de RAM?
Sí, siempre que se dimensionen bien los recursos de cada VM. No es un entorno para cargas de producción exigentes, pero sí suficiente para:
- desplegar un clúster HA completo,
- probar CNIs, controladores, operadores y upgrades,
- y ejecutar cargas de prueba o benchmarks realistas a pequeña escala.
¿Sigue siendo relevante configurar br_netfilter y las reglas de iptables si se va a usar Cilium como CNI?
Aunque Cilium ya no depende del camino clásico bridge/iptables, mantener estos parámetros activos no genera conflicto y garantiza compatibilidad con otros componentes o escenarios híbridos. En un laboratorio, aporta flexibilidad y reduce sorpresas.
¿Por qué desactivar la swap en un laboratorio de rendimiento y no solo en producción?
Porque uno de los objetivos de este tipo de laboratorio es reproducir condiciones lo más parecidas posible a un entorno serio. Kubernetes está diseñado para trabajar sin swap por motivos de estabilidad y predicción de recursos. Mantener la swap desactivada desde el inicio evita falsos positivos y comportamientos que luego no se reproducirían en producción.
