HTTP-роутеры
HTTP-роутер определяет правила маршрутизации HTTP-запросов в группы бэкендов.
Указывать HTTP-роутеры можно только для обработчиков типа HTTP. Если обработчик принимает чистый
TCP-трафик (тип Stream), то для него напрямую указывается группа бэкендов.
Если HTTP-роутер используется хотя бы в одном балансировщике, удалить его нельзя. Сначала удалите его из всех балансировщиков.
С помощью настроек HTTP-роутера можно модифицировать заголовки запросов и ответов, а также формировать небольшие статические ответы прямо на балансировщике нагрузки. Можно создать пустой HTTP-роутер, а потом добавить в него маршруты.
Маршруты внутри HTTP-роутера объединены в виртуальные хосты. Маршрутизация происходит в два этапа.
-
На основе заголовка
Host
(:authority
в случае HTTP/2) выбирается наиболее подходящий виртуальный хост. -
Выбирается первый маршрут, предикату которого удовлетворяет запрос. Порядок виртуальных хостов внутри роутера не важен, а порядок маршрутов внутри виртуального хоста важен — наиболее специфичные маршруты должны быть первыми в списке.
Виртуальные хосты
Виртуальные хосты объединяют маршруты, относящиеся к одному набору доменов — значений заголовков Host
(:authority
) HTTP-запроса. Поддерживаются как точные совпадения, так и символы подстановки. При получении входящего запроса балансировщик по очереди проверяет предикаты маршрутов и выбирает первый, удовлетворяющий запросу.
Балансировщик направляет трафик на бэкенд, который указывает на различные ресурсы. Эти ресурсы могут быть подвержены внешним угрозам. Вы можете защитить ресурсы с помощью сервиса Yandex Smart Web Security, подключив профиль безопасности к виртуальному хосту.
Если балансировщик управляется Ingress-контроллером Application Load Balancer, то подключать профиль безопасности следует с помощью аннотации ресурса Ingress.
Также на уровне виртуального хоста настраиваются модификации HTTP-заголовков запросов и ответов.
Маршруты
Маршруты состоят из набора условий (предиката), на основании которых балансировщик выбирает маршрут для запроса, и действия над запросом. Доступные условия и действия зависят от типа маршрута.
Типы маршрутов
HTTP-роутеры поддерживают два типа маршрутов — HTTP и gRPC:
-
HTTP-маршруты предназначены для обработки HTTP-запросов по протоколам HTTP/1.1 и HTTP/2.
В качестве условия для маршрута можно указать начало, полный путь запроса или регулярное выражение
стандарта RE2 , а также метод запроса (GET, POST и т. д.).С запросом, который удовлетворяет условиям, можно выполнить одно из действий:
-
Передача запроса в группу бэкендов типа HTTP для обработки. В этом случае вы можете изменить заголовок
Host
на указанное значение или настроить автоматическую замену на адрес целевой ВМ.Помимо заголовка
Host
, вы можете настроить тайм-ауты на обработку запроса, добавить поддержку WebSocket, указать протоколы, на которые группа бэкендов может перейти в рамках TCP-соединения по запросу клиента, изменить URI перед передачей запроса в бэкенды. -
Перенаправление запроса на другой адрес с выбранным кодом ответа и модификациями URI запроса. В этом случае можно заменить путь (полностью или частично), удалить query-параметры, изменить хост, порт и схему.
Если в качестве условия для маршрута указан полный путь запроса, то заменить только начало пути не получится. Заменится весь путь, даже если в настройках указано изменить только начало.
Если в оригинальном URI использована схема
http
(https
) и указан порт80
(443
), при изменении схемы порт будет удален. -
Немедленный возврат статического ответа балансировщика на запрос, поступивший по этому маршруту.
-
-
gRPC-маршруты предназначены для обработки gRPC-запросов (удалённых вызовов процедур
) по протоколу HTTP/2.В качестве условия для gRPC-маршрута можно указать начало, полное имя метода (FQMN, fully qualified method name) или регулярное выражение
стандарта RE2 . Значение должно начинаться с косой черты/
.С запросом, который удовлетворяет условиям, можно выполнить одно из действий:
-
Передача запроса в группу бэкендов типа gRPC для обработки. В этом случае вы можете настроить тайм-ауты на обработку запроса и заменить заголовок
Host
на указанное значение или настроить автоматическую замену на адрес целевой ВМ. -
Немедленный возврат статического ответа.
-
Тайм-ауты
Запрос, который удовлетворяет условиям маршрута, можно передать в группу бэкендов для обработки. В этом случае есть возможность настроить тайм-ауты:
-
Таймаут, с — максимальное время поддержания HTTP-соединения между узлом балансировщика и бэкендом. Доступно только для групп бэкендов типа HTTP. Значение по умолчанию —
60
. -
Максимальный таймаут, с — максимальный период, на который может быть установлено соединение между узлом балансировщика и бэкендом. Доступно только для групп бэкендов типа gRPC. Клиент может указать в запросе HTTP-заголовок
grpc-timeout
с меньшим тайм-аутом. Значение по умолчанию —60
. -
Таймаут простоя, с — максимальное время, в течение которого соединение может поддерживаться без передачи данных. Значения по умолчанию нет. Если тайм-аут не указан, он не учитывается. Тайм-аут простоя можно использовать в сценариях потоковой передачи (например, для длительных опросов, событий, отправляемых сервером). В некоторых случаях, когда основной тайм-аут не указан, тайм-аут простоя может проставиться автоматически.
Если соединение для групп бэкендов типа HTTP завершится по тайм-ауту, балансировщик вернет код 504 Gateway Timeout
.
Примеры использования
- Организация виртуального хостинга
- Терминирование TLS-соединений с помощью консоли управления
- Создание L7-балансировщика с защитой от DDoS с помощью консоли управления или CLI
- Миграция сервисов с балансировщика NLB на L7-балансировщик ALB для защиты от DDoS-атак с помощью Yandex Smart Web Security
- Интеграция L7-балансировщика с Cloud CDN и Object Storage
- Организация сине-зеленого и канареечного развертывания версий веб-сервиса
- Запись логов балансировщика в PostgreSQL
- Создание L7-балансировщика Application Load Balancer с профилем безопасности Yandex Smart Web Security