Este diminuto homelab de las Tortugas Ninja es muy mono, pero ejecuta un pipeline de producción completo

El tema de la guarida en las alcantarillas es lo menos interesante

Un homelab temático puede salir mal muy rápido. Les pones unos cuantos nombres de dibujos animados a un montón de máquinas, subes una foto y todo empieza a parecer decoración que se hace pasar por arquitectura. Este sale bien parado porque el tema de las Tortugas Ninja es lo menos interesante que tiene. El clúster se llama sewer-lair, los nodos de Proxmox se llaman leonardo y donatello, y sí, eso le da al montaje un toque de cómic. Debajo de los nombres divertidos hay una plataforma pequeña, real y con criterio propio, construida para aprender la cadena de la infraestructura moderna por las malas, ejecutando aplicaciones de verdad sobre ella.

El hardware es modesto en el mejor sentido posible: dos HP EliteDesk 705 G4 Mini, cada uno con un AMD Ryzen 5 PRO 2400GE, 16GB de RAM y almacenamiento NVMe, además de un switch gestionable de TP-Link y un NAS de WD. Con esa ficha técnica no vas a ganar ningún concurso de racks. No hay una pared de servidores empresariales, ni ventiladores chillando, ni guerras religiosas sobre 10GbE, ni una SAN de eBay zumbando en un rincón como una estufa. Es compacto y práctico, el tipo de equipo que dice: "Quiero aprender Kubernetes, no explicarle a mi familia la factura de la luz".

Eso es lo que me gusta. Es autoalojamiento con un propósito, más cerca de un portafolio con cables. Proxmox está en la base con VMs encima, luego k3s para Kubernetes, ArgoCD para GitOps, Longhorn para el almacenamiento y Traefik para el ingress. cert-manager y Let's Encrypt se encargan de TLS, mientras que Cloudflare Tunnel y Access se ocupan del enrutamiento externo y de los servicios protegidos. En el stack viven aplicaciones reales, así que es algo más que pods de demostración parpadeando en verde en un panel. Es pequeño, pero tiene la forma de algo mucho más grande.

Un clúster de mini PCs con ambición de plataforma

A veces los homelabs diminutos son más interesantes que los gigantes. Un laboratorio grande puede esconder una mala arquitectura detrás del exceso de hardware: más RAM, más discos, más nodos, más puertos, más de todo. Uno pequeño no tiene dónde esconderse. Con dos mini PCs y 16GB por nodo, cada decisión cuenta. ¿Cuántas VMs creas? ¿Dónde vive el plano de control? ¿Qué recibe almacenamiento persistente, qué se ejecuta fuera de Kubernetes y qué merece una VM propia? ¿Qué se rompe cuando un nodo sufre presión de disco? Los límites obligan a hacer ingeniería de verdad en lugar de arquitectura de fantasía.

Este montaje toma unas cuantas decisiones inteligentes. Proxmox VE gestiona la capa de virtualización, con VMs dedicadas para el plano de control de k3s, el worker de k3s, Home Assistant y Cloudflared. Esa separación evita que el host se convierta en un cajón de sastre y mantiene el entorno comprensible. Las VMs de k3s usan Debian 13, una respuesta aburrida en el mejor sentido. Kubernetes ya trae suficiente caos, y el sistema operativo invitado no necesita hacer un casting para llamar la atención.

El stack en sí es el kit de iniciación de un homelab moderno que se ha convertido en un pequeño equipo de plataforma: ArgoCD, App of Apps y namespaces para apps, infra, monitoreo, almacenamiento, ArgoCD, Traefik, cert-manager y Longhorn. Suena a sopa de palabras de moda hasta que cuentas cuánto aprendizaje práctico hay metido ahí, desde la sincronización y la poda de GitOps, la programación de PVCs y el enrutamiento de ingress hasta la automatización de certificados, los desafíos DNS, los fallos de almacenamiento, la migración de bases de datos y la presión de disco. Cada una de esas cosas es una trampilla en la infraestructura real, y este laboratorio las va recorriendo una a una.

