Балансировка входящего трафика на физическом сервере: MetalLB, BGP и L2 в Kubernetes

MetalLB стал популярным решением для организации внешнего доступа к Kubernetes, когда облачный балансировщик недоступен. В сочетании с режимами BGP и L2 он позволяет построить отказоустойчивый сервис‑уровень, а платформа Deckhouse добавляет механизм сохранения активных соединений при падении узла.

Проблемы доступа к Kubernetes на физическом сервере

При развертывании кластера на собственных серверах традиционный способ — NodePort — выдаёт случайные порты, что усложняет настройку firewall и затрудняет работу с клиентскими приложениями. Облачные балансировщики (например, ELB) недоступны, а настройка собственного L4‑балансировщика требует отдельного программного обеспечения и поддержки. Кроме того, без автоматического failover любой отказ узла приводит к потере всех соединений, что недопустимо для бизнес‑критичных сервисов. Эти ограничения заставляют искать решение, которое бы использовало уже существующие узлы кластера и обеспечивало высокую доступность без дополнительных затрат.

MetalLB: базовый механизм и режимы

MetalLB реализует протоколы L2 (ARP) и BGP, позволяя объявлять IP‑адреса, принадлежащие сервисам типа LoadBalancer, на уровне сети. В режиме L2 каждый узел отвечает на ARP‑запросы, распределяя трафик по MAC‑адресам, а в режиме BGP узлы объявляют адреса в маршрутизаторе провайдера, что даёт более масштабируемое решение. MetalLB автоматически отслеживает состояние узлов и переключает трафик на здоровый экземпляр при возникновении отказа. Конфигурация хранится в виде обычного манифеста Kubernetes, что упрощает интеграцию с CI/CD‑процессами. Поддержка протокола BGP требует наличия BGP‑демона (например, bird) и корректных соседних роутеров, но даёт возможность балансировать трафик без необходимости в отдельном L4‑устройстве.

BGP‑режим: детали и преимущества

В режиме BGP MetalLB объявляет пул IP‑адресов в соседний маршрутизатор, который затем распределяет запросы между узлами кластера. Основные преимущества: 

• Масштабируемость — можно обслуживать тысячи запросов без перегрузки ARP‑таблиц.
• Контроль над маршрутами — администратор задаёт локальные префиксы и политики, минимизируя влияние внешних атак.
• Быстрое переключение — при падении узла BGP‑сообщения о недоступности распространяются за секунды, что снижает время простоя.

Типичная настройка включает объявление CIDR‑пула (например, 192.168.100.0/24), указание соседних IP‑адресов роутера и параметров таймаутов. При этом важно обеспечить совместимость BGP‑демона с оборудованием провайдера и правильно настроить аутентификацию (MD5‑ключи) для предотвращения подмены маршрутов.

L2‑режим: детали и когда уместно

L2‑режим подходит для небольших кластеров, где нет возможности изменить маршрутизацию провайдера. MetalLB отвечает на ARP‑запросы от шлюза, распределяя трафик между узлами по MAC‑адресам. Этот подход прост в реализации: достаточно указать пул IP‑адресов и включить режим L2 в конфигурации. Однако он имеет ограничения: 

• Ограниченный размер ARP‑таблицы — при большом числе сервисов может возникнуть конфликт.
• Меньшая гибкость — нет возможности управлять приоритетами маршрутов.
• Зависимость от широковещательного трафика — в больших сетях широковещание может быть ограничено.

Для небольших корпоративных сетей L2‑режим часто оказывается достаточным, особенно когда требуется быстрое развёртывание без изменения инфраструктуры провайдера.

Deckhouse: сохранение соединений при отказе узла

Платформа Deckhouse добавляет к MetalLB механизм active‑connection‑preservation. При обнаружении падения узла Deckhouse автоматически перенаправляет открытые TCP‑соединения на здоровый репликационный под, используя iptables‑правила и технологию conntrack. Это позволяет клиентским приложениям продолжать работу без повторных запросов и без потери данных. Фишка реализована как отдельный модуль Deckhouse, который интегрируется с MetalLB через CRD‑объекты, обеспечивая синхронное обновление таблиц маршрутизации. В результате бизнес‑процессы сохраняют свою доступность даже при одновременном отказе нескольких узлов, что критично для сервисов с долгоживущими соединениями (например, WebSocket или gRPC).

Практические рекомендации

• Выберите режим в зависимости от размеров сети: для небольших кластеров предпочтителен L2, для крупных — BGP.
• Настройте мониторинг состояния узлов: используйте readiness‑probes и liveness‑probes, чтобы MetalLB своевременно переключал трафик.
• Обеспечьте аутентификацию BGP‑сессий: включите MD5‑ключи и ограничьте диапазоны IP‑адресов соседних роутеров.
• Внедрите Deckhouse модуль сохранения соединений: проверьте совместимость с вашими сервисами и протестируйте переключение в тестовой среде.
• Проведите нагрузочное тестирование: имитируйте отказ узла и измерьте время переключения, чтобы убедиться в соответствию SLA.

Для проверки корректности конфигурации сети и открытых портов можно воспользоваться модулем network платформы Perimeter. Он сканирует все узлы кластера, выявляет несоответствия в BGP‑пирах и проверяет доступность объявленных IP‑адресов, позволяя быстро обнаружить ошибки до их появления в продакшене.