Модуль реализует механизм LoadBalancer для сервисов в кластерах bare metal.

Поддерживает следующие режимы работы:

  • Режим Layer 2 — реализует улучшенный (относительно стандартного режима L2 в MetalLB) механизм балансировки в кластерах bare metal, который позволяет использовать несколько «публичных» адресов для сервисов кластера.
  • Режим BGP — полностью основан на решении MetalLB.

Режим Layer 2

В режиме Layer 2 один или несколько узлов берут на себя ответственность за предоставление сервиса в «публичной» сети. С точки зрения сети это выглядит, как будто каждый из узлов имеет несколько IP-адресов, назначенных его сетевому интерфейсу. Технически это реализовано следующим образом: модуль отвечает на ARP-запросы для IPv4-сервисов и NDP-запросы — для IPv6. Основное преимущество режима layer 2 — его универсальность: он работает в любой сети Ethernet, не требуя специального оборудования.

Преимущества модуля перед классическим MetalLB

MetalLB в режиме L2 позволяет заказать Service с типом LoadBalancer, работа которого основана на том, что в пиринговой сети узлы-балансировщики имитируют ARP-ответы от «публичного» IP. Этот режим имеет существенное ограничение — единовременно лишь один балансировочный узел обрабатывает весь входящий трафик данного сервиса. Соответственно:

  • Узел, выбранный в качестве лидера для “публичного” IP становится “узким местом” без возможности горизонтального масштабирования.
  • В случае выхода узла-балансировщика из строя, все текущие соединения будут разорваны в процессе переключения на новый узел, который будет назначен лидером.

Данный модуль помогает обойти эти ограничения. Он предоставляет новый ресурс MetalLoadBalancerClass, который позволяет с помощью nodeSelector связать группу узлов и пул IP-адресов. После чего можно создать стандартный ресурс Service с типом LoadBalancer и в нем указать имя обслуживающего MetalLoadBalancerClass’a, а с помощью аннотации указать необходимое количество IP-адресов для L2-анонсирования.

Таким образом:

  • Приложение получит не один, а несколько «публичных» IP. Эти IP потребуется прописать в качестве A-записей для публичного домена приложения. Для последующего горизонтального масштабирования потребуется добавить дополнительные узлы-балансировщики. Соответствующие Service будут созданы автоматически, потребуется лишь добавить их в список A-записей прикладного домена.
  • При выходе из строя одного из узлов-балансировщиков, лишь часть трафика будет подвержена обрыву для переключения на здоровый узел.

Режим BGP

Доступно только в редакции Enterprise Edition.

Metallb в режиме BGP предоставляет эффективный и масштабируемый способ предоставления Service’ов типа LoadBalancer в кластерах Kubernetes, работающих на «голом железе». Благодаря использованию стандартизированного протокола BGP, metallb легко интегрируется в существующую сетевую инфраструктуру и обеспечивает высокую доступность Service’ов.

Принцип работы metallb в режиме BGP

В режиме BGP metallb устанавливает BGP-сессии с маршрутизаторами (или с Top-of-Rack коммутаторами) и анонсирует им IP-адреса сервисов типа LoadBalancer. Это достигается следующим образом:

Конфигурация.

  • Metallb конфигурируется с указанием пула IP-адресов, которые он может назначать Service’ам.
  • Определяются параметры BGP-сессий: AS (Autonomous System) number кластера Kubernetes, IP-адреса маршрутизаторов (пиров), AS number пиров, пароли для аутентификации (опционально).
  • Для каждого пула IP-адресов можно задать специфические параметры анонсирования, например, community strings.

Установка BGP-сессий.

  • На каждом узле кластера Kubernetes, где запущен metallb, компонент speaker устанавливает BGP-сессии с указанными маршрутизаторами.
  • Происходит обмен маршрутной информацией между metallb и маршрутизаторами.

Назначение IP-адресов Service’ам.

  • Когда создается Service типа LoadBalancer, metallb выбирает свободный IP-адрес из сконфигурированного пула и назначает его Service’у.
  • Компонент controller отслеживает изменения в Service’ах и управляет назначениями IP-адресов.

Анонсирование IP-адресов.

  • После назначения IP-адреса speaker на узле, выбранном лидером для данного Service’а, начинает анонсировать этот IP-адрес через установленные BGP-сессии.
  • Маршрутизаторы получают этот анонс и обновляют свои таблицы маршрутизации, направляя трафик к этому IP-адресу на узел, анонсирующий его.

Распределение трафика.

  • Маршрутизаторы используют протоколы ECMP (Equal-Cost Multi-Path) или другие алгоритмы балансировки для распределения трафика между узлами, анонсирующими один и тот же IP-адрес Service’а.
  • Внутри кластера Kubernetes трафик, поступивший на узел, перенаправляется на поды Service’а с помощью механизмов используемого CNI (iptables/IPVS, eBPF-программы и т.д.).

Преимущества использования BGP

  • Стандартизированный протокол. BGP — широко используемый и хорошо зарекомендовавший себя протокол маршрутизации.
  • Гибкость и масштабируемость. BGP позволяет интегрировать кластер Kubernetes в существующую сетевую инфраструктуру и масштабировать сервисы.
  • Распределение нагрузки. Использование ECMP позволяет эффективно распределять нагрузку между узлами кластера.
  • Отказоустойчивость. При выходе из строя узла, анонсирующего IP-адрес, маршрутизаторы автоматически перенаправляют трафик на другие узлы, анонсирующие этот же IP.

Недостатки использования BGP

  • Сложность настройки. Настройка BGP может быть сложнее, чем настройка анонсов ARP/GARP (в режиме Layer 2).
  • Требования к сетевому оборудованию. Маршрутизаторы должны поддерживать BGP и ECMP.