Durante mucho tiempo ignoré los backups de mi cluster K3s. Tenía Proxmox Backup Server para las VMs, tenía el backup 3-2-1 para los datos importantes… pero el estado del propio cluster, los deployments, los ConfigMaps, los PersistentVolumeClaims: nada. Si el cluster petaba, tocaba reconstruir desde cero.
Llegó el momento en que un fallo de disco en uno de los nodos de Longhorn me dejó dos PVCs corruptos. No perdí datos críticos, pero me pasé un fin de semana reconfigurando servicios que debería haber tenido respaldados. Esa semana instalé Velero.
Hay un problema que aparece tarde o temprano cuando llevas un tiempo con el homelab: necesitas almacenamiento de objetos compatible con S3. No porque seas Amazon, sino porque muchas herramientas modernas hablan S3 de forma nativa. Velero para backups de Kubernetes. Loki para logs. Restic, Rclone, Backblaze. Incluso algunas aplicaciones como Immich o Seafile pueden usar S3 como backend.
Si dependes de AWS S3 real, tienes un coste mensual variable y tus datos en manos de Amazon. MinIO resuelve eso: un servidor de objetos que habla la misma API que S3, que corres en tu propio hardware.
Un agente de IA que monitoriza tu infraestructura, revisa el email y ejecuta comandos en tu clúster K3s. Sin SaaS, sin datos que salen de tu red. Esto es lo que monté y lo que aprendí tras meses usándolo.
Después de perder datos por un nodo caído, instalé Longhorn en mi clúster K3s. Réplicas automáticas, backups a MinIO y snapshots integrados. Esto es lo que tendrías que saber antes de que te pase lo mismo.
Llevo tres años gestionando clusters Kubernetes. He aprendido kubectl, helm, kustomize, escribo YAMLs dormido, y aun así… hay días que abro Rancher y respiro tranquilo. Porque sí, kubectl es potente y la terminal mola. Pero cuando son las 3 de la mañana y algo se ha caído, ver gráficos de CPU en vez de piped JSON es la diferencia entre arreglarlo en 5 minutos o perder una hora.
Rancher no te convierte en peor administrador de Kubernetes. Te convierte en uno más eficiente. Y eso es lo que vamos a montar hoy.
Tres ZimaBoard 2, una VPN mesh y ganas de sufrir. Así monté un clúster Kubernetes de producción que consume 20W y corre 34 pods. Tutorial paso a paso con todo lo que funcionó y lo que no.
He cometido el error dos veces ya. Montar algo “rapidito” en Docker Compose, que crece, se complica, y termino pasándolo a Kubernetes porque ya no puedo gestionarlo. Luego está el error contrario: montar un cluster K3s completo para hostear un solo contenedor que perfectamente podría vivir en un docker-compose.yml de tres líneas.
Después de gestionar ambos sistemas durante años en mi homelab (ahora mismo tengo varios equipos con Compose y un cluster K3s de tres nodos en ZimaBoard 2), creo que finalmente entiendo cuándo usar cada uno. Spoiler: no es solo “Compose para cosas simples, Kubernetes para lo complejo”. Es más sutil que eso.
Google Photos lleva años con mis recuerdos en sus servidores. Lo cambié por Immich corriendo en mi cluster K3s. Te cuento cómo lo monté, qué funciona, qué no, y por qué no volvería atrás.
