Homelab: Kubernetes bare-metal en tu escritorio.

¿Por qué un Homelab?

Las plataformas cloud públicas nos permiten construir, escalar y operar aplicaciones con suma facilidad y a un coste relativamente bajo. Y no solo en términos puros de coste de infraestructura. Nuestro tiempo también supone un coste muy importante y crear estas infraestructuras, adquirir los equipos, acondicionar los centros de datos, montar las redes, etc. suponen costes muy elevados en términos de tiempo/esfuerzo/infraestructura que las plataformas cloud nos permiten obviar.

Podríamos concluir que a priori todo son beneficios. Sin embargo, a veces nuestra propia organización y su burocracia, el control de costes asociado, los imprescindibles límites de seguridad y sus políticas e incluso la conectividad, limitan nuestra agilidad a la hora de consumir estos entornos en cloud. GitHub publicó en 2024 un dato revelador: en sus repositorios hay más de 39 millones de secretos publicados. Sin ir más lejos, de cada diez mil commits, 84 incluyen claves de AWS. Por último, dos de cada tres organizaciones utilizan kubernetes, es un estándar de facto en la industria por sus innumerables ventajas.

Así las cosas, disponer de entornos de desarrollo en cloud/kubernetes es cada vez más necesario. Pero como podemos comprobar en nuestro día a día, a nivel operacional conlleva ciertos esfuerzos, sobre todo al compartir determinados contextos entre diferentes equipos de desarrollo e infraestructura, lo que nos impide ser más ágiles para probar ciertas cosas y/o duplicar infraestructura y por tanto recursos. ¿Y si eres estudiante? Las limitaciones de presupuesto son aún mayores y los créditos, a la hora de usar laboratorios complejos, se consumen rápido.

Un homelab cambia ese contexto. Permite replicar la topología de un clúster real de Kubernetes (control plane, nodos, red, almacenamiento) en un entorno físico y seguro, sin depender de la facturación por hora ni del riesgo de publicar claves o endpoints, afectar a terceros o compartir contextos. ¿Podemos hacer lo mismo en nuestro equipo local con kind o minikube? Sí, pero no. Necesitamos mucha más potencia, nuestro cluster competirá con nuestros recursos locales sin aislamiento físico.

¿Y si queremos un homelab con hardware dedicado? El uso de miniPCs y Raspberries es cada día más habitual. Nos dan mucha flexibilidad a un coste realmente bajo. En algunos casos, las Raspis se van acumulando, ya que no solo se usan como homelab, sino que se añaden al hogar como un elemento más: Pi hole, domótica, etc.

¿Qué es Turing Pi?

Y aquí es donde llegamos a Turing Pi, una placa que permite agrupar varios módulos de Raspberry, Nvidia Jetson y en su última versión, módulos hardware propios, para formar un pequeño clúster de Kubernetes “bare-metal” compacto, eficiente y con un consumo realmente bajo.

En esencia, convierte hardware de bajo consumo en una plataforma bare-metal de alta disponibilidad capaz de ejecutar contenedores, Kubernetes o cualquier carga bajo Linux. Echemos un vistazo rápido a sus componentes:

Placa Turing Pi 2:

La Turing Pi 2, su versión más reciente, puede alojar hasta cuatro módulos CM4, cada uno actuando como nodo independiente. Además, incorpora:

• BMC (Baseboard Management Controller) para monitorizar, encender y apagar cada nodo de forma remota.
• Dos puertos SATA, para conectar discos SSD o HDD.
• Slot mPCIe y SIM, pensados para módulos 4G/5G o NVMe.
• Conectividad Ethernet gigabit interna y externa.
• Alimentación ATX o PicoPSU y formato Mini-ITX estándar, compatible con cajas ITX como la Streacom DA6.
• Por la parte trasera podremos ver también un slot para una microSD, amén de los que incluyen los adaptadores de cada módulo de CM4.

Veamos la matriz de compatibilidad de componentes según el tipo de módulo:

Módulo CM4 con adaptador y disipador:

Cada nodo del clúster puede ejecutar un sistema operativo basado en Linux ARM64. Lo habitual es instalar Raspberry Pi OS Lite (antiguamente Raspbian) ya que no necesitamos X. Sobre esa base se instala un orquestador Kubernetes ligero, siendo K3s la opción más habitual por su bajo consumo y simplicidad de despliegue. El control plane suele alojarse en el módulo 1, que actúa como nodo máster, mientras los demás desempeñan el papel de workers formando el data plane. Esta separación reproduce fielmente la arquitectura de un clúster en la nube, pero en formato reducido.

Además, hay que tener en cuenta que la propia placa incluye un BMC (Baseboard Management Controller), un chip independiente que actúa como el “cerebro auxiliar” de la placa. Este controlador (basado en un ASPEED AST2500, el mismo que usan muchos servidores empresariales como QNAP o Dell EMC) permite encender, apagar o reiniciar cada nodo de forma remota, monitorizar temperaturas, controlar ventiladores y actualizar firmware sin necesidad de conectar teclado o pantalla.

El BMC ejecuta una versión personalizada de OpenBMC, accesible por SSH o interfaz web, y cuenta con su propia conexión de red Ethernet. Desde él es posible flashear los módulos CM4, instalar sistemas operativos, supervisar el estado del clúster o automatizar tareas mediante IPMI o Redfish, igual que en un entorno de centro de datos real. En la práctica, convierte un conjunto de Raspberry Pi en un mini data center completamente administrable, reproduciendo de forma tangible la capa de gestión que normalmente asumimos en la nube.

Aunque el Turing Pi 2 ofrece un entorno distribuido real, su potencia no es brutal. Jeff Geerling, uno de los principales referentes de la comunidad Raspberry Pi, demostró que un clúster completo con cuatro CM4 no alcanza el rendimiento de un MacBook M1. Sin embargo, su eficiencia energética es excepcional: cada módulo consume entre 2 y 7 W, de modo que un clúster completo rara vez supera los 30 W totales. Esa relación rendimiento-consumo lo convierte en una plataforma ideal para aprendizaje, pruebas de orquestación y despliegue continuo 24x7 sin el ruido ni el gasto eléctrico de un servidor convencional.

En próximos capítulos veremos cómo ensamblar nuestra Turing Pi y cómo instalar kubernetes y sus nodos. Pero en lugar de hacerlo con k3s como sugiere Turing Pi lo haremos más interesante recurriendo a ¡Talos! Una forma más eficiente y sobre todo declarativa para empezar a sacarle partido a nuestro homelab. Porque comprender la infraestructura física es el primer paso para diseñar y arquitecturar mejor en cloud.