Модуль alb

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

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

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

• балансировку трафика по нескольким протоколам;
• автоматическое создание и гибкую настройку инфраструктуры для объектов Gateway (служебный ресурс для настройки точки входа трафика в кластер);
• управление приёмом входящих запросов с помощью объектов ListenerSet (пользовательский ресурс);
• маршрутизацию входящих запросов с помощью объектов HTTPRoute, GRPCRoute, TCPRoute, UDPRoute и TLSRoute (пользовательские ресурсы);
• валидацию конфигурации Gateway API.

Преимущества подхода на основе Gateway API

Модуль построен на Kubernetes Gateway API — современном стандарте управления входящим трафиком, который приходит на смену Ingress API. Опираясь на этот стандарт, модуль предоставляет:

• единый декларативный API сразу для нескольких протоколов (HTTP/HTTPS, gRPC, TCP, UDP и TLS passthrough), включая сценарии, которые не покрываются Ingress API;
• разделение ответственности между администратором кластера (инфраструктура через ClusterALBInstance и ALBInstance), администратором неймспейса (приём трафика через ListenerSet) и командой приложения (маршрутизация через HTTPRoute и другие объекты-маршруты), что упрощает мультитенантность;
• расширенные возможности обработки запросов из коробки: WAF (ModSecurity/Coraza) на уровне маршрута, внешнюю аутентификацию, списки разрешённых IP-адресов, ограничение частоты запросов, session affinity, GeoIP, BackendTLSPolicy, Proxy Protocol и HTTP/3.

Модуль может работать в кластере одновременно с модулем ingress-nginx, поэтому переходить на Gateway API можно постепенно: новые приложения публиковать через модуль, а существующие — оставлять в текущей схеме.

Отличие Kubernetes Gateway API от API Gateway

Несмотря на схожие названия, это разные понятия:

• Kubernetes Gateway API — это набор ресурсов Kubernetes (спецификация), описывающих маршрутизацию входящего трафика к сервисам. Это интерфейс конфигурации, который реализуют контроллеры, и преемник Ingress API.
• API Gateway — это архитектурный компонент (или продукт), который объединяет несколько API приложений за единой точкой входа и централизует сквозные функции: аутентификацию, авторизацию и ограничение частоты запросов для потребителей API.

Иными словами, Kubernetes Gateway API описывает, как настроить маршрутизацию трафика, а API Gateway — это разновидность инфраструктуры, которая этот трафик обрабатывает. Некоторые API Gateway можно настраивать через Kubernetes Gateway API. Модуль alb является реализацией Kubernetes Gateway API.

Сравнение возможностей модулей ingress-nginx и alb

Оба модуля решают одну задачу — приём и маршрутизацию внешнего трафика к приложениям, но опираются на разные стандарты: ingress-nginx использует Ingress API с аннотациями, а alb — Kubernetes Gateway API. Модули можно использовать в кластере одновременно (подробнее — в разделе «Руководство администратора»). В таблице ниже сравниваются их возможности в текущих версиях.

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

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

• 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.
• UDP: поддерживается маршрутизация UDP-трафика через UDP listener управляемого Gateway с помощью UDPRoute.

Поддержка 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.

Мониторинг и статистика

Модуль alb собирает метрики Envoy Proxy и предоставляет их Prometheus в формате Prometheus. Если включён модуль operator-prometheus, объект PodMonitor d8-alb-proxy собирает метрики с endpoint /stats/prometheus каждого готового пода ALB-прокси. Имена собранных метрик получают префикс d8_alb_gateway_.

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

• namespace;
• gateway;
• clusteralbinstance;
• hostname;
• route;
• response_code;
• method для счётчика HTTP-запросов по методу;
• country для GeoIP-метрик;
• city для GeoIP-метрик по городам;
• cluster_name для upstream-кластеров;
• node и tier для метаданных цели прокси.

Графики собраны в дашбордах Grafana, расположенных в monitoring/grafana-dashboards/alb:

• requests.json (Requests) содержит общую статистику HTTP-запросов, HTTP-методы, HTTP-, TCP- и UDP-трафик, карту стран и Top cities для GeoIP-запросов, ошибки, upstream, TLS и listener’ы;
• route-details.json (Route Details) содержит детализацию выбранного маршрута: количество запросов, RPS, HTTP-трафик, задержку P50/P95/P99, коды ответов и сигналы ошибок;
• upstream-details.json (Upstream Details) содержит детализацию выбранного upstream-кластера: количество запросов, задержку, повторы, таймауты, ошибки соединения, ожидающие запросы и доступные endpoints.