Un comentarista lo calificó de "limpio", un elogio breve que funciona porque no necesita mucho más. Otro se fijó en el mini PC y bromeó con que él usa esa misma máquina como PC principal, mientras que el autor la usa como hardware de servidor. Ahí está la economía del homelab en una frase: el equipo de uso diario de una persona es el nodo worker de Kubernetes de otra. La línea entre "escritorio" y "servidor" nunca ha sido tan fina, y cajas diminutas como estas hacen que parezca casi ridícula.

GitOps le da seriedad al laboratorio

Lo más fuerte de este montaje es el flujo de trabajo, más que el hardware o el tema. Las imágenes Docker se construyen en local, se suben a GitHub Container Registry y ArgoCD las despliega desde Git. Eso cambia la personalidad del laboratorio: pasa de "instalé algunas cosas" a "tengo un pipeline de entrega". Importa porque la carencia de habilidades en infraestructura moderna rara vez tiene que ver con instalar una herramienta. Tiene que ver con entender cómo pasan los cambios del código al contenedor, al registro, al clúster, al ingress y a los usuarios sin convertirse en un ritual de clics manuales.

El patrón App of Apps dice mucho. Tiene un sabor algo empresarial para un homelab de dos nodos, claro, pero a un homelab se le permite estar un poco sobredimensionado cuando el objetivo es aprender. Nadie necesita ArgoCD para ejecutar un portafolio personal en dos mini PCs. Pero si el objetivo es entender cómo Git se convierte en la verdad de la infraestructura, ArgoCD es la lección en sí.

Esa lección se vuelve real cuando las cosas se rompen. El autor ya ha lidiado con volúmenes de Longhorn atascados o en fallo, PVCs de Kubernetes y programación de almacenamiento, presión de disco en un nodo de k3s, la ampliación de una partición raíz de Debian tras aumentar el disco de la VM, la migración de PostgreSQL a Kubernetes, el enrutamiento de Cloudflare Tunnel, el enrutamiento por host de Traefik y el comportamiento de sincronización y poda de ArgoCD. Esa lista vale más que el diagrama final limpio. La arquitectura reluciente es la foto de portada, y la lista de problemas resueltos es donde ocurre el aprendizaje.

Ver tutoriales no es lo mismo que estar de guardia por tus propias tonterías. Cuando Longhorn se pone raro, aprendes lo que significa en la práctica el almacenamiento distribuido. Cuando los PVCs no se programan, aprendes que Kubernetes no es una máquina expendedora mágica de almacenamiento. Cuando aparece la presión de disco, aprendes que "clúster pequeño" significa un radio de impacto pequeño y también un margen pequeño. Y cuando ArgoCD poda algo que no esperabas, GitOps deja de ser un eslogan y pasa a ser un arma cargada.

Por eso importan las aplicaciones reales pequeñas. El laboratorio ejecuta un portafolio personal, Proximity para la comunidad de radioaficionados, Uptime Kuma, Home Assistant, un bot de Discord del PUBG Portugal Team, PostgreSQL, Traefik, ArgoCD, Longhorn y Cloudflared. Ninguna de esas es una carga de trabajo crítica para el mundo, pero son lo bastante reales como para castigar los cambios descuidados. Tienen datos, rutas, certificados, expectativas de disponibilidad y pequeñas dependencias que hacen que el sistema parezca vivo.

Cloudflare Tunnel es una elección práctica, aunque no purista

La parte de Cloudflare siempre va a dividir opiniones. A algunos les encanta Cloudflare Tunnel porque evita abrir puertos de entrada, gestiona el enrutamiento público de forma limpia y combina bien con Access para los servicios protegidos. A otros les pone nerviosos meter a un tercero tan grande en el camino de una infraestructura autoalojada. Las dos reacciones son razonables. En un laboratorio de aprendizaje, eso sí, Cloudflare Tunnel es una decisión muy práctica. Permite al autor centrarse en el ingress, el DNS, TLS y patrones de acceso más o menos basados en identidad sin convertir el router de casa en un campo de batalla.

