Homelab Rebuild 2026 — del homelab a un mini centro de datos

🌐 También en: English · Deutsch · Français

Episodio 0 — Empieza el proyecto. Esto va de rediseñar todo mi homelab — no de añadir un servicio más encima, sino de replantear cómo se construye y se opera todo el entorno. En realidad ya he trabajado con Kubernetes, en una configuración bastante parecida a la que voy a describir. En marzo publiqué el primer borrador de esta idea. Por razones que todavía no sé explicar del todo, me fui alejando del plan original y nunca lo terminé. Ese artículo ya se ha retirado. Esta vez quiero empezar de nuevo — siguiendo un plan sorprendentemente parecido al que tenía entonces. Como siempre, la cosa se descontroló rápido.

• Clúster de Proxmox de 3 nodos
• Windows Server Active Directory
• Clientes Windows 11
• Servidor de archivos Windows
• PKI interna
• GitLab
• RKE2 Kubernetes
• FluxCD GitOps
• Longhorn y MinIO (en futuros artículos)
• Monitorización con Icinga2
• Proxmox Backup Server

🎯 Objetivo

No se trata de montar un centro de datos de producción. Se trata de aprender cómo funciona la informática empresarial construyendo una en casa.

🖥️ Hardware

• HP1 — 64 GB de RAM, SSD de sistema de 512 GB, SSD de 2 TB
• HP2 — 32 GB de RAM, SSD de sistema de 512 GB, SSD de 2 TB
• HP3 — 32 GB de RAM, SSD de sistema de 512 GB, SSD de 3×2 TB (RAID5 por software)

Todas las VM Linux usarán Ubuntu Server 26.04 LTS como sistema base.

🏛️ Arquitectura 2026: no todo es nuevo, pero por fin está bien montado

Antes de escribir este artículo, desenterré un viejo documento de planificación de febrero — un intento anterior de esta misma idea que nunca terminé. Esperaba encontrar algo desfasado y ya había tirado mentalmente casi todo antes de volver a leerlo. Me equivocaba. Aquel borrador de febrero ya estaba sorprendentemente cerca de donde he acabado hoy. El plan de direcciones IP, el esquema de nombres y el reparto de roles entre Active Directory, PKI y monitorización estaban en gran parte bien. Lo que le faltaba no era mejor tecnología — era un modelo de operación como es debido. Así que, en lugar de empezar desde cero, esta reconstrucción toma el plan antiguo como una «versión 0.9», conserva lo que sigue en pie, descarta lo que no y añade GitOps como la pieza que faltaba para unirlo todo.

Lo que sobrevivió del plan antiguo

• Rango IP y dominio — 192.168.10.x/24 en la red interna, con home.arpa como sufijo de dominio. home.arpa es el TLD reservado oficialmente para redes domésticas — un pequeño detalle que el plan antiguo ya tenía bien.
• Un esquema de nombres legible — en lugar de nombres genéricos tipo VM11/VM12, cada VM sigue el patrón <host>-<role>-<number>, p. ej. HP1-gitlab01 o HP2-fs01. Con solo leer el nombre sabes dónde corre algo y qué hace. Los propios hosts se llaman según el rango IP que les corresponde: HP1 para los 30, HP2 para los 40, HP3 para los 50.
• Dos controladores de dominio — HP1-dc01 (DNS, roles FSMO, CA raíz) y HP2-dc02 (DNS, catálogo global), repartidos entre dos hosts Proxmox distintos para tener redundancia.
• Una jerarquía PKI de verdad — CA raíz offline → CA emisora → servidores y clientes, en lugar de una única CA plana. Más parecido a como lo haría una organización real.
• Icinga2 para la monitorización clásica de infraestructura (Proxmox, Windows Server, VM, red) — Kubernetes tiene en cambio su propio stack de Prometheus/Grafana, en lugar de obligar a una sola herramienta a cubrir ambos mundos.
• GitLab, ascendido de «simplemente un repositorio Git» a plataforma central para el código fuente, CI/CD, el registro de contenedores y el repositorio GitOps que vigila FluxCD.
• Vault (u OpenBao) para la gestión de secretos — se queda, pero aplazado a propósito a la fase 2 en lugar de ser una dependencia desde el primer día, para que la configuración inicial de Kubernetes/GitOps no quede bloqueada esperando a que la gestión de secretos esté perfecta.

Lo que dejo atrás a propósito

Un homelab tiene la costumbre de convertirse en una colección de tecnologías de «esto también estaría interesante». Esta reconstrucción quiere demostrar una arquitectura pensada, no un montón de tecnologías apiladas — así que algunas cosas del plan antiguo se descartan adrede:

• Agrupar varios servicios en una sola VM (p. ej. GitLab + Pi-hole + Grafana + Nextcloud juntos). Más difícil de incluir en las copias de seguridad, más difícil de mantener y menos realista. Una VM, una tarea.
• Un servidor NAS aparte. Entre el servidor de archivos Windows, el almacenamiento propio de Proxmox y Longhorn/MinIO para Kubernetes, una cuarta plataforma de almacenamiento solo añadiría complejidad sin aportar capacidades.
• NFS como backend de almacenamiento de Kubernetes. Longhorn está hecho justo para esto y es la mejor forma de aprender de verdad el almacenamiento en Kubernetes.
• Ejecutar Nextcloud fuera de Kubernetes. Es una carga de trabajo realmente buena para aprender — ingress, almacenamiento, base de datos, secretos, copias de seguridad — así que su sitio está dentro del clúster, no al lado.
• Apilar varios sistemas de monitorización que se solapan (Icinga + Zabbix + Nagios + Prometheus a la vez). Basta con una herramienta por capa: Icinga2 para la infraestructura clásica, Prometheus/Grafana para Kubernetes.
• Un appliance de cortafuegos dedicado (p. ej. una VM de cortafuegos aparte basada en FreeBSD). Interesante por sí mismo, pero es un proyecto distinto que diluiría el foco de este.