Основные принципы сбора статистики

1. Envoy Proxy формирует стандартные метрики и пользовательскую HTTP-статистику. Пользовательская статистика запросов содержит маршрут, запрошенное имя хоста и код ответа в виде меток метрик.
2. Envoy Proxy предоставляет метрики по адресу /stats/prometheus. Прокси ALB через kube-rbac-proxy публикует этот endpoint на порту https-metrics и авторизует доступ к соответствующему workload прокси. Метрики Gateway-контроллера также публикуются через его kube-rbac-proxy.
3. Если включён operator-prometheus, объекты PodMonitor d8-alb-proxy и d8-alb-gateway-controller собирают метрики ALB-прокси и Gateway-контроллера; к именам метрик добавляется префикс d8_alb_gateway_.
4. Дашборды Grafana выполняют запросы к полученным метрикам Prometheus и позволяют фильтровать данные по namespace, Gateway, ALB instance, hostname, route, коду ответа или upstream-кластеру.

Какая информация собирается Prometheus и в каком виде

• HTTP: d8_alb_gateway_envoy_http_custom_downstream_rq_by_path считает запросы с метками route, hostname и response_code; d8_alb_gateway_envoy_http_custom_downstream_rq_by_method считает запросы с метками method, route и hostname; d8_alb_gateway_envoy_http_custom_downstream_rq_{rx,tx}_bytes_total считает принятый и переданный HTTP-трафик; d8_alb_gateway_envoy_http_custom_downstream_rq_duration_by_path_{sum,count,bucket} хранит гистограмму длительности запросов; метрики no-route, no-cluster, таймаутов и сбросов downstream показывают сигналы ошибок;
• GeoIP: d8_alb_gateway_envoy_http_custom_geoip_requests считает HTTP-запросы по метке country; d8_alb_gateway_envoy_http_custom_geoip_requests_by_city — по меткам country и city. Первая метрика создаётся, если настроены GeoIP City DB и geoIP.headers.country; вторая — если также настроен geoIP.headers.city.
• Статус GeoIP: d8_alb_gateway_geoip_configured равна 1, когда для ALBInstance настроен источник баз GeoIP (GeoProxy или прямое зеркало), и 0 в остальных случаях. Она отображается в панели GeoIP status дашборда Requests; это статус конфигурации, а не готовности или актуальности скачанной базы.
• Upstream: d8_alb_gateway_envoy_cluster_upstream_rq_time_{sum,count,bucket} хранит гистограмму задержки upstream; также собираются общее количество запросов, повторы, переполнения повторов, таймауты, ошибки соединения, активные и ожидающие запросы, сбросы и количество доступных endpoints;
• Listener и TLS: d8_alb_gateway_envoy_listener_downstream_cx_active и d8_alb_gateway_envoy_listener_ssl_certificate_* показывают активные downstream-соединения и статистику TLS-сертификатов;
• TCP: d8_alb_gateway_envoy_tcp_custom_downstream_cx_total и d8_alb_gateway_envoy_tcp_downstream_cx_{rx,tx}_bytes_total показывают количество соединений и объём трафика;
• UDP: d8_alb_gateway_envoy_cluster_udp_sess_{rx,tx}_datagrams показывают полученные и переданные датаграммы UDP-сессий.

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

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

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

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

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

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

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

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

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

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

Объекты TCPRoute и UDPRoute для обычных TCP/UDP-портов, заданных в additionalPorts, подключаются непосредственно к соответствующему listener управляемого Gateway, а не к ListenerSet. Это дает сетевым администраторам более точный контроль над тем, какие дополнительные порты доступны в кластере. Подробнее — в разделе «Открытие дополнительного TCP/UDP-порта» руководства администратора.

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

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

• HTTPRoute — для маршрутизации HTTP/HTTPS/TLS запросов;
• GRPCRoute — для маршрутизации gRPC-трафика;
• TLSRoute — для сквозной маршрутизации TLS-трафика;
• TCPRoute — для маршрутизации TCP-трафика (обычный TCP через listener Gateway из additionalPorts либо после терминации TLS на ListenerSet);
• UDPRoute — для маршрутизации UDP-трафика через listener Gateway из additionalPorts.

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

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

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