El stack de borde es ordenado: Traefik v3, cert-manager, certificados comodín de Let's Encrypt, el desafío DNS-01 de Cloudflare, Cloudflare Tunnel y Cloudflare Access. Es una solución de borde sorprendentemente completa para dos cajitas. Enseña la diferencia entre el enrutamiento interno de servicios y la exposición pública, hace real la automatización de TLS y convierte el DNS en algo más que una cosa que tocas una vez y olvidas. También tiene suficientes piezas móviles como para que depurar tenga sentido.

Podrías argumentar que esto es demasiado para un homelab, que un portafolio, un bot y Home Assistant no necesitan GitOps, certificados comodín, ingress de Kubernetes y túneles protegidos. Esa crítica da por hecho que el objetivo es alojar aplicaciones. Aquí el objetivo es entender la cadena completa: del hardware a Proxmox, de Proxmox a las VMs, de las VMs a k3s, de k3s al almacenamiento, del almacenamiento al ingress, del ingress a TLS, de TLS al DNS, del DNS a GitOps, de GitOps al monitoreo y del monitoreo a las aplicaciones reales. Esa cadena es el producto.

Otro comentarista sugirió añadir automatización con Ansible y un proxy interno de registro Docker para esquivar los límites de descarga de Docker Hub. Un laboratorio como este invita justo a ese tipo de comentarios, porque la plataforma ya ha superado el "¿qué debería instalar?" y está en el "¿cómo reduzco el trabajo repetitivo?". Ansible podría estandarizar la preparación de las VMs, el endurecimiento del sistema operativo, la instalación de paquetes, la gestión de usuarios y la configuración base. Un espejo de registro o una caché pull-through haría el clúster más resistente y menos dependiente de los cambios de humor de los registros públicos. Las dos cosas afinarían el pipeline, y ninguna es un juguete más.

La única advertencia es la proliferación de herramientas. En cuanto un laboratorio se pone emocionante, cada herramienta empieza a parecer la siguiente lección: Ansible, Renovate, SOPS, external-secrets, Prometheus, Grafana, Loki, Velero, Talos, Cilium, Tailscale, Authentik, Harbor, MinIO. El menú no se acaba nunca. El truco es añadir herramientas porque resuelven un dolor que ya has sentido, no porque quede sitio en el diagrama.

Longhorn es donde el laboratorio mono choca con la realidad

El almacenamiento es donde los laboratorios pequeños de Kubernetes maduran o empiezan a engañarse a sí mismos. Longhorn es una buena elección para aprender porque hace accesibles los volúmenes persistentes, pero también deja claro que el almacenamiento distribuido en nodos diminutos tiene un coste. Las réplicas necesitan espacio, las reconstrucciones necesitan I/O y los nodos necesitan margen para respirar. La presión de disco se convierte en un evento real en lugar de un aviso teórico en un panel. El autor ya ha visto volúmenes de Longhorn atascados o en fallo, algo molesto y también justo el tipo de dolor que enseña las lecciones correctas.

Ejecutar PostgreSQL 16 dentro del clúster sube la apuesta. Una base de datos cambia la pregunta del almacenamiento de "¿arranca la aplicación?" a "¿me fío de tener mis datos aquí?". Con volúmenes persistentes para aplicaciones, bases de datos, subidas, logs y datos del bot, el laboratorio ya no es un juego sin estado. Las copias de seguridad, las pruebas de restauración, la retención, la salud del almacenamiento y la simulación de fallos empiezan a importar. Uptime Kuma puede decirte que algo está caído. No puede salvar una base de datos de la que nunca se hizo una copia de seguridad como es debido.

