Homelab – no es solo hardware.
Hace unos días decidí actualizar la pagina donde trato de llevar un listado del hardware que compone mi homelab. Desde hace un tiempo muchas personas han querido introducirse en esta practica, muchos lo logran, otros no, desde mi punto de vista el tema es mas que solo tener hardware, es tener una meta y cumplirla haciendo uso de un sofware en ese hardware.
https://arielantigua.com/weblog/home-lab/
Luego de la introducción un poco desconectada, aquí les presento el sofware que uso en casa para mantenerme actualizado.
Virtualización:
Siempre seré un fiel seguidor de las soluciones de visualización, aunque a simple viste se podría decir que solo uso la solución de VMware para esto, déjenme decirles (escribirles) que no es así, he usado varias soluciones y antes de conocer VMware, era fanático de Xen (hasta que lo adquirió Citrix…).
BUNKER – Es un R420 el cual hace unos días recibió un upgrade el cual permitirá tener mas ambientes de pruebas, actualmente correo ESXi 7.0.
Este equipo tiene 1.2TB de SSD, 2 Xeon E5-2420v2 y 192GB de RAM.
No siempre fue así, anteriormente no contaba con el performance necesario y esto me llevo a tener otros equipos con menos prestaciones para distribuir la carga.
Así es como se ve actualmente este equipo desde el punto de vista de vSphere:
Que se puede ver?
- Tres maquinas virtuales que tienen ESXi 7.0 (Nested Virtualization).
- Tres maquinas virtuales las cuales fueron aprovisionadas desde Rancher para crear un cluster de Kubernetes (1 master + 2 workers).
- Dos maquinas virtuales a las cuales se le instalo Proxmox para probar clustering HA con GlusterFS.
Y al final se puede ver vCenter server. He decido dejarlo en este host por los recursos de RAM que posee, si queremos que vCenter funcione bien, debemos asignarle mucha RAM.
La idea es que BUNKER sea un host para crear laboratorios que necesiten mucha RAM y que en su mayoría serán nested, actualmente estoy planeando probar Tanzu en un host nested con 64GB de RAM.
NUC1 – es un pequeño NUC con un i5 y 16GB de RAM, esta también tiene ESXi 7.0 y la idea detrás de este pequeño vSphere host fue tener vCenter allí, lamentablemente con el consumo de RAM que tiene vCenter esto no es posible así que actualmente la labor de este host es hospedar dos host. K0 es un Ubuntu Server con k3s y el UI de Rancher, K1 es otro Ubuntu Server con k3s y funciona como el master node del cluster de Kubernetes que uso como producción de la casa.
TANK – Este es el tercer servidor físico con ESXi 7.0, es un R210II el cual adquirí son el motherboard dañado, procedí a reemplazarlo y al final termine cambiándole el procesador y llevándolo al máximo de memoria RAM que son 32GB ECC unregistered. En este equipo es donde están la mayoría de VMs de “producción” y las cuales me gustaría que funcionen sin problemas. Sin embargo, en el ultimo anno he hecho mucho con Kubernetes y poco a poco he migrado servicios que tenían su propia VM a un Deployment de k8s.
En este host tenemos lo siguiente:
EVE – Esta VM corre EVE-NG versión community, esta plataforma me permite correr una gran variedad de equipos de red para hacer pruebas, normalmente pruebo RouterOS y Linux. Me preguntaran por que correr Linux en EVE-NG, es mas sencillo hacerlo en EVE que correr VM para probar funcionalidades de routing. Así puedo interconectar hosts con BIRD a RouterOS y hacer pruebas de BGP antes de intentar cambiar algo en mi red productiva y terminar sin conectividad.
kw1 – kw2 – Estas VM son dos Ubuntu server que tienen k3s y funcionan como Workers del cluster de Kubernetes.
leela – es un Ubuntu server corriendo mail-cow para hospedar correo para mis dominios.
mom – es un Ubuntu server con LXD, hace anos que inicie un host físico con LXD y fue cambiando de host hasta que la ultima migración fue de un NUC gen2 a esta VM la cual también ha estado en todos los hosts de ESXi que tengo en casa. En este LXD tengo 3 contenedores con importancia.
vpn – es un Ubuntu Server con Pritunl instalado e IP Publica para tener acceso a mi red cuando estoy en lugares que no permiten L2TP.
Kubernetes y Rancher
Ademas de algunos productos de VMware, en el ultimo ano he aprendido bastante de Kubernetes, teniendo este conocimiento, poco a poco he iniciado una migración de servicios y herramientas que anteriormente estaban en VMs y ahora están en Pods.
K3s – Rancher UI.
Las herramientas de Rancher han permitido una rápida evolución de mi aventura con Kubernetes, esto es debido a una excelente comunidad y una clara documentación. Inicialmente usaba RKE para los nodos, luego apareció k3s y pude apreciar que la diferencia en consumo de recursos en un mismo host era abismal, esto es debido a lo pequeño que es k3s y a que no viene con Docker (en mi opinion). En ese momento incie el cambio de nodos desde RKE a k3s.
Actualmente tengo un host con k3s donde se ejecuta el UI de Rancher, desde este UI puedo administrar otro cluster de k3s que tiene 6 nodos (1 master + 5 workers), aquí tengo una mezcla ya que 3 de estos workers son maquinas físicas (kw0, kw4 y kw5) y dos son VMs (kw1 y kw2).
Mas adelante haré una nueva entrada de todos los Deployments que corren en el cluster de “producción” y las diferencias luego de mover estos servicios desde maquinas virtuales a Deployments de k8s.