Envoy изнутри: как запрос находит маршрут, кластер и конкретный сервер
Маршрутизация, обнаружение адресов, проверка здоровья и доставка конфигурации работают на разных уровнях. Разбираем путь запроса и роль xDS без смешения управляющего сервера с самим прокси.
Listener и cluster отвечают за разные стороны запроса
В терминологии Envoy downstream — сторона, которая подключается к прокси, а upstream — назначение, куда прокси передаёт запрос. Эти роли определяются конкретным соединением, не постоянным статусом машины. В sidecar-сценарии локальное приложение в одном направлении может быть источником, в другом — получателем.
Listener принимает соединения на заданном адресе и организует обработку downstream-стороны. Cluster представляет логический сервис с набором endpoints. Именно cluster-подсистема хранит сведения о доступных серверах, балансировке и пулах upstream-соединений. Между этими частями HTTP-запрос передаёт router filter.
Документация «Life of a Request» показывает несколько последовательных уровней: принятие соединения, выбор цепочки фильтров, транспортную обработку, разбор HTTP и обработку отдельного потока. Один TCP-сеанс HTTP/2 может содержать несколько запросов, поэтому жизненный цикл соединения не совпадает с жизненным циклом одного сообщения. Рабочий поток обслуживает downstream-соединение, а его запросы используют соответствующие upstream-пулы. Прокси при этом может стоять на границе сети, внутри системы или рядом с приложением: внутренние понятия не ограничиваются одной топологией service mesh.
Маршрут выбирает логическое назначение, а не обязательно IP
HTTP router сопоставляет входящий запрос с правилами и выбирает upstream cluster. Виртуальный хост связывает домен или authority с набором маршрутов. Далее могут учитываться точный путь, префикс, регулярное выражение и заголовки. Это решение происходит на прикладном уровне и отличается от принятия TCP-соединения на listener.
После выбора назначения router получает пул соединений к подходящему серверу. Маршрут способен также вернуть прямой ответ или перенаправление, вообще не выполняя обычный проксирующий проход. Изменение префикса либо host при передаче — ещё отдельное действие: выбор backend и преобразование направляемого сообщения не являются одной операцией.
Документация описывает распределение трафика между кластерами по весам, тайм-ауты и повторные попытки. У этих механизмов разные области действия. Доля между двумя версиями сервиса задаёт логический выбор версии; балансировщик внутри выбранного кластера затем выбирает конкретный endpoint. Поэтому фраза «отправить часть запросов новому сервису» скрывает как минимум два уровня: определение целевого множества и выбор его участника. На схеме маршрутов показана конфигурационная структура, а не последовательность обмена сообщениями xDS.
Обнаружение сервиса определяет состав множества серверов
Cluster должен получить список или способ разрешения своих endpoints. Самый простой статический вариант задаёт адреса явно. Strict DNS периодически асинхронно разрешает имя и рассматривает возвращённые IP как отдельных участников кластера. Если адрес исчезает из результата, меняется и представление состава сервиса.
Logical DNS использует другую модель: результат DNS нужен для установления нового соединения, но весь ответ не трактуется как точный неизменный перечень участников. Существующие соединения не сбрасываются только из-за нового набора DNS-адресов. Это важно для крупных внешних сервисов, где ответы могут регулярно различаться и не означают фактическое исчезновение прежних серверов.
Оба варианта разрешают имена асинхронно: обычная пересылка запроса не должна ждать синхронного DNS-запроса. Однако различается интерпретация результата и работа с пулами. Отдельный путь — EDS, где состав приходит через управляющий API. Таким образом, обнаружение не является алгоритмом балансировки само по себе. Оно предоставляет множество и свойства участников, а последующее решение о конкретном соединении использует эти сведения вместе с другими настройками cluster.
Обнаруженный адрес ещё не означает здоровый сервис
Активные проверки здоровья выполняются для upstream cluster и помогают определить пригодность endpoints. Наличие записи в DNS или EDS говорит о регистрации адреса, но не доказывает, что приложение обслуживает запросы. Интервалы проверок, пороги успешных и неудачных ответов и ожидаемое поведение задаются отдельно.
HTTP-проверка отправляет запрос и оценивает ответ по настроенным условиям. Для gRPC предусмотрен свой механизм, а на транспортном уровне возможна проверка соединения или обмен определёнными байтами. Документация также описывает специализированные варианты для отдельных протоколов. Проверочный адрес или порт участника может отличаться от адреса обычной обработки данных.
Активная проверка отличается от passive health checking: outlier detection использует сведения, полученные при реальной работе с сервером. Это два источника информации о состоянии, а не два названия одного фонового запроса. Проверки проходят через настроенный транспорт и могут требовать соответствующих параметров TLS. В результате доступность адреса, успех специального health endpoint и результаты пользовательских запросов представляют разные наблюдения. Envoy позволяет учитывать их в маршруте к endpoint, но не смешивает регистрацию сервиса с выполнением его прикладной функции.
xDS разделяет динамические ресурсы по назначению
Для простой установки Envoy допускает статическую конфигурацию. Динамическая схема добавляет внешние сервисы управления, которые предоставляют ресурсы через APIs, вместе называемые xDS. Это не отдельный механизм пересылки пользовательского HTTP-трафика: управляющие сообщения описывают, как прокси должен работать.
EDS передаёт участников кластера, CDS — определения кластеров, RDS — конфигурацию HTTP-маршрутов, LDS — listeners и связанные цепочки. Их можно вводить постепенно, не делая всю конфигурацию динамической одномоментно. RDS позволяет заменять правила без вмешательства в уже выполняющиеся запросы. Изменение состава через EDS также отличается от пересоздания определения cluster: нет необходимости затрагивать существующие подключения к неизменённым участникам тем же способом.
Существуют и более специализированные ресурсы — например, отдельное обнаружение виртуальных хостов или разделённых таблиц маршрутизации. Смысл разделения состоит в независимых объектах управления и ссылках между ними. Envoy получает определения, а решение о том, какие определения сформировать для этой инфраструктуры, принимает внешняя control plane. Стандартный протокол доставки не создаёт такую бизнес-логику автоматически и не делает любой управляющий сервер взаимозаменяемым по своему содержанию.
| API | Ресурс | За что отвечает |
|---|---|---|
| LDS | Listener | Входные listeners и фильтры |
| RDS | RouteConfiguration | Правила HTTP-маршрутизации |
| CDS | Cluster | Определения upstream-сервисов |
| EDS | ClusterLoadAssignment | Наборы endpoints кластеров |
Источник: Envoy: xDS configuration API overview
Подтверждение ресурса не равно атомарному переключению сети
В потоковом gRPC xDS клиент подписывается на ресурсы, сервер отправляет DiscoveryResponse, а клиент сообщает о результате проверки. ACK означает, что ресурсы признаны допустимыми по отдельности и клиент намерен их применить. Это не универсальное доказательство успешного применения всей конфигурации. NACK указывает на недопустимость как минимум части ответа и содержит сведения об ошибке.
Nonce связывает подтверждение с конкретным ответом внутри потока; версии ресурсов решают другую задачу. Ресурсы имеют зависимости: route может ссылаться на cluster, а тот — на набор endpoints. Если новый маршрут придёт раньше своего назначения, возникает временно неполная схема. Документация поэтому описывает последовательность make before break: сначала подготовить новое назначение, затем переключить ссылки и лишь потом удалить старое.
Согласованность xDS достигается не мгновенной глобальной транзакцией. Прокси выполняет прогрев некоторых новых ресурсов, а управляющая система должна учитывать порядок обновлений. Это объясняет, почему отсутствие перезапуска не означает отсутствие переходного состояния. Пользовательский трафик продолжает идти через data plane, пока control plane постепенно меняет её конфигурацию; эти два потока связаны результатом настройки, но не являются одним соединением.