El plan consolidado de VM e IP

El reparto de las VM sigue la RAM realmente disponible en cada host: HP1 tiene la mayor cantidad de RAM (64 GB), así que carga con la mayor parte del trabajo general y del control plane. HP3 tiene menos RAM pero el gran pool de almacenamiento RAID5, así que aloja menos VM pero sigue siendo el hogar natural de los workers de Kubernetes que tiran mucho de almacenamiento. HP2 completa el conjunto con el servidor de archivos, el segundo controlador de dominio y el resto de workers.

VM	Rol	IP	RAM	Disco
HP1-dc01	AD / DNS / CA raíz	192.168.10.x	4 GB	60 GB
HP1-gitlab01	GitLab / registro de contenedores	192.168.10.x	8 GB	120 GB
HP1-seed01	VM de desarrollo (Ansible, kubectl, herramientas)	192.168.10.x	4 GB	60 GB
HP1-vault01	Gestión de secretos (fase 2)	192.168.10.x	2 GB	40 GB
HP1-icinga01	Monitorización	192.168.10.x	4 GB	60 GB
HP1-k8s-cp01	Control plane de RKE2	192.168.10.x	8 GB	80 GB
HP1-k8s-cp02	Control plane de RKE2	192.168.10.x	8 GB	80 GB
HP2-fs01	Servidor de archivos Windows	192.168.10.x	8 GB	200 GB
HP2-dc02	AD / DNS / catálogo global	192.168.10.x	4 GB	60 GB
HP2-k8s-w03	Worker	192.168.10.x	8 GB	100 GB
HP2-k8s-w04	Worker	192.168.10.x	8 GB	100 GB
HP3-pihole01	Filtro DNS	192.168.10.x	1 GB	20 GB
HP3-k8s-cp03	Control plane de RKE2	192.168.10.x	8 GB	80 GB
HP3-k8s-w01	Worker	192.168.10.x	8 GB	150 GB
HP3-k8s-w02	Worker	192.168.10.x	8 GB	150 GB

Todas estas VM se aprovisionarán automáticamente con Terraform, en lugar de montarlas a mano a base de clics en la interfaz de Proxmox — un primer paso deliberado para tratar todo el homelab como código, no solo la capa de Kubernetes que va encima.

Almacenamiento, simplificado

Proxmox Storage (HP3)
    ZFS RAIDZ1 → VM storage, snapshots

Kubernetes Storage
    Longhorn → Persistent Volumes

Backup
    Proxmox Backup Server → VM backup

Ninguna caja NAS adicional en medio — el almacenamiento ZFS propio de Proxmox y Longhorn cubren ambos mundos.

Los cinco pilares

                Homelab 2026

        +-----------------------+
        |                       |
   Classic IT              Cloud Native

   Active Directory        RKE2
   Windows                 FluxCD
   SMB                     GitOps
   PKI                     Longhorn

        +-----------------------+

              Proxmox

        +-----------------------+

              Backup (PBS)

La gracia de esta reconstrucción no es «he instalado 25 tecnologías». Es: estoy construyendo en casa una pequeña plataforma de estilo empresarial y operándola como lo hacen de verdad los equipos de plataforma modernos — con GitOps como columna vertebral que une la infraestructura clásica con el lado cloud native.

📐 GitOps primero

Todo lo relacionado con Kubernetes vivirá en GitLab. Git es la única fuente de verdad y FluxCD sincroniza el clúster de forma continua. Nada de deriva de configuración manual.

📝 Documentación

Todo — decisiones de arquitectura, configuraciones, lecciones aprendidas y errores — se documentará públicamente en https://www.github.com/aptupgrademe/rebuild_2026. El objetivo es ayudar a otros mientras me construyo mi propia base de conocimiento.

🤖 La IA como compañera de aprendizaje

A diferencia de mis anteriores experimentos con Kubernetes, este proyecto usará mucho a Claude como sparring técnico para entender conceptos, revisar configuraciones, resolver problemas y mejorar la documentación. La IA está para acelerar el aprendizaje — no para sustituir la comprensión.

🗺️ Hoja de ruta de seis meses

1. Clúster Proxmox y red
2. Active Directory, Windows 11 y servicios de archivos
3. GitLab y VM seed de desarrollo
4. RKE2 Kubernetes
5. FluxCD GitOps
6. Aplicaciones (WordPress, Nextcloud, …)
7. PKI
8. Monitorización, copias de seguridad y bastionado

Cada hito tendrá su propio artículo en el blog. Este es, a propósito, la visión general — el comienzo del viaje.

🔜 ¿Qué viene ahora?

El próximo artículo tratará el hardware, la red y la instalación inicial del clúster Proxmox. Bienvenido al comienzo de una aventura de seis meses.

---

📚 Más de esta serie: Homelab Rebuild 2026 (en inglés)

• Homelab Rebuild 2026 — Building the Proxmox Cluster and Provisioning It with Terraform
• Homelab Rebuild 2026 — Active Directory, Pi-hole Laundering, and a Drive Letter That Refuses to Exist
• Homelab Rebuild 2026 — GitLab, a Seed VM, and the Calm Before the Kubernetes Storm
• Homelab Rebuild 2026: Wait and See – A Server Crash, a Dead-End Advisory, and My New Prime Suspect