Подскажите, какие есть адекватные альтернативы metallb?

PureLB

благодарю

а чем не устроил? Я вот жду пока допилят cilium bgp cp, а так metallb более чем отличный

изучаю вопрос с сохранением source ip. Насколько понял, металлб без изменения externaltrafficpolicy в local не умеет сохранят сурс ип, т.к. не поддерживает proxy-protocol v2. Вот решил посравнивать с другими балансерами. Мб я вообще туплю и металлб умеет, но пока не разобрался

Не поддерживает кто? Я именно по этому и не юзаю bgp cp, а в metallb работает

Оно же не балансеры делает, а просто трафик роутит. Proxy protocol там в теории не может быть

kube-router)

ты металлб в л2 мод юзаешь да?

А напомни плиз каким образом трафик на nodePort заворачивается в metallb. Под рукой нет. Спикер делает dnat правило в iptables для порта из сервиса? Чёт я туплю, а под рукой metallb нет, чтобы глянуть

Спикер просто занимается анонсом ip, балансировка осуществляется через ipvs/iptables поэтому в л2 мод юзается cluster а не local - чтобы можно было балансить трафик до эндпоинтов, так арп анонс будет идти толькл с одной ноды, как и в случае с вррп

ага в нём

Тогда не важно какой агент ты выберешь (металлб, пьюрлб и тп), от физики не уйдешь. Тебе либо анонсить по бгп нужно лб айпи, либо отказаться от балансировки и использоватьexternaltrafficpolicy: Local, либо оставить cluster но терять реал айпи за натом

есть над чем подумать, спасибо)

не, я про порты. Уже глянул. kube-proxy/kube-router/cilium dnat'ят просто. По совпадению externalIP:port

А каким образом бгп поможет? Чтобы обратиться к ip lb в любом случае надо сделать arp-запрос на это адрес. Что в случае bgp изменится?

в том, что при анонсе эникаст в бгп, эникаст никак не завязан на арп

Ты со 2 уровня сейчас уходишь на 3. А без второго в любом случее сетевое взаимодействие работать не будет. Мне непонятно что на 2 уровне меняется? Рядом стоящий сервер, ничего не знает про бгп, но знает, что чтобы обратиться к ip lb надо направить широковещательный arp-запрос с целью выснить mac. В этой схеме разве что-то меняется?

а даже не знаю как отвветить не отправляя читать матч часть: предположим есть сервер1 который анонсит ip address 1.1.1.1 котрпый прописан на loopback, у сервера есть интерфейс eht0 у него на интерфейсе ip - 192.168.0.2, пиринг бгп держит с роутером с ip 192.168.0.1 вопрос - зачем в этой схема арп запрос на 1.1.1.1 иил вообще знать мак адрес 1.1.1.1?

тут все понятно, непонятно как будет это работать, если рядом стоящий ПК с windows захочет обратиться к ip lb 1.1.1.1? Как он сможет обратиться к 1.1.1.1 без выполнения arp-запроса?

а если эта винда обратится на 8.8.8.8 ? точно так же - на основе маршрутизации

ты снова переходишь на 3 уровень, а мне непонятно, что меняется на 2. Если у меня 3 сервера metallb и виндоус-пк захочет обратиться на ip-lb 1.1.1.1, то он сделает arp-запрос. В ответ придет 1 ответ? От спикера, который анонсировал адрес?

не делает запрос, он сделает арп хапрос на некст хоп в таблице маршрутиазции, а не на дст адресс в пакете

Почему не делает широковещательный запрос, если он в одной сети с ip lb?

зачем винда будет делать ара запрос если хост не в ее подсети ? она просто отправит запрос на шлюз по умолчанию

Я как раз рассматривал случай, когда диапазон metallb входит в сеть, в которой заведены ip-адреса worker-нод. У меня так сделано.