Свежий прикладной балансировщик с поддержкой Gateway программный оболочку в Deckhouse Kubernetes Platform

Мы добавили в Deckhouse Kubernetes Platform балансировщик нагрузки нового поколения с поддержкой Gateway программный интерфейс на основе Envoy — современного стандарта для управления входящим трафиком в Kubernetes-кластерах. Он внедрён в модуле alb, который разворачивает и настраивает инфраструктуру для приёма и маршрутизации внешних запросов, а равным образом валидирует пользовательскую конфигурацию Gateway программный интерфейс. 

Для работы модуля понадобится DKP версии 1.76 и выше. Прикладной балансировщик доступен как в коммерческих редакциях платформы, так и в опенсорсной Community Edition, хотя возможности самого модуля в них немного отличаются. В новости рассказываем, зачем нужен ещё один балансировщик нагрузки в DKP, что даёт переход на Gateway программный интерфейс и что именно входит в CE.

ingress-nginx и alb: зачем DKP два модуля для одной задачи и как мигрировать на новый

В DKP уже давно есть модуль ingress-nginx. Как и новый компонент alb, он решает задачу приёма и маршрутизации внешнего трафика к приложениям. Но ingress-nginx построен на основе Ingress NGINX Controller, ставшего де-факто стандартом для управления Ingress-ресурсами. И это тот самый контроллер, для которого Kubernetes SIG Network осенью 2025 года анонсировала прекращение поддержки. До марта 2026 года авторы поддерживали проект в режиме best-effort, а затем полностью остановили версия релизов и обновлений безопасности.

Для пользователей Deckhouse Kubernetes Platform это не значит, что компонент ingress-nginx резко перестанет функционировать: мы будем развивать его и самостоятельно исправлять CVE. Но нам важно следовать Kubernetes-way, а дальнейшее развитие средств балансировки входящего трафика Kubernetes ориентирует на Gateway программный оболочку, преемника Ingress api.

Компонент alb — это наша реализация Gateway api в DKP. При этом расставаться с ingress-nginx прямо сейчас вам не нужно, потому что «старый» и «свежий» модули балансировки нагрузки можно применять в кластере одновременно. А в будущем мы планируем добавить поддержку ресурсов Ingress прямо в alb.

Значимый нюанс: компонент alb сейчас находится на стадии Preview. Это значит, что часть функциональности ещё может измениться, и при переходе на будущие версии может потребоваться ручная миграция.

Мы подготовили подробное руководство по миграции с модуля ingress-nginx на alb. В нём описан поэтапный план. Сначала настраиваете alb параллельно с уже работающим ingress-nginx и переносите часть существующих Ingress-правил маршрутизации с помощью встроенного инструмента конвертации — он готовит черновые ресурсы, которые нужно проверить перед применением. Затем тестируете посещаемость через alb на выбранных клиентах без смены DNS. И только после этого плавно переключаете прод, сохраняя функция откатиться, если что-то пойдёт не так.

Что даёт переход на Kubernetes Gateway api

Gateway программный интерфейс в модуле alb — это не просто иной метод маршрутизации. Он даёт единый декларативный api для HTTP/HTTPS, gRPC, TCP, UDP и TLS passthrough, включая сценарии, которые не покрываются Ingress api. Помимо этого, реализация современного стандарта даёт возможность разделять ответственность между тремя ролями:

1. Администратор кластера управляет инфраструктурой Gateway через ресурсы ClusterALBInstance и ALBInstance.

2. Администратор неймспейса осуществляет тонкую настройку точки входа  трафика, в том числе настраивает TLS-сертификаты через ListenerSet;

3. Команда приложения описывает маршрутизацию через HTTPRoute и другие Route-ресурсы.

Такое разделение упрощает мультитенантность: командам не нужно давать доступ к общей инфраструктуре, чтобы они могли публиковать свои приложения.

Опираясь на Gateway api, модуль alb даёт «из коробки» и расширенные возможности обработки запросов: WAF на уровне маршрута, внешнюю аутентификацию, ограничение доступа по IP, ограничение частоты запросов, session affinity, обогащение запросов GeoIP-заголовками на основе баз MaxMind. Равным образом поддерживаются BackendTLSPolicy, Proxy Protocol и HTTP/3. А ещё через Gateway программный интерфейс можно открыть доступ не только к пользовательским приложениям, но и к большей части системных компонентов DKP.

Общий шлюз для всего кластера или свой для каждой команды: где грань между редакциями DKP

Компонент alb вводит два пользовательских ресурса (CRD), которые описывают инфраструктуру для Gateway, — ClusterALBInstance и ALBInstance. Проксирование в обоих случаях выполняет Envoy Proxy, сейчас используется релиз v1.38.3.

• ClusterALBInstance — совокупный шлюз на весь кластер, которым управляет администратор кластера. 

• ALBInstance — отдельный шлюз в конкретном неймспейсе, который администратор неймспейса может выделить приложению или команде.

Здесь и кроется начальный значимый нюанс с редакциями: разработка ресурсов ALBInstance поддерживается только в коммерческих редакциях Deckhouse Kubernetes Platform. В Community Edition доступен только ClusterALBInstance.

Второе ограничение Community Edition — в  WAF. В бесплатной редакции включить его нельзя. Ограничение доступа по IP, ограничение частоты запросов, basic-аутентификация и GeoIP работают во всех редакциях DKP.

Готовые метрики в формате Prometheus и дашборды в Grafana

Модуль собирает метрики Envoy Proxy и отдаёт их в Prometheus, если в кластере включён модуль prometheus. К ним сразу готовы три дашборда Grafana — с общей статистикой по трафику, детализацией по конкретному маршруту и по upstream-серверам приложений.

Как попробовать компонент alb

Включить модуль можно через веб-интерфейс DKP в разделе «Модули», CLI d8 командой d8 system module enable alb или применив манифест ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata: name: alb
spec: enabled: true

Подробное описание ресурсов, настройку WAF, GeoIP, HTTP/3 и других возможностей смотрите в документации. Если вы используете компонент ingress-nginx и планируете переезд на alb, начните с руководства по миграции.