Este documento explica qué es MetalLB, por qué es necesario y cómo encaja en la arquitectura actual y futura del clúster.
No es solo una guía de instalación.
Es una explicación conceptual para entender qué problema resuelve hoy y cómo puede evolucionar mañana.
Cuando Kubernetes se ejecuta en la nube (AWS, Azure, GCP), existe un componente automático que:
En entornos bare-metal (servidores físicos propios), eso no existe.
Si creas un Service tipo LoadBalancer, Kubernetes no sabe cómo exponerlo hacia la red física.
👉 Aquí es donde entra MetalLB.
MetalLB permite que un servicio tenga una IP real dentro de tu red, como si fuera un servidor tradicional.
MetalLB es un controlador que permite a Kubernetes:
Puede trabajar de dos formas:
En términos simples:
👉 Hace que un servicio de Kubernetes tenga una IP "normal" y accesible desde tu infraestructura de red.
En modo L2:
Si el nodo cae:
Es ideal para:
En modo BGP, el funcionamiento cambia.
En lugar de anunciar la IP por ARP, el nodo establece una sesión BGP con el router y le anuncia:
"Para esta IP, enruta el tráfico hacia mí."
El router actualiza su tabla de rutas.
No hay broadcast.
No hay ARP compartido.
Hay routing dinámico real.
Si el nodo cae:
| Característica | L2 (ARP) | BGP |
|---|---|---|
| Complejidad | Baja | Media / Alta |
| Configuración en router | No | Sí |
| Dependencia de broadcast | Sí | No |
| Escalabilidad | Media | Alta |
| Multi-site real | Limitado | Excelente |
Actualmente el sistema funciona como un stretch cluster:
Este modelo permite alta disponibilidad, pero implica:
En este contexto, el modo L2 es suficiente.
Pero no es necesariamente el modelo final.
El uso de BGP abre la puerta a una evolución arquitectónica importante.
En lugar de mantener un único clúster distribuido, en el futuro podría adoptarse un modelo de:
En ese escenario:
Esto reduce el acoplamiento entre sedes.
Y convierte la arquitectura en algo más modular.
Define el rango de IPs que MetalLB puede usar.
Son IPs reales y libres dentro de la red.
Indica que el pool debe anunciarse por ARP.
Solo aplica en modo L2.
Debe activarse en kube-proxy cuando se usa modo L2.
Evita que varios nodos respondan simultáneamente por la misma IP.
Permite asignar explícitamente una IP concreta a un servicio.
Esto aporta:
MetalLB permite:
Sin MetalLB:
Después de leer este documento debe quedar claro que:
Exposición limpia hoy. Preparada para desacoplamiento y routing dinámico mañana.