Eldocumentación de MetalLBEstablece que:
En el modo de capa 2, todo el tráfico de una IP de servicio va a un nodo.
Según tengo entendido, esto se debe principalmente al hecho de que:
un nodo asume la responsabilidad de anunciar un servicio en la red local.
Como se menciona en el resto de dicha documentación, este comportamiento implica una limitación severa. El ancho de banda del tráfico está limitado a lo que puede pasar a través del nodo elegido. ¿Pero se debe a ARP como se afirma en la documentación?
Una solución que se me ocurre para eliminar esta limitación es tener un "altavoz" por nodo. Cuando se implementa un nuevo conjunto de pods y servicios, el altavoz que se ejecuta en el nodo que ejecuta el nuevo nodo está a cargo del anuncio ARP. De esta forma, el tráfico entrante siempre toma la ruta óptima. ¿Es técnicamente factible?
Respuesta1
MetalLB es correcto. Jugar juegos de direccionamiento de nivel 2 significa que sólo un host puede recibir tráfico de unidifusión a la vez. Por dirección de servicio.
Say 2001:db8:c0ba:4816::a
es la dirección del servicio y actualmente apunta a una NIC en Ethernet 6E:17:C2:2E:F4:A4
. Una falla en ese host desencadena una conmutación por error. Se produce un descubrimiento de vecino y ahora apunta a un host diferente con 6E:17:C2:2E:E7:B8
. No hay posibilidad de múltiples rutas, el protocolo HA y la carga de trabajo de unidifusión son demasiado simples para eso. Seguro que podría tener más direcciones de servicio, así que agregue 2001:db8:c0ba:4816::b
las que podrían ir a otro host, posiblemente no utilizado.
Una configuración activa/pasiva como esta resultará familiar para los usuarios de clústeres VRRP o PowerHA. Excepto que MetalLB reimplementó lo suyo por alguna razón.
El modo MetalLB BGP es diferente, enrutamiento de capa 3. Lo que hace posible ECMP si se instalan varios saltos siguientes para la ruta de la dirección de servicio. Comparar con diseños paragrandes balanceadores de carga de múltiples niveles que utilizan ECMP.
Un host activo por IP de servicio puede no ser un problema, según el diseño. Los hosts pueden crecer bastante, quizás con enlaces de 25 Gb. Si fuera necesario, el trabajo real podría trasladarse a otros hosts, dejando solo un proxy para terminar las conexiones frontales.