Aquí es donde el NAS de WD podría dejar de ser hardware de fondo y pasar a formar parte de una estrategia de backup real. "Tengo un NAS, así que tengo copias de seguridad" no cuenta; lo que cuenta son copias programadas, restauraciones probadas, copias fuera del nodo y quizá más adelante una ruta hacia una ubicación externa. Si el sentido de todo esto es aprender la cadena completa, las copias de seguridad y la restauración merecen un papel protagonista. Una plataforma que despliega sin problemas sigue sin ser madura hasta que puede recuperarse limpiamente.

Luego está la realidad de los dos nodos. Un clúster de Proxmox de dos nodos y un despliegue de k3s de dos nodos pueden enseñar mucho, pero tienen limitaciones de quórum y disponibilidad. Eso no hace que el diseño sea malo, solo honesto. Un tercer nodo diminuto, incluso algo de bajo consumo, podría cambiar la forma del sistema al darle al clúster un testigo mejor. La respuesta correcta depende de si el autor quiere bajo consumo y sencillez o un comportamiento ante fallos más realista.

Alguien hizo el típico comentario sobre la electricidad, diciendo que el montaje debía de consumir un montón. Comparado con servidores de tamaño completo, probablemente no. Dos minis EliteDesk, un switch y un NAS no son precisamente la hoguera de un centro de datos, y eso es parte de por qué el montaje funciona. Está en el punto justo en el que puede quedarse encendido el tiempo suficiente para ser útil sin convertirse en el villano de la factura de la luz.

Un proyecto de portafolio que muerde

Este homelab destaca porque entiende algo que muchos laboratorios pasan por alto: la estética atrae la atención, pero las operaciones crean valor. Los nombres de las Tortugas Ninja son divertidos, las fotos están cuidadas y los mini PCs tienen su encanto. Lo que importa más es el ciclo operativo de construir, subir, desplegar, enrutar, asegurar, monitorear, romper, arreglar y repetir. Ese es el ciclo que a la gente le pagan por entender.

Un montaje así provoca tres reacciones. La primera es pura admiración, porque es limpio, compacto, temático y ejecuta un stack moderno serio. La segunda es escepticismo: demasiado para dos mini PCs, demasiadas piezas móviles, demasiado Kubernetes para aplicaciones sencillas, demasiado dependiente de Cloudflare, demasiado frágil con Longhorn en nodos pequeños. La tercera es la más útil. Sí, está sobredimensionado si el objetivo es alojar cosas, pero tiene el tamaño adecuado si el objetivo es aprender.

Yo me quedaría con esa tercera opinión. Un homelab no tiene por qué ser la forma más sencilla de servir una página web, y puede ser una carrera de obstáculos hecha a propósito. Este enseña Kubernetes, GitOps, almacenamiento, ingress, TLS, DNS, monitoreo y la operación de aplicaciones reales en un único sistema compacto. Eso lo convierte en un temario, y yo no lo llamaría desperdicio.

Las próximas mejoras probablemente deberían ser aburridas, y lo digo como un cumplido. Añadir Ansible para preparar VMs y hosts de forma repetible, una caché de registro o un registro interno y una gestión de secretos como es debido. Hacer simulacros de copia de seguridad y restauración. Añadir un monitoreo que siga la salud de los nodos, la salud de Longhorn, la caducidad de los certificados, el estado del túnel y la presión de almacenamiento, y escribir documentación para que todo se pueda reconstruir en lugar de solo admirarlo. Quizá añadir un tercer nodo que ayude con el quórum si las pruebas de disponibilidad se convierten en la próxima frontera.

El tema de la guarida en las alcantarillas hace que el laboratorio sea memorable, el stack lo hace útil y la resolución de problemas lo hace real. Además, solo tiene unos días, lo que lo hace más interesante de seguir. Verse limpio el tercer día es fácil. La pregunta difícil es si seguirá pareciendo limpio después de treinta días, después de la primera actualización fallida, después de una reconstrucción de Longhorn, una sorpresa con un certificado, un error de poda de ArgoCD y la primera prueba de restauración que o bien funciona o bien te arruina la noche. Ahí es cuando un homelab deja de ser algo para presumir y se convierte en un maestro, y este ya va por la mitad del camino.