В этом разделе описываются подходы к балансировке входящего трафика в Deckhouse Kubernetes Platform (DKP):
- NLB (Network Load Balancer) — работает на сетевом уровне, маршрутизирует трафик по IP-адресам и портам без анализа содержимого запросов.
- ALB (Application Load Balancer) — действует на прикладном уровне, анализирует HTTP(S)-заголовки, пути и домены. Поддерживает SSL-терминацию и маршрутизацию в зависимости от содержимого запроса.
Балансировка на сетевом уровне (NLB)
Балансировка NLB может быть организована двумя способами:
- с помощью внешнего балансировщика от облачного провайдера;
- средствами внутреннего балансировщика
metallb, работающего как в облачных, так и в bare-metal-кластерах.
Балансировка на прикладном уровне (ALB)
Для балансировки трафика на уровне приложений в DKP доступны следующие решения:
- Ingress NGINX Controller (модуль
ingress-nginx); - Kubernetes Gateway API (модуль
alb); - Istio (модуль
istio).
Отличие Kubernetes Gateway API от API Gateway
Kubernetes Gateway API и API Gateway выполняют разные функции:
- Kubernetes Gateway API — спецификация Kubernetes, определяющая набор ресурсов для настройки маршрутизации входящего трафика к приложениям.
- API Gateway — архитектурный компонент или программный продукт, предоставляющий единую точку входа к API приложений и централизованно реализующий такие функции, как аутентификация, авторизация и ограничение частоты запросов.
Иными словами, Kubernetes Gateway API описывает, как настроить маршрутизацию трафика, а API Gateway — это разновидность инфраструктуры, которая этот трафик обрабатывает. Некоторые API Gateway можно настраивать через Kubernetes Gateway API. Модуль alb является реализацией Kubernetes Gateway API.
Разделение ролей в модели Gateway API
При использовании модуля alb ответственность за настройку и публикацию приложений разделяется между следующими ролями:
- администратор кластера — разворачивает кластерную инфраструктуру шлюза через ClusterALBInstance;
- администратор неймспейса — разворачивает локальную инфраструктуру шлюза через ALBInstance и настраивает приём трафика через ListenerSet (hostname, TLS, порты);
- разработчики приложения — настраивают маршрутизацию к приложениям с помощью HTTPRoute и других ресурсов маршрутизации.
В типовом сценарии с общекластерным шлюзом ListenerSet создаёт администратор неймспейса, а HTTPRoute — разработчики приложения. Один и тот же человек может выполнять обе роли, если у него есть соответствующие права.
Как выбрать реализацию ALB
В таблице ниже приведены критерии выбора реализации ALB.
| Критерий | Ingress NGINX | Gateway API | Istio |
|---|---|---|---|
| API публикации | Ingress + аннотации | Gateway, ListenerSet, маршруты | Gateway, VirtualService, DestinationRule |
| Протоколы | HTTP/HTTPS, gRPC (Ingress) | HTTP/HTTPS, gRPC, TLS, TCP, UDP | HTTP/HTTPS, gRPC, TCP (Istio Gateway) |
| Разделение ролей | IngressClass + Ingress | ClusterALBInstance/ALBInstance → ListenerSet → маршруты | IngressIstioController + Istio Gateway |
| Service mesh | Нет | Опционально (sidecar на прокси шлюза) | Да |
| Типичный сценарий | Классический Ingress, минимальные изменения | Новые приложения, мультитенантность, постепенная миграция с Ingress | Canary, mTLS, трассировка, продвинутая маршрутизация |
Сравнение возможностей модулей ingress-nginx и alb
Оба модуля решают одну задачу — приём и маршрутизацию внешнего трафика к приложениям, но опираются на разные стандарты: ingress-nginx использует Ingress API с аннотациями, а alb — Kubernetes Gateway API. Модули можно использовать в кластере одновременно. В таблице ниже сравниваются их возможности в текущих версиях.
Служебные домены (веб-интерфейсы компонентов DKP и модулей по publicDomainTemplate) и домены приложений (маршруты разработчиков приложения) настраиваются по-разному. Подробности — в разделе «Публикация служебных доменов».
| Параметр | ingress-nginx |
alb |
|---|---|---|
| Стандарт маршрутизации | Ingress API с аннотациями | Kubernetes Gateway API |
| Реализация прокси | nginx | Envoy Proxy |
| Стадия жизненного цикла | General Availability | Preview |
| Развитие | Режим сопровождения: upstream-проект Ingress NGINX не развивает новые возможности, обновления безопасности поставляет DKP | Активно развивается |
| Минимальная версия DKP | Доступен во всех поддерживаемых версиях | 1.76 |
| Редакции DKP | Все редакции | Все редакции |
| Модель разграничения ролей | Администратор кластера, администратор неймспейса | Администратор кластера, администратор неймспейса, разработчики приложения |
| Несколько независимых точек входа | Несколько Ingress-контроллеров, выбор через ingressClass |
Несколько объектов Gateway, выбор через gatewayName; общекластерные шлюзы и шлюзы в неймспейсе |
| HTTP/HTTPS (HTTP/1.1, HTTP/2, HTTP/3) | Есть | Есть (включение HTTP/3) |
| WebSocket | Есть | Есть |
| gRPC | Есть | Есть |
| FastCGI | Есть | Нет |
| TCP | Нет | Есть (TCPRoute) |
| UDP | Нет | Есть (UDPRoute) |
| TLS passthrough | Есть | Есть (TLSRoute) |
| Proxy Protocol | Есть | Есть |
| Способы приёма трафика | Инлеты LoadBalancer, HostPort и HostWithFailover |
Инлеты LoadBalancer и HostPort |
Автоматический выпуск TLS-сертификатов (cert-manager) |
Есть | Есть |
| Настройка политик HTTPS (версии TLS, шифры, HSTS) | Есть | По умолчанию TLSv1.2/1.3; HSTS — через аннотацию заголовков ответа |
| WAF | ModSecurity на уровне контроллера или Ingress-ресурса | ModSecurity/Coraza на уровне маршрута, набор правил OWASP CRS |
| Внешняя аутентификация | Есть | Есть |
| Ограничение доступа по IP (whitelist) | Есть | Есть |
| Базовая аутентификация | Есть | Есть |
| Ограничение частоты запросов | Есть | Есть |
| Закрепление сессии (session affinity) | Есть | Есть |
| GeoIP | Гео-статистика запросов в метриках | Добавление полей GeoIP в заголовки на основе баз MaxMind |
| Метрики Prometheus и дашборды Grafana | Есть, с детализацией по неймспейсам, виртуальным хостам, Ingress-ресурсам и локациям | Есть: метрики Envoy Proxy и дашборды по запросам, маршрутам и upstream |
| Трассировка OpenTelemetry | Есть | Есть (настройка) |
Следующие шаги
Чтобы опубликовать приложение, выполните следующие шаги:
- Выберите реализацию ALB по критериям из таблицы выше: Ingress NGINX, Gateway API или Istio.
- Istio — если нужно управление трафиком в service mesh (canary-маршрутизация, mTLS между подами).
- Gateway API — если нужна модель с разделением ролей и протоколами шире классического Ingress.
- Ingress NGINX — если нужен зрелый ALB на Ingress API.
- Включите и настройте соответствующий модуль. Для Gateway API выполните «Действия перед включением и настройкой ALB в кластере».
- Опубликуйте приложения по руководствам пользователя по ALB (Gateway API, Ingress NGINX или Istio).
- Для перехода с Ingress NGINX на Gateway API следуйте разделу «Миграция с ingress-nginx на alb».