En el mundo del desarrollo y la gestión de Kubernetes, la eficiencia y la resiliencia de la red son componentes críticos para garantizar el funcionamiento óptimo de las aplicaciones. Durante años, MetalLB ha sido la opción predilecta para implementar el balanceo de carga en clusters Kubernetes que no cuentan con un proveedor de nube nativo. Sin embargo, con la evolución de las tecnologías, herramientas como Cilium han surgido ofreciendo una experiencia más integrada y avanzada para el manejo del tráfico y la seguridad de red. En este recorrido, comparto cómo migré de MetalLB a Cilium, exponiendo las motivaciones, configuraciones y beneficios de esta transición. MetalLB es ampliamente reconocido por su simplicidad y efectividad para proporcionar direcciones IP de servicio externas en ambientes donde el balanceo de carga tradicional de capa 4 no está disponible.
Opera principalmente con dos modos: capa 2 y BGP. El modo capa 2 funciona como mecanismo de fail-over, asegurando que si un nodo falla, otro pueda tomar el relevo sin interrumpir el servicio. Sin embargo, en esta modalidad no se implementa balanceo de carga real ya que todo el tráfico dirigido a una IP de servicio se concentra en un solo nodo y luego es distribuido internamente por KubeProxy. Por otro lado, el modo BGP es una opción más robusta y comparable funcionalmente con Cilium, ya que permite anunciar rutas usando protocolos dinámicos y mejora la eficiencia en el enrutamiento y el balanceo del tráfico. En mi entorno minimalista, compuesto por una infraestructura VMware ESXi con varias máquinas virtuales y un nodo adicional basado en Raspberry Pi 4 corriendo Ubuntu como worker, MetalLB en modo capa 2 cumplió su función inicial.
No obstante, a medida que el cluster creció y perdí flexibilidad en la gestión avanzada de IPs y rutas, consideré explorar alternativas que ofrecieran una gestión más inteligente y nativa de las funcionalidades de red dentro de Kubernetes, sin depender de soluciones externas. Aquí fue donde Cilium se presentó como la solución innovadora. Cilium es conocido por ser una herramienta con superpoderes para la red en Kubernetes, aportando no solo funcionalidades avanzadas de seguridad y visibilidad sino ahora también capacidades para el balanceo de carga nativas y dinámicas. Con el lanzamiento próximo de la versión 1.13, Cilium introduce la gestión de direcciones IP para balanceadores de carga a través de una función llamada LoadBalancer IP Address Management, o LB IPAM.
Esta herramienta elimina la necesidad de depender de MetalLB al permitir que el controlador de Cilium asigne y gestione direcciones IP para servicios de forma nativa dentro del ecosistema Kubernetes. LB IPAM se activa automáticamente cuando se crea un recurso personalizado (CRD) llamado CiliumLoadBalancerIPPool en el cluster. En mi caso, definí un pool reducido, ya que solo un servicio específico, el ingreso Nginx, necesitaba solicitar IPs. Esto se logra mediante la especificación de etiquetas en el selector de servicios, limitando así el acceso a las IP del pool solamente a los servicios que cumplan con los criterios, mejorando la seguridad y la organización. Además, el Cilium BGP Control Plane se encarga de anunciar estos bloques de IP dentro de la red.
La ventaja crucial es que el protocolo BGP no viene habilitado por defecto; debe activarse durante la instalación o actualización de Cilium mediante la configuración del parámetro --enable-bgp-control-plane=true. La configuración de las políticas de peering BGP en Cilium se realiza mediante el recurso CiliumBGPPeeringPolicy, donde se define con precisión qué nodos participan en el peering con routers externos, en este caso con Opensense, mi firewall y enrutador. Las políticas también pueden aplicarse selectivamente a servicios específicos mediante etiquetas, dando un control granular sobre qué rutas se anuncian y desde dónde. Opensense, al otro lado del peering, requiere la instalación adicional de un plugin BGP para activar esta funcionalidad. Su configuración, sin embargo, es sencilla: configurar el número de sistema autónomo (ASN) y agregar los vecinos BGP que recibirán los anuncios de rutas.
Este enfoque no solo facilita la integración sino que proporciona herramientas de diagnóstico para resolver posibles problemas en el entorno de red. Uno de los detalles que encontré fascinantes fue la posibilidad de asignar direcciones IP específicas a servicios particulares. Por ejemplo, asigné la IP 172.198.1.
1 al ingreso Nginx, que provenía del pool definido en CiliumLoadBalancerIPPool, mediante la anotación io.cilium/lb-ipam-ips en el servicio. Esta capacidad de control preciso asegura que servicios críticos mantengan direcciones estáticas cuando así se requiera. La migración en sí misma fue fluida y representó un avance importante en la gestión de redes dentro de Kubernetes. Al eliminar la dependencia de MetalLB, se redujo la complejidad operativa y se ganó en coherencia al centralizar toda la lógica de la red y el balanceo en una sola plataforma: Cilium.
Esta integración favorece la escalabilidad y la seguridad, dos factores primordiales en ambientes productivos y en desarrollo. Además, Cilium ofrece funciones adicionales de seguridad, como la visibilidad en tiempo real del tráfico, políticas basadas en identidades y un enfoque centrado en el modelo de aplicación, que amplían el valor del sistema más allá del simple balanceo de carga. En conclusión, la transición de MetalLB a Cilium representa para mí un salto cualitativo en la manera en que gestiono la red de mi cluster Kubernetes. La posibilidad de manejar balanceo de carga con IPs asignadas y anunciadas dinámicamente mediante BGP dentro del propio cluster, junto a la integración nativa con Kubernetes y la capacidad ampliada de seguridad, convierten a Cilium en una herramienta indispensable para administradores y desarrolladores que buscan maximizar el rendimiento y la confiabilidad de sus aplicaciones. La recomendación es estudiar detenidamente las funcionalidades específicas de Cilium, prepararse para la configuración avanzada de BGP y aprovechar sus amplias capacidades para llevar las implementaciones de Kubernetes a un nivel superior.
Así, cada servicio podrá contar con la robustez y agilidad necesarias en los entornos actuales y futuros de la computación en la nube y on-premises.
