Мы добавили в Deckhouse Kubernetes Platform балансировщик нагрузки нового поколения с поддержкой Gateway API на основе Envoy — современного стандарта для управления входящим трафиком в Kubernetes-кластерах. Он реализован в модуле alb, который разворачивает и настраивает инфраструктуру для приёма и маршрутизации внешних запросов, а также валидирует пользовательскую конфигурацию Gateway API.
Для работы модуля понадобится DKP версии 1.76 и выше. Прикладной балансировщик доступен как в коммерческих редакциях платформы, так и в опенсорсной Community Edition, хотя возможности самого модуля в них немного отличаются. В новости рассказываем, зачем нужен ещё один балансировщик нагрузки в DKP, что даёт переход на Gateway API и что именно входит в 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 API, преемника 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 API в модуле alb — это не просто другой способ маршрутизации. Он даёт единый декларативный API для HTTP/HTTPS, gRPC, TCP, UDP и TLS passthrough, включая сценарии, которые не покрываются Ingress API. Кроме того, реализация современного стандарта позволяет разделять ответственность между тремя ролями:
-
Администратор кластера управляет инфраструктурой Gateway через ресурсы ClusterALBInstance и ALBInstance.
-
Администратор неймспейса осуществляет тонкую настройку точки входа трафика, в том числе настраивает TLS-сертификаты через ListenerSet;
-
Команда приложения описывает маршрутизацию через HTTPRoute и другие Route-ресурсы.
Такое разделение упрощает мультитенантность: командам не нужно давать доступ к общей инфраструктуре, чтобы они могли публиковать свои приложения.
Платформенная команда отвечает за настройку шлюза, команда приложения получает доступ к управлению маршрутами и публикует сервисы самостоятельно
Опираясь на Gateway API, модуль alb даёт «из коробки» и расширенные возможности обработки запросов: WAF на уровне маршрута, внешнюю аутентификацию, ограничение доступа по IP, ограничение частоты запросов, session affinity, обогащение запросов GeoIP-заголовками на основе баз MaxMind. Также поддерживаются BackendTLSPolicy, Proxy Protocol и HTTP/3. А ещё через Gateway API можно открыть доступ не только к пользовательским приложениям, но и к большей части системных компонентов 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/v1alpha1kind: ModuleConfigmetadata: name: albspec: enabled: true
Подробное описание ресурсов, настройку WAF, GeoIP, HTTP/3 и других возможностей смотрите в документации. Если вы используете модуль ingress-nginx и планируете переезд на alb, начните с руководства по миграции.
Источник: habr.com