Всем привет! У меня возник вопрос по Linux ip routes. Вчера ставил

MetalLB себе в домашний кластер Kubernetes который развернут на 3-х виртуалках (KVM, 1 master, 1 etcd, 2 worker, CNI - flannel), у него есть address_pool из которого он выдает IP адреса для сервисов типа LoadBalancer.

Подсеть виртуалок 200.0.0.0/24, а для MetalLB я выдал pool из 10.5.0.50-10.5.0.200. Как я прочитал в одном из гайдов, в такой ситуации (не совпадение подсетей) требуется добавить ip route с одной сети, на другую. Но мне, если честно, не понятно как это работает.

По идеи у нас есть набор адресов 1 (200....) и 2 (10.0.5......), они отличны по размеру. Как я понимаю, если мы сделаем ip route на каждой ноде (руками/скриптом/не важно) со 2-го пула на подсеть (допутсим, ens3), то мы сможем достучаться до этих адресов через некий gateway, как это работает?

Проблему я решил тупо поставив пулл в рамках виртуальной подсети 200.0.0.50-200.0.0.100

P.S. OS на нодах ubuntu 20.04

Меня в гугле забанили, извините, и заранее спасибо неравнодушным)))

ip route не нужен

Хм... Вчера читал вот эту статью https://itnext.io/configuring-routing-for-metallb-in-l2-mode-7ea26e19219e Говорят делать через ip route / iptables Не подскажешь пожалуйста, как быть если возникнет подобная ситуация в будущем? Спасибо

лучше у @kvaps уточнить

ip route нужен для того чтобы твои ноды могли роутить в эту подсеть.

а зачем

Всё что делает metallb - просто вешает /32 айпишник на интерфейс, если там нет айпишника из той же подсети на интерфейсе нужно добавить роут

Да, ток если речь не идет про bpf-маскарад на нодах

типа как в цилиум?

Цилиум или калико, да

объясню по другому, когда ты делаешь ip addr add 1.2.3.4/24 dev eth1 то у тебя автоматически появляется роут, как если бы ты сделал: ip route add 1.2.3.0/24 dev eth1 таким образом добавление новых айпишников из тойже подсети будет работать без проблем: ip addr add 1.2.3.7/24 dev eth1 Теперь о том, как работает metallb, он делает примерно следующее: ip addr add 1.2.3.8/32 dev eth1 таким образом у тебя появляется айпишник на интерфейсе, но не появляется роут в подсеть 1.2.3.0/24, чтобы это "исправить" нужно сделать: ip route add 1.2.3.0/24 dev eth1

Это хорошо когда немного серверов а когда их даже 5 а адресов например 20 на каждом, и нужен фуллмеш как то упороться можно

Та я ж не спорю с этим. Говорю лишь о том, что ты можешь прописать маршрут, но bpf/xdp-программа, которая к твоему интерфейсу привязана может его проигнорить в конечном итоге

То есть, если мы повесили IP на устройство (создали роут) то стучась по этому IP мы можем дойти до наших сервисов, "игнорируя" пул адрессов внешней подсети? upd: или нужен какой-то гейтвей который будет слушать внешний IP?

когда у меня стояла такая задача мы просто init-containerом к metallb раскатывали на ноды что-то типа ip route add 1.2.3.0/24 dev eth0.100 а дальше айпишниками рулил уже metallb

Хитро ))

хз, с цилиумом это работало без проблем

Если у тебя за этим устройством сети твоих сервисов и обратный маршрут есть то да ))

ну nginx-ingress-controller крутится, вроде как за reverse-proxy сойдет) Дилетант в плане сетей, извини, и спасибо)))

Ты не путай L4-7 и L3