Настройка внешней маршрутизации в bare-metal Kubernetes: полное руководство по MetalLB и BGP | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Настройка внешней маршрутизации в bare-metal Kubernetes: полное руководство по MetalLB и BGP

03 апреля 2026 10 мин. чтения
Содержание статьи

Развертывание Kubernetes на собственном оборудовании (bare-metal) открывает путь к полному контролю над инфраструктурой и снижает стоимость владения. Однако одна из ключевых проблем такой среды — отсутствие автоматического механизма предоставления внешних IP-адресов сервисам типа LoadBalancer, который в облаках предоставляется провайдерами. В результате администраторы часто ограничиваются NodePort, что усложняет управление доступом и не масштабируется. MetalLB с протоколом BGP решает эту проблему, позволяя кластеру Kubernetes напрямую анонсировать маршруты до выделенных IP-адресов на корпоративные маршрутизаторы, создавая полноценную, отказоустойчивую и масштабируемую систему внешнего балансирования трафика.

Это руководство предоставляет проверенную на практике, пошаговую инструкцию для production-среды. Вы освоите установку и конфигурацию MetalLB, интеграцию с Ingress-контроллером и диагностику типичных проблем, получив готовое решение для организации входящего трафика в bare-metal кластер без зависимости от облачных сервисов.

Проблема LoadBalancer в bare-metal и почему MetalLB — решение

В облачных Kubernetes (AWS, GCP, Azure) сервис типа LoadBalancer автоматически получает публичный IP от провайдера. В bare-metal кластер этот механизм отсутствует: создание такого сервиса приводит к бесконечному статусу Pending. Обычно используют NodePort, который открывает порт на каждом узле, но это создает сложности с управлением доступом, требует дополнительной внешней балансировки и не является полноценной заменой LoadBalancer.

MetalLB — это проект с открытым исходным кодом, который реализует контроллер LoadBalancer для bare-metal кластеров Kubernetes. Он работает в двух режимах:

  • Layer 2 Mode: Использует ARP/NDP для анонса IP на локальной сети. Проще в настройке, но имеет ограничения масштабирования и отказоустойчивости (один узёл отвечает за IP).
  • BGP Mode: Использует протокол Border Gateway Protocol (BGP) для анонсирования IP-адресов на внешние маршрутизаторы. Это стандартный, масштабируемый и отказоустойчивый подход, идеальный для корпоративных сетей.

Выбор BGP для production обусловлен его преимуществами:

  • Масштабируемость: Множество Speaker'ов могут анонсировать маршруты одновременно.
  • Отказоустойчивость: При потере узла другие Speaker'ы продолжают анонсировать маршруты.
  • Интеграция с существующей инфраструктурой: Использует стандартный протокол, поддерживаемый всеми корпоративными маршрутизаторами (Cisco, Juniper, MikroTik, Huawei).
  • Контроль и экономия: Полная независимость от облачных провайдеров, снижение затрат на внешние балансировщики нагрузки.

Таким образом, MetalLB в режиме BGP — оптимальный путь для создания production-готовой системы маршрутизации трафика в bare-metal Kubernetes.

Архитектура MetalLB в режиме BGP: как это работает

Чтобы успешно настроить и адаптировать решение, необходимо понимать его внутренние механизмы. MetalLB состоит из двух ключевых компонентов, работающих в namespace metallb-system.

Компоненты MetalLB: Controller и Speaker

Controller работает как Deployment. Его задачи:

  • Мониторинг сервисов Kubernetes типа LoadBalancer.
  • Выбор и назначение IP-адреса из заданного пула (address-pools) соответствующему сервису.
  • Обновление статуса сервиса (External IP).

Controller не взаимодействует с сетью напрямую. Он лишь распределяет IP.

Speaker работает как DaemonSet, запускаясь на каждом узле кластера (или на выбранных узлах). Его ответственность:

  • Установление BGP-сессий с внешними маршрутизаторами (Peers), указанными в конфигурации.
  • Анонсирование маршрутов до IP-адресов, назначенных Controller'ом, на эти маршрутизаторы.
  • Управление сессиями: при потере узла его сессии закрываются, а маршруты перестают анонсироваться.

Важно обеспечить совместимость версий MetalLB с версией вашего кластера Kubernetes. Для кластеров версии 1.25+ рекомендуется использовать MetalLB версии 0.13+.

BGP-сессии и анонсирование IP-пулов

BGP Peer (пир) — это внешний маршрутизатор, с которым компонент Speaker устанавливает сессию для обмена маршрутной информацией. В конфигурации MetalLB вы указываете его IP-адрес (peer-address) и номер Autonomous System (peer-asn).

Процесс установления сессии: Speaker пытается подключиться к маршрутизатору на стандартный BGP порт 179. После успешного установления TCP-соединения и обмена параметрами (AS номеры) сессия считается активной.

Анонсирование маршрута: Когда Controller назначает IP-адрес сервису (например, 192.0.2.100), Speaker, на узле которого запущен этот сервис (или выбранный Speaker), начинает анонсировать маршрут до этого IP-адреса всем своим BGP-пирам. Маршрутизатор получает этот анонс и добавляет его в свою таблицу маршрутизации. Теперь трафик, направленный на 192.0.2.100, будет поступать на тот узёл Kubernetes, который его анонсирует.

MetalLB позволяет управлять предпочтением маршрутов через параметры BGP, такие как local-pref, что полезно для балансировки трафика между несколькими узлами.

Схема потока данных:

  1. Пользователь отправляет запрос на публичный IP-адрес сервиса (например, 192.0.2.100).
  2. Корпоративный маршрутизатор, получивший BGP-анонс от MetalLB, направляет трафик на соответствующий узёл Kubernetes.
  3. На узле трафик попадает на сервис типа LoadBalancer через kube-proxy.
  4. Сервис направляет трафик в целевые Pod'ы приложения.

Предварительные требования и подготовка сети

Перед установкой MetalLB необходимо выполнить ряд обязательных проверок. Попытка настройки в неподготовленной среде гарантированно приведёт к ошибкам.

  • Kubernetes кластер: Версия 1.21 или выше. Кластер должен быть настроен и работоспособен. CNI-плагин (Calico, Cilium, Flannel) должен поддерживать работу kube-proxy. Network Policies не должны блокировать трафик между компонентами MetalLB.
  • Сетевые требования:
    • Выделенный пул IP-адресов для сервисов LoadBalancer. Это может быть публичный диапазон (например, /29) или приватный диапазон из корпоративной сети (например, 10.0.0.0/24). Эти адреса не должны конфликтовать с другими сетями в инфраструктуре.
    • На маршрутизаторах (физических или виртуальных) должен быть настроен и поддерживаться протокол BGP.
    • Между узлами Kubernetes и маршрутизаторами должна быть прямая IP-связность. Часто требуется разместить узлы в той же VLAN или подсети, где находится маршрутизатор.
  • Настройка маршрутизатора: Перед установкой MetalLB необходимо подготовить маршрутизатор:
    • Создать BGP-пира с указанием IP-адреса узла Kubernetes (или диапазона узлов, где будет запущен Speaker).
    • Назначить номер AS для маршрутизатора (peer-asn).
    • Настроить политики для принятия анонсов от MetalLB (обычно требуется разрешить анонсы с указанным AS номером MetalLB).
  • Проверка связности: Убедитесь, что с узлов Kubernetes можно установить TCP-соединение на порт 179 маршрутизатора. Используйте nc -zv <router_ip> 179 или аналогичные команды.
  • Документация производителя: Конкретные шаги настройки BGP зависят от модели маршрутизатора (Cisco IOS, Juniper Junos, MikroTik RouterOS). Используйте официальную документацию вашего оборудования.

Пошаговая установка и конфигурация MetalLB

Ниже приведена полная инструкция для развертывания MetalLB в режиме BGP. Все команды предполагают работу с кластером через kubectl.

Установка через манифесты (kubectl)

Это самый прямой и контролируемый метод установки, рекомендуемый для production.

1. Примените манифесты установки MetalLB:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.10/config/manifests/metallb-native.yaml

Эта команда создаст namespace metallb-system, Deployment для Controller и DaemonSet для Speaker.

2. Проверьте созданные ресурсы:

kubectl get pods -n metallb-system

Вы должны увидеть примерно следующее:

NAME                          READY   STATUS    RESTARTS   AGE
controller-7c8b5b4d8c-9wqhd   1/1     Running   0          2m
speaker-6xkj7                 1/1     Running   0          2m
speaker-bm8fg                 1/1     Running   0          2m

STATUS должен быть Running. Если есть проблемы, проверьте события кластера: kubectl describe pod -n metallb-system <pod_name>.

Детальная настройка ConfigMap

ConfigMap — ключевой файл конфигурации MetalLB. Он определяет пулы IP-адресов и параметры BGP-сессий.

Создайте файл metallb-config.yaml с следующим содержимым:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    peers:
      - peer-address: 10.100.0.1  # IP-адрес вашего маршрутизатора
        peer-asn: 65001           # AS номер маршрутизатора
        my-asn: 65000             # AS номер MetalLB (кластера)
    address-pools:
      - name: default-pool
        protocol: bgp
        addresses:
          - 192.0.2.100-192.0.2.110  # Пул IP-адресов для сервисов
        auto-assign: true

Описание полей:

  • peer-address: IP-адрес маршрутизатора, с которым Speaker установит BGP-сессию.
  • peer-asn: Номер Autonomous System (AS) вашего маршрутизатора. Это уникальный номер в вашей сети.
  • my-asn: Номер AS, который будет использоваться MetalLB. Должен отличаться от peer-asn.
  • address-pools: Список пулов IP-адресов.
    • name: Имя пула для ссылок в конфигурациях.
    • protocol: bgp для использования режима BGP.
    • addresses: Диапазон IP-адресов. Можно указать список (192.0.2.100,192.0.2.101) или диапазон (192.0.2.100-192.0.2.110).
    • auto-assign: true позволяет MetalLB автоматически назначать IP из этого пула.

3. Примените ConfigMap:

kubectl apply -f metallb-config.yaml

После применения MetalLB начнет установку BGP-сессий. Проверить это можно через логи Speaker.

Создание и тестирование сервиса LoadBalancer

Теперь можно проверить работу MetalLB, создав тестовый сервис.

1. Разверните простое тестовое приложение (например, Nginx):

kubectl create deployment nginx-test --image=nginx:alpine
kubectl expose deployment nginx-test --port=80 --type=LoadBalancer --name=nginx-service

2. Наблюдайте за присвоением External IP:

kubectl get svc nginx-service -w

Через несколько секунд в столбце EXTERNAL-IP должен появиться IP-адрес из пула MetalLB (например, 192.0.2.100).

3. Проверка установления BGP-сессии:

kubectl logs -l app=metallb-speaker -n metallb-system | grep -E "session established|announced"

В логах должны быть сообщения типа "BGP session established with 10.100.0.1" и "speaker announced service".

4. Проверка на маршрутизаторе:

На вашем маршрутизаторе (Cisco, MikroTik, etc.) проверьте таблицу BGP или маршрутов. Должен появиться маршрут до назначенного IP-адреса (192.0.2.100) с next-hop, равным IP одного из узлов Kubernetes.

5. Тестирование доступа из внешней сети:

Из сети, которая маршрутизируется через ваш маршрутизатор, попробуйте обратиться к назначенному IP:

curl http://192.0.2.100

Вы должны получить ответ от Nginx (стандартная welcome страница).

Интеграция с Ingress-контроллерами (Nginx, Traefik)

Для организации входящего HTTP/HTTPS трафика в production-среде используется Ingress-контроллер. MetalLB позволяет ему получить стабильный внешний IP.

1. Установка Ingress-контроллера (пример для Nginx Ingress через Helm):

helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

2. После установки сервис контроллера уже будет типа LoadBalancer. Проверьте присвоенный ему IP:

kubectl get svc -n ingress-nginx

MetalLB автоматически назначит IP из своего пула сервису ingress-nginx-controller.

3. Создайте простой Ingress ресурс, указывающий на этот сервис:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service  # наш ранее созданный сервис
            port:
              number: 80

4. Фактический сценарий работы:

  • Пользователь обращается к домену example.yourdomain.com.
  • DNS направляет запрос на внешний IP, назначенный MetalLB для Ingress-контроллера (например, 192.0.2.101).
  • Маршрутизатор, получивший BGP-анонс от MetalLB, направляет трафик на узёл с Ingress-контроллером.
  • Ingress-контроллер, согласно правилам Ingress ресурса, проксирует трафик на внутренний сервис nginx-service.
  • Трафик достигает конечных Pod'ов приложения.

Это создает полноценную, production-готовую систему маршрутизации входящего трафика в bare-metal кластер. Для управления сложными приложениями с множеством сервисов важно понимать их внутреннюю логику. Если ваш Custom Resource в Kubernetes не работает, не тратьте часы на хаотичную отладку. Используйте полный пошаговый гайд по диагностике CR в Kubernetes, который включает базовые команды kubectl, анализ контроллеров и настройку проактивного мониторинга.

Диагностика проблем и обеспечение отказоустойчивости

После настройки важно знать, как проверить работоспособность и устранить возможные проблемы.

Анализ логов и статусов компонентов

Основные команды для диагностики:

  • Статус подов: kubectl get pods -n metallb-system. Все поды должны быть в состоянии Running.
  • Логи Speaker: kubectl logs -l app=metallb-speaker -n metallb-system. Ищите ключевые сообщения: "BGP session established" (успешная сессия), "speaker announced service" (анонс маршрута), ошибки подключения.
  • Логи Controller: kubectl logs -l app=metallb-controller -n metallb-system. Здесь можно увидеть ошибки назначения IP ("no available IPs").
  • Конфигурация: kubectl describe configmap config -n metallb-system — проверьте, что ConfigMap применен корректно.
  • Статус сервиса: kubectl describe svc <service_name>. В событиях (Events) могут быть указания на проблемы с назначением IP.

Распространенные ошибки и их решение

  • "no available IPs" в логах Controller: Пул адресов в ConfigMap пуст, переполнен или указан некорректно. Проверьте секцию address-pools. Убедитесь, что адреса не конфликтуют с другими сетями и не используются другими устройствами.
  • "BGP session not established" в логах Speaker:
    • Проверьте IP-адрес и порт маршрутизатора (peer-address).
    • Убедитесь, что AS номеры (my-asn и peer-asn) корректны и отличаются.
    • Проверьте сетевую связность между узлами Kubernetes и маршрутизатором (порт 179). Возможны проблемы с firewall.
    • На маршрутизаторе проверьте, что BGP-пир настроен корректно и принимает соединения.
  • "IP assigned but no route" (IP назначен, но трафик не идет):
    • Проверьте логи Speaker — убедитесь, что анонс маршрута был отправлен ("speaker announced").
    • На маршрутизаторе проверьте таблицу маршрутизации — маршрут должен быть присутствовать и активен.
    • Возможно, на маршрутизаторе настроены политики фильтрации (route-map), блокирующие анонсы от MetalLB.

Обеспечение отказоустойчивости: DaemonSet Speaker обеспечивает запуск компонента на каждом узле. Если узёл, анонсирующий маршрут для конкретного IP, выходит из строя, другой Speaker на другом узле может взять на себя анонсирование этого маршрута (в зависимости от конфигурации BGP и параметров local-pref). Это обеспечивает высокую доступность сервисов.

Для комплексного мониторинга состояния кластера и сервисов, включая BGP-сессии, рекомендуется интегрировать MetalLB с системами мониторинга, например, Prometheus. Эксплуатация production-сред требует глубокого понимания всех компонентов. Если вы рассматриваете альтернативы Kubernetes, для системных администраторов может быть оптимальным решение на основе Docker Swarm. Практическое руководство по Docker Swarm 2026 детально описывает создание отказоустойчивого кластера, масштабирование сервисов и выполнение бесшовных обновлений.

Настройка MetalLB с BGP завершает построение полноценной системы внешней маршрутизации для bare-metal Kubernetes. Вы получаете автоматическое назначение публичных IP, интеграцию с корпоративной сетевой инфраструктурой и отказоустойчивость, сопоставимую с облачными решениями, но с полным контролем и сниженной стоимостью.

Поделиться:
Сохранить гайд? В закладки браузера