Cuando Kubernetes se ejecuta en entornos on‑premise, en bare metal o sobre virtualización sin un balacenador de carga gestionado, aparece una limitación habitual: los servicios de tipo LoadBalancer no reciben una IP externa de forma nativa. En ese escenario, MetalLB en Kubernetes se convierte en una pieza clave para exponer servicios de forma controlada, con una arquitectura coherente y con criterios de alta disponibilidad.
En este artículo se revisa la arquitectura de MetalLB, sus casos de uso en producción y los errores más comunes que suelen degradar la disponibilidad o introducir incidencias difíciles de diagnosticar.
Qué es MetalLB en Kubernetes y qué problema resuelve
MetalLB es un balanceador de carga para Kubernetes diseñado para entornos que no disponen de un balanceadores de carga externos al propio entorno. Su objetivo es proporcionar un comportamiento equivalente al de un Service tipo LoadBalancer: asignar una IP externa (de un pool controlado) y anunciarla a la red para que el tráfico llegue al clúster.
En la práctica, MetalLB permite:
- Asignar IPs externas a servicios sin depender de un balanceador externo.
- Operar con pools de IPs definidos (segmentación, control y trazabilidad).
- Implementar exposición de servicios con criterios de disponibilidad acordes a producción.
Arquitectura de MetalLB: componentes y funcionamiento
Para usar MetalLB en Kubernetes de forma fiable conviene entender su arquitectura a alto nivel: por un lado decide qué IP se asigna a cada servicio, y por otro lado se encarga de anunciar esa IP a la red para que el tráfico llegue al clúster.
Plano de control: asignación de IPs
MetalLB gestiona la asignación de IPs externas a los servicios LoadBalancer a partir de pools de direcciones (rangos o bloques de IPs) que usted define. Con ello se evita:
- Asignación manual y propensa a conflictos.
- Uso de IPs fuera de segmentos autorizados.
- Exposición desordenada sin gobernanza (quién publica qué y dónde).
Plano de datos: anuncios a la red (L2 o BGP)
Una vez asignada una IP a un servicio, MetalLB debe hacer que la red sepa que esa IP es alcanzable a través del clúster. Esto se realiza mediante anuncios que, según el modo de operación, se apoyan en mecanismos de capa 2 o en enrutamiento dinámico.
Dos aproximaciones comunes:
- Modo L2 (capa 2): la IP se anuncia en la LAN (por ejemplo, mediante ARP/NDP), de forma que el tráfico se dirige al nodo que está anunciando esa IP.
- Modo BGP: la IP (o prefijo) se anuncia mediante BGP a uno o varios routers, permitiendo políticas de enrutamiento y escenarios más avanzados.
Elegir L2 o BGP no es una preferencia; depende de su red, de sus requisitos de alta disponibilidad y de cómo quiera controlar el tráfico.
Cómo encaja con Kubernetes (Service, kube-proxy e ingress)
MetalLB trabaja a nivel de Service tipo LoadBalancer. Esto significa que:
- Usted expone un servicio Kubernetes como LoadBalancer.
- MetalLB asigna una IP externa (del pool definido).
- El tráfico entra por esa IP y se enruta hacia los Pods mediante la lógica habitual del clúster (por ejemplo, kube-proxy/IPVS/iptables, según su configuración).
Un patrón frecuente en producción es combinar MetalLB con un Ingress Controller (por ejemplo, para HTTP/HTTPS) y usar MetalLB para publicar el servicio del Ingress como LoadBalancer. Así se obtiene una IP externa estable para la entrada al clúster.
Decisiones de diseño para producción (antes de activar MetalLB)
1) Definir pools de IPs con gobernanza
En producción conviene evitar pools genéricos sin criterio. Defina:
- Qué rangos son válidos para exposición externa.
- Qué segmentación aplica (DMZ, redes internas, entornos de preproducción, etc.).
- Qué procedimiento seguirá su equipo para solicitar o crear nuevos servicios externos.
Un pool bien definido reduce conflictos, acelera diagnósticos y mejora la seguridad operacional.
2) Elegir L2 o BGP en función de disponibilidad y red
Modo L2 suele ser más sencillo de desplegar en redes donde la capa 2 está controlada y no se requiere una arquitectura de enrutamiento avanzada. Sin embargo, puede introducir limitaciones en escenarios complejos o cuando se necesita un control fino del enrutado.
Modo BGP suele encajar mejor cuando se busca:
- Mejor integración con red (routers, políticas de routing y multipath según diseño).
- Más control sobre anuncios y rutas.
- Arquitecturas con requisitos estrictos de disponibilidad y escalabilidad.
La elección debe alinearse con su red (equipamiento y equipo de red) y con su objetivo de continuidad.
3) Alinear la exposición con requisitos de seguridad
Exponer servicios con IPs externas implica revisar:
- Control de acceso (firewalls, listas permitidas, segmentación).
- Gestión de certificados (si aplica a HTTPS).
- Monitorización y detección de anomalías.
- Procedimientos de cambios y rollback.
MetalLB facilita la publicación; su política de seguridad define si esa publicación es robusta.
Casos de uso de MetalLB en producción
Publicar un Ingress Controller con IP estable
Uno de los usos más comunes es asignar una IP externa al servicio del Ingress Controller. Con ello obtiene un punto de entrada único para HTTP/HTTPS y puede gestionar el enrutado por host/path dentro del clúster, manteniendo una IP estable en la red.
Exposición de servicios L4 (TCP/UDP) específicos
Servicios que no encajan en Ingress HTTP (por ejemplo, TCP o UDP) pueden publicarse con LoadBalancer. MetalLB asigna IP y la red puede alcanzar el servicio sin depender de NodePorts.
Entornos on‑premise y edge con control estricto de red
En infraestructuras on‑premise o edge, donde los rangos IP y las rutas deben estar controlados, MetalLB permite definir con precisión de qué bloques salen las IPs externas y cómo se anuncian, manteniendo consistencia entre entornos.
Homogeneizar el patrón de exposición entre entornos
Si su organización opera Kubernetes tanto en cloud como on‑premise, MetalLB ayuda a mantener un patrón similar de LoadBalancer en entornos sin proveedor cloud, reduciendo divergencias operativas.
Checklist de disponibilidad: cómo evitar sorpresas
Antes de llevar MetalLB a producción, valide al menos estos puntos:
- IPAM y conflictos: confirme que el pool no solapa con asignaciones DHCP u otros sistemas de gestión de IPs.
- Red y anuncios: valide que los anuncios (L2/BGP) se propagan como espera y que el retorno de tráfico no genera rutas asimétricas no deseadas.
- Pruebas de fallo: simule caída de nodos para confirmar que el servicio sigue siendo alcanzable dentro de los márgenes aceptables.
- Observabilidad: asegure logs, métricas y alertas sobre asignación de IPs, anuncios, errores de configuración y eventos.
- Procedimientos: documente cómo se publica un servicio nuevo, cómo se revoca y cómo se actúa ante incidencias.
Errores comunes en MetalLB que afectan a la disponibilidad (y cómo mitigarlos)
1) Pools de IPs mal definidos o solapados
Un error recurrente es definir pools que solapan con rangos en uso (DHCP, dispositivos estáticos, otras plataformas). Esto puede producir conflictos intermitentes y cortes difíciles de reproducir. Mitigue con gobernanza de IPs, coordinación con el equipo de red y validación previa del rango.
2) Publicar demasiados servicios sin un patrón claro
Exponer múltiples servicios como LoadBalancer sin un criterio (naming, segmentación, quién aprueba) aumenta el riesgo de errores y complica la auditoría. Defina un patrón: qué se publica vía Ingress, qué se publica L4 y quién lo autoriza.
3) Subestimar el comportamiento del tráfico y el retorno
En algunos diseños, el tráfico de entrada puede llegar por un camino y el retorno seguir otro, generando problemas de sesión o políticas de seguridad que bloquean el tráfico. Mitigue revisando el enrutado real, los firewalls intermedios y la coherencia de rutas esperada para el servicio.
4) Falta de pruebas de conmutación por error (failover)
Asumir que si funciona hoy, funcionará mañana suele terminar en incidentes. Pruebe la caída de un nodo que anuncia IP, valide el tiempo de recuperación y verifique que el servicio sigue siendo accesible para clientes reales.
5) Configuración de salud y exposición sin controles
Publicar un servicio externamente sin health checks adecuados, sin límites de acceso o sin monitorización puede hacer que una degradación interna se convierta en indisponibilidad externa. Mitigue con observabilidad, límites de acceso y validación periódica.
6) Problemas de ARP/NDP, filtrados o políticas de red (especialmente en L2)
En modo L2, ciertos entornos pueden tener particularidades (filtrados, reglas de seguridad o comportamiento de switches) que afectan a la propagación de anuncios. Mitigue coordinando con el equipo de red, revisando la configuración de switches y validando con pruebas controladas.
7) Cambios no gestionados y falta de rollback
Un cambio en pools, anuncios o en la exposición de servicios sin control de cambios y sin plan de rollback es un multiplicador de riesgo. Mitigue con procedimientos: control de cambios, ventanas, rollback y evidencia de pruebas.
FAQ sobre MetalLB en Kubernetes
Sirve para asignar y anunciar IPs externas a servicios tipo LoadBalancer en entornos donde no existe un proveedor cloud que lo haga automáticamente (por ejemplo, on‑premise o bare metal).
No. MetalLB aporta IP externa para servicios LoadBalancer. Un Ingress Controller gestiona el enrutado de HTTP/HTTPS a nivel de aplicación. En producción suelen complementarse: MetalLB publica el servicio del Ingress.
Depende de su red y de sus requisitos. L2 suele ser más sencillo; BGP ofrece mayor control e integración con enrutamiento. La decisión debe alinearse con disponibilidad, escalabilidad y capacidades de su equipo de red.
Conflictos de IP, anuncios mal propagados, rutas asimétricas no previstas, ausencia de pruebas de failover y falta de observabilidad. Con diseño y pruebas, estos riesgos se controlan.
Que el pool de IPs es correcto, que los anuncios funcionan, que el failover cumple el objetivo, que existe monitorización y que hay procedimientos de cambio y rollback.
Puede serlo si se diseña con gobernanza de IPs, criterios de red, pruebas de alta disponibilidad y operación day‑2 (monitorización, cambios y auditoría). En producción, cómo se opera es tan importante como el despliegue inicial.
Haga que la exposición de servicios en Kubernetes sea un proceso controlado
Si su clúster Kubernetes opera on‑premise o en bare metal y necesita publicar servicios con IP externa de forma fiable, MetalLB es una pieza relevante, pero requiere diseño, pruebas y operación consistente para no comprometer la disponibilidad.
Hopla puede ayudarle a definir la arquitectura de exposición, validar modos L2/BGP según su red y establecer procedimientos de operación para entornos de Kubernetes en producción.
