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

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

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

Текущая используемая версия Envoy Proxy - 1.37.3.

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

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

Балансировка трафика по нескольким протоколам

Модуль позволяет использовать следующие протоколы для приема и дальнейшей маршрутизации трафика:

  • HTTP/HTTPS: основные протоколы маршрутизации трафика. По умолчанию поддерживаются HTTP/1.1 и HTTP/2. HTTP/3 можно включить с помощью параметров ALBInstance и ClusterALBInstance.
  • WebSocket: поддерживается Envoy Proxy нативно, без дополнительной настройки со стороны пользователя.
  • gRPC: поддерживается маршрутизация gRPC-маршрутов с помощью GRPCRoute.
  • Proxy Protocol: поддерживается организация приёма Proxy Protocol-трафика за счёт использования соответствующих параметров ALBInstance и ClusterALBInstance.
  • SSL Passthrough: поддерживается сквозная маршрутизация SSL-трафика с помощью TLSRoute.
  • TCP: поддерживается маршрутизация TCP-трафика с помощью TCPRoute.

Поддержка SSL/TLS

По умолчанию в Envoy Proxy поддерживается TLSv1.2 и TLSv1.3. В случае использования TLSv1.2 применяются следующие параметры криптографии:

  • обмен ключами: ECDHE;
  • аутентификация: ECDSA, RSA;
  • шифрование (AEAD): AES-GCM (128/256), ChaCha20-Poly1305;
  • контроль целостности: SHA256, SHA384.

При использовании TLSv1.3 набор протоколов криптографии определяется библиотекой BoringSSL.

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

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

ClusterALBInstance ALBInstance
Назначение Развёртывание cluster-scoped-объекта Gateway Развёртывание объекта 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.