Odocumentação do MetalLBafirma que:
No modo camada 2, todo o tráfego de um IP de serviço vai para um nó.
No meu entender, isso se deve principalmente ao fato de que:
um nó assume a responsabilidade de anunciar um serviço na rede local.
Conforme mencionado no restante da referida documentação, este comportamento implica uma limitação severa. A largura de banda do tráfego é limitada ao que pode passar pelo nó eleito. Mas isso é devido ao ARP conforme afirmado na documentação?
Uma solução que eu poderia imaginar para remover essa limitação é ter um “alto-falante” por nó. Quando um novo conjunto de pod e serviço é implantado, o alto-falante em execução no nó que executa o novo nó é responsável pelo anúncio ARP. Dessa forma, o tráfego de entrada sempre segue a rota ideal. É tecnicamente viável?
Responder1
MetalLB está correto. Jogar jogos de endereçamento de nível 2 significa que apenas um host pode receber tráfego unicast por vez. Por endereço de serviço.
Say 2001:db8:c0ba:4816::aé o endereço do serviço e atualmente está apontando para uma NIC na Ethernet 6E:17:C2:2E:F4:A4. Uma falha nesse host aciona um failover. Acontece alguma descoberta de vizinho e agora aponta para um host diferente com 6E:17:C2:2E:E7:B8. Não há oportunidade de multicaminho, o protocolo HA e a carga de trabalho unicast são muito simples para isso. Claro que poderia ter mais endereços de serviço, então adicione 2001:db8:c0ba:4816::bquais poderiam ir para outro host, possivelmente não utilizado.
Uma configuração ativa/passiva como essa será familiar aos usuários de clusters VRRP ou PowerHA. Exceto que o MetalLB reimplementou suas próprias coisas por algum motivo.
O modo MetalLB BGP é diferente, roteamento de camada 3. O que torna o ECMP possível se vários próximos saltos forem instalados para a rota de endereço de serviço. Compare com designs paragrandes balanceadores de carga de vários níveis usando ECMP.
Um host ativo por IP de serviço pode não ser um problema, dependendo do design. Os hosts podem ser ampliados bastante, talvez com links de 25 Gb. Se necessário, o trabalho real pode ser movido para outros hosts, deixando apenas um proxy para encerrar as conexões front-end.