Доступно в редакциях:  CE, BE, SE, SE+, EE

Стадия жизненного цикла модуля: Preview
У модуля есть требования для установки

Модуль alb реализует прикладной балансировщик нагрузки (Application Load Balancer, ALB) и позволяет публиковать приложения с помощью Kubernetes Gateway API. Он разворачивает и настраивает инфраструктуру для приёма и маршрутизации внешних запросов, а также проверяет пользовательскую конфигурацию Gateway API.

Модуль поддерживает:

Модуль может использоваться в кластере совместно с модулем ingress-nginx. Подробнее — в разделе «Руководство администратора».

Автоматическое создание и гибкая настройка инфраструктуры для объектов Gateway

В модуле представлены два пользовательских ресурса (CRD) для декларативного описания и управления инфраструктурой объектов Gateway: ClusterALBInstance и ALBInstance. Особенности этих ресурсов и разница между ними описаны в таблице ниже.

ClusterALBInstance ALBInstance
Назначение Развёртывание cluster-scoped-объекта Gateway Развёртывание namespaced-объекта Gateway
Типичный сценарий Общая точка входа, системный (для публикации служебных компонентов DKP) или платформенный шлюз Отдельный шлюз для приложения или команды в выделенном неймспейсе
Поддерживаемые типы инлета LoadBalancer, HostPort LoadBalancer
Реализация прокси Envoy Proxy Envoy Proxy
Тип развёртывания DaemonSet Deployment
Локализация объектов ListenerSet и маршрутов В любом пользовательском неймспейсе В том же неймспейсе, что и объект ALBInstance
Права доступа Администратор кластера Администратор неймспейса

Результатом создания объекта ClusterALBInstance или ALBInstance в кластере становится появление управляемого объекта Gateway. При этом:

  • Каждый объект Gateway обслуживается как минимум одним экземпляром Envoy Proxy.
  • Трафик в него приходит через объект Service типа LoadBalancer или напрямую с использованием параметров HostPort.
  • Каждый объект Gateway по умолчанию создает два обработчика: d8-http (порт 80) и d8-https (порт 443). Они предназначены для служебных целей — например, проверки доступности шлюза или работы cert-manager (HTTP-01). Для публикации приложений эти обработчики использовать не рекомендуется, используйте для этого ListenerSet.

Ручная модификация объектов Gateway, управляемых модулем, не допускается.

Несколько объектов ClusterALBInstance или ALBInstance могут ссылаться на один и тот же объект Gateway через поле gatewayName. В этом случае они описывают общий шлюз, но инфраструктура приёма запросов может отличаться в зависимости от настроек. Можно рассматривать gatewayName как аналог ingressClass для объектов IngressNginxController.

Управление приёмом входящих запросов с помощью объектов ListenerSet

Объект ListenerSet описывает системные и пользовательские обработчики трафика, которые задают имя хоста, режим TLS, порт и протокол. Каждый объект ListenerSet связывается с конкретным родительским объектом Gateway через поле spec.parentRef, а затем к нему подключаются маршруты.

Расположение объектов ListenerSet зависит от используемого типа объекта Gateway:

  • для ClusterALBInstance объекты ListenerSet могут располагаться в любом неймспейсе;
  • для ALBInstance объекты ListenerSet рекомендуется располагать в том же неймспейсе, что и родительский ALBInstance.

В обоих случаях объект ListenerSet рекомендуется располагать в том же неймспейсе, что и подключаемые к нему объекты HTTPRoute, GRPCRoute, TCPRoute и TLSRoute. Это упрощает читаемость конфигурации и позволяет избежать дополнительных настроек, например объектов ReferenceGrant.

Маршрутизация входящих запросов с помощью объектов HTTPRoute, GRPCRoute, TCPRoute и TLSRoute

Модуль поддерживает следующие типы маршрутов:

  • HTTPRoute — для маршрутизации HTTP/HTTPS/TLS запросов;
  • GRPCRoute — для маршрутизации gRPC-трафика;
  • TLSRoute — для сквозной маршрутизации TLS-трафика;
  • TCPRoute — для маршрутизации TCP-трафика.

Объекты HTTPRoute поддерживают расширенные настройки с помощью аннотаций, которые дополняют текущую спецификацию Gateway API.

Валидация конфигурации Gateway API

Помимо настройки инфраструктуры Gateway API, модуль выполняет валидацию пользовательских настроек, чтобы не допустить применения конфликтующих конфигураций. Например, модуль проверяет конфликты между одинаковыми обработчиками трафика в разных объектах ListenerSet, если они ссылаются на один и тот же объект Gateway.