Problema

Muchas personas que empiezan en DevOps necesitan un entorno controlado donde probar Docker, Kubernetes, Ansible y pipelines de CI/CD sin comprometer recursos de producción. El desafío es conseguir suficiente potencia de cómputo, aislamiento y flexibilidad dentro de un presupuesto limitado (≈ 500‑600 €). Además, el hardware debe permitir añadir una GPU más adelante para experimentos de IA local. El problema no es solo el precio; también hay que equilibrar la complejidad de la gestión (cluster, networking, backup) con la capacidad de escalar.

Causa

Los errores más habituales aparecen por tres motivos:

  1. Subestimar la carga de trabajo – Un nodo con solo 2 vCPU y 4 GB RAM se queda sin margen cuando se ejecutan varios pods, bases de datos ligeras y herramientas de observabilidad al mismo tiempo.
  2. Red y almacenamiento insuficientes – Un switch no gestionado de 5 Gbps o discos SATA lentos generan cuellos de botella que aparecen al iniciar pipelines de CI o al recopilar métricas.
  3. Elección de arquitectura rígida – Instalar k3s directamente sobre el hardware sin una capa de virtualización dificulta la creación de entornos de prueba aislados y complica la incorporación de un nodo GPU más adelante.

Solución

1. Definir la arquitectura base

Capa Tecnologías recomendadas Por qué
Hardware 2‑3 mini PCs (Intel i5‑8500T / i5‑9500T), 32 GB DDR4, 1 TB NVMe (RAID‑1 opcional) Buen balance entre coste, consumo y número de núcleos.
Hipervisor Proxmox VE (Debian‑based) Soporta KVM, LXC y ZFS nativamente; gestión vía web UI.
Orquestador k3s en VMs LXC Ligero, compatible con Helm, fácil de actualizar.
GitOps ArgoCD + Helm charts Despliegue declarativo y reversión sencilla.
Automatización Ansible + Terraform Provisionamiento reproducible de VMs y recursos de nube.
Observabilidad Prometheus, Grafana, Loki Stack completo para métricas, dashboards y logs.
AI futura Nodo dedicado con GPU (NVIDIA RTX 3060 o similar) conectado al mismo switch Se mantiene aislado y se puede añadir sin re‑arquitectura.

2. Selección de hardware

  • Mini PC: Busca modelos con fuente de alimentación interna (no externa) y puertos PCIe libres. Los Dell OptiPlex 3070 Micro y HP EliteDesk 800 G5 son habituales en el mercado de segunda mano y suelen incluir 2‑4 TB de espacio interno para discos.
  • Memoria: 32 GB DDR4 (2 × 16 GB) permite crear varias VMs con 4‑8 GB cada una y reservar 8 GB para el hipervisor.
  • Almacenamiento: Un NVMe de 500 GB para el OS de Proxmox y otro de 500 GB para datos de VM. Configura ZFS con raidz1 si añades un tercer disco; mejora la tolerancia a fallos sin mucho coste.
  • Red: Un switch gestionado de 8 puertos 1 GbE (por ejemplo, Netgear GS108Tv3) permite VLANs para separar tráfico de gestión y de workloads.
  • GPU opcional: Cuando el presupuesto lo permita, adquiere una tarjeta con al menos 6 GB VRAM y conectores de alimentación estándar; monta en un chasis con espacio para la GPU y una fuente de 500 W.

3. Instalación de Proxmox

  1. Graba la ISO oficial de Proxmox VE en una USB.
  2. Arranca cada mini PC, instala en el NVMe dedicado al hipervisor.
  3. Configura la red estática y habilita NTP.
  4. Crea un clúster con pvecm create homelab-cluster en el primer nodo y pvecm add <IP‑master> en los demás (ver bloque de código).
  5. Activa el repositorio pve-enterprise o pve-no-subscription según la política de licencias.

4. Despliegue de k3s en VMs

  • Crea una plantilla LXC basada en Ubuntu 22.04 con 2 vCPU y 8 GB RAM.
  • Instala curl -sfL https://get.k3s.io | sh - dentro de la VM.
  • Usa k3s kubectl para validar los nodos y aplicar los manifests de ArgoCD, Prometheus y Loki.
  • Configura un Ingress (Traefik) para exponer servicios internos y el UI de Grafana.

5. Integración de CI/CD y IaC

  • Define un proyecto Git con pipelines que ejecuten terraform apply -var-file=env.tfvars para crear VMs y ansible-playbook site.yml para provisionar paquetes dentro de los contenedores.
  • Conecta ArgoCD a ese repositorio; cada push a la rama main dispara una sincronización automática del clúster.

6. Preparación para la GPU

  • Reserva una VLAN exclusiva para el nodo GPU.
  • Cuando la tarjeta llegue, crea una VM con passthrough PCI (hostpci0: 01:00.0,pcie=1).
  • Instala los drivers NVIDIA y nvidia-container-toolkit para que los contenedores de Ollama o TensorFlow accedan a la GPU.

Cuándo aplicar esta solución

  • Presupuesto limitado: Ideal para rangos de 500‑800 €, donde la prioridad es aprender y experimentar, no producción de alta carga.
  • Necesidad de aislamiento: Si requieres varios entornos (dev, test, CI) sin interferencias, la capa de virtualización es esencial.
  • Plan de expansión a IA: Cuando se prevé añadir GPU en el futuro, la arquitectura basada en VMs permite el passthrough sin rehacer el clúster.

No es la mejor opción si:

  • Se necesita rendimiento GPU al 100 % desde el día uno (una solución bare‑metal sería más eficiente).
  • El workload incluye bases de datos de alta I/O que requieren almacenamiento en SAS o NVMe en RAID‑10.
  • Se busca una solución “plug‑and‑play” sin gestión de hipervisor.

Código

# En el nodo maestro
pvecm create homelab-cluster
pvecm addnode <IP_DEL_SEGUNDO_NODO>
pvecm addnode <IP_DEL_TERCER_NODO>

# Instalar k3s dentro de la VM LXC (Ubuntu 22.04)
curl -sfL https://get.k3s.io | sh -
# Verificar nodos
k3s kubectl get nodes

Verificación

  1. Accede a la UI de Proxmox y comprueba que los tres nodos aparecen como Online y que el cluster muestra Quorum.
  2. En la VM con k3s, ejecuta k3s kubectl get pods -A; todos los pods del sistema (kube-system) deben estar en estado Running.
  3. Abre Grafana (puerto 3000) y verifica que los dashboards de CPU, memoria y latencia de red reciben datos de Prometheus.
  4. Si el nodo GPU está conectado, ejecuta docker run --gpus all nvidia/cuda:12.0-base nvidia-smi dentro de un contenedor; la salida debe listar la GPU.

Notas adicionales

  • ZFS: habilita compression=lz4 y recordsize=4K para reducir la carga de escritura de los logs de Loki.
  • Backup: programa snapshots de ZFS cada 12 h y replica a un disco externo mediante zfs send/receive.
  • Seguridad: desactiva el acceso root por SSH, usa claves SSH y habilita fail2ban dentro de las VMs.
  • Consumo: los mini PCs consumen < 30 W en idle; con carga completa rondan los 70 W, lo que mantiene la factura eléctrica bajo control.
  • Actualizaciones: mantén Proxmox y el kernel alineados; prueba primero en una VM de prueba antes de actualizar los nodos de producción.

Con esta arquitectura, cualquier ingeniero que cuente con medio mil euro puede montar un homelab robusto, experimentar con Docker, Kubernetes y pipelines de DevOps, y escalar sin sobresaltos cuando llegue el momento de probar modelos de IA locales.