Theдокументация MetalLBговорится, что:
В режиме уровня 2 весь трафик для IP-адреса службы направляется на один узел.
Насколько я понимаю, это в основном связано с тем, что:
один узел берет на себя ответственность за рекламу услуги в локальной сети.
Как упоминалось в остальной части указанной документации, такое поведение подразумевает серьезное ограничение. Пропускная способность трафика ограничена тем, что может пройти через выбранный узел. Но связано ли это с ARP, как утверждается в документации?
Решение, которое я могу себе представить, чтобы снять это ограничение, — иметь по одному «спикеру» на узел. Когда развертывается новый набор pod и сервиса, динамик, работающий на узле, который запускает новый узел, отвечает за объявление ARP. Таким образом, входящий трафик всегда идет по оптимальному маршруту. Это технически осуществимо?
решение1
MetalLB прав. Игра в игры с адресацией уровня 2 означает, что только один хост может получать одноадресный трафик одновременно. На адрес службы.
Say 2001:db8:c0ba:4816::a— это адрес службы, который в настоящее время указывает на сетевую карту в Ethernet 6E:17:C2:2E:F4:A4. Сбой в этом хосте запускает аварийное переключение. Происходит обнаружение соседей, и теперь он указывает на другой хост с 6E:17:C2:2E:E7:B8. Нет возможности многопутевого использования, протокол HA и одноадресная рабочая нагрузка слишком просты для этого. Конечно, можно было бы иметь больше адресов служб, поэтому добавьте, 2001:db8:c0ba:4816::bкоторые могли бы перейти на другой, возможно, неиспользуемый хост.
Такая активная/пассивная настройка будет знакома пользователям кластеров VRRP или PowerHA. За исключением того, что MetalLB по какой-то причине перереализовал свою собственную штуку.
Режим MetalLB BGP отличается, маршрутизация уровня 3. Что делает возможным ECMP, если для маршрута адреса сервиса установлено несколько следующих переходов. Сравните с проектами длябольшие многоуровневые балансировщики нагрузки с использованием ECMP.
Один активный хост на IP-адрес сервиса может не быть проблемой, в зависимости от дизайна. Хосты могут масштабироваться довольно сильно, возможно, с 25-гигабитными связями. При необходимости выполнение реальной работы можно перенести на другие хосты, оставив только прокси для завершения соединений front-end.