Настройка Envoy прокси: где рвётся трафик на пиках
Когда обратный прокси под нагрузкой ведёт себя непредсказуемо, искать причину в приложении почти бессмысленно: узкое место на входе проявляется раньше, чем запросы доходят до сервисов. Долгие соединения — потоковые выгрузки, тяжёлые отчёты, сессии реального времени — рвутся при плановом перезапуске процесса, потому что он завершается быстрее, чем успевают доработать уже принятые запросы. В логах это выглядит как всплеск ответов об ошибке на ровном месте, без единой правки в коде.
Второй источник — рассинхрон конфигурации между узлами. Правила маршрутизации обновляют на одном сервере перечитыванием файла, а на остальных они остаются прежними. Пока трафик распределяется по всем узлам, один и тот же адрес попадает то под новый маршрут, то под старый: часть клиентов получает корректный ответ, часть — ошибку маршрутизации. Воспроизвести это на стенде не выходит — там узел один, и расхождению просто неоткуда взяться.
Третий класс отказов — ручные правки под нагрузкой. Изменение правил в час пика требует перечитать конфигурацию, а сделать это без разрыва уже установленных соединений удаётся не всегда. Каждая такая операция открывает окно, в котором теряется часть трафика, и чем чаще меняются маршруты, тем шире это окно. Именно поэтому настройка Envoy прокси начинается не с файла конфигурации, а с ответа на вопрос, как правила попадают на все узлы одновременно и что происходит с соединениями в момент их применения.
Разбираем, как это закрывается: от динамической выдачи конфигурации без перезапуска до управляемого завершения соединений.
Что даёт управляемый обратный прокси: эффект в цифрах
Единая точка входа снимает с приложений работу входного слоя: проверку клиентских сертификатов, ограничение частоты запросов, повторы к недоступным узлам, согласование схемы. Сервис занимается своей логикой, а не транспортом, — и перестаёт падать от некорректного запроса или от того, что сосед не ответил вовремя. Такую роль отдаём прокси Envoy, где маршруты, правила и взаимная аутентификация по сертификатам описаны декларативно, а не размазаны по коду приложений.
Что меняется в цифрах
Время применения конфигурации. Раньше правка маршрута означала пересборку образа и перезапуск — десятки минут и обрыв соединений. Динамическая конфигурация подхватывается на лету: изменение вступает в силу за секунды, активные соединения не рвутся, перезапуск не нужен.
Доля отказов при нагрузке. Балансировка с учётом фактического состояния узлов, автоматические повторы на другом экземпляре и размыкание цепи до нездорового сервиса убирают каскадные ошибки на всплеске. Просадка одного экземпляра перестаёт быть заметной для пользователя.
Ручные операции на выкладку. Маршруты, сертификаты и правила описываются версионируемым набором файлов и применяются одним изменением — вместо серии ручных правок на каждом узле.
Отдельно уходит класс инцидентов «обновили входной слой — часть сервисов отвалилась»: отказоустойчивость входного слоя обеспечивается на уровне самого прокси, а не героическими действиями дежурного.
Сравнение режимов конфигурации: статика, файлы, динамика
В Envoy настройка попадает в процесс одним из трёх путей: статический файл при старте, конфигурация как код из репозитория с автоприменением или поток с управляющего сервера. Разница проявляется в цене правки — перезапуск с разрывом соединений против обновления маршрута на живом трафике.
Четвёртый путь — не содержать прокси-слой вовсе, а взять готовый облачный балансировщик. Ниже границы применимости каждого варианта, включая те, где подход упирается в собственные ограничения.
| Вариант | Когда подходит | Ограничения подхода |
|---|---|---|
| Статическая конфигурация | Стенды, единичные сервисы, редкие правки маршрутов | Любое изменение — перезапуск с разрывом соединений; не масштабируется на десятки узлов |
| Конфигурация как код в репозитории с автоприменением | Один-два контура, изменения по расписанию, нужен аудит и откат через историю | Применение занимает минуты; нет реакции на падение узла или рост нагрузки |
| Динамическая выдача настроек с управляющего сервера | Много сервисов, частые релизы, канареечные схемы, горячая смена маршрутов | Требует управляющего сервера и его наблюдаемости; ошибка расходится по всем узлам сразу |
| Готовый облачный балансировщик | Не хочется содержать прокси-слой, трафик уже идёт через облако | Меньше контроля над таймаутами, повторами и mTLS-политиками; сложнее сменить провайдера |
На практике варианты комбинируют: статика поднимает сам прокси, динамика обновляет маршруты и сертификаты. Общее ограничение одно — без проверки конфигурации в тестовом контуре и поэтапного раската ошибка попадает сразу на весь трафик.
Порядок внедрения: от аудита трафика до передачи
Начинаем с инвентаризации: какие сервисы принимают внешний трафик, где терминируется TLS и где нужна взаимная аутентификация. Без карты потоков правка маршрутов превращается в угадывание — сначала фиксируем факты, потом трогаем конфигурацию.
- Аудит трафика. Снимаем картину с журналов и метрик: доли протоколов, пиковые значения, долгие соединения, источники запросов. На выходе — перечень маршрутов с владельцами и требованиями к шифрованию.
- Схема маршрутизации. Проектируем listeners, clusters и правила: по домену, пути или заголовку, с политиками mTLS, проверкой сертификатов и таймаутами. Согласуем схему до написания конфигурации.
- Настройка узлов. Разворачиваем прокси Envoy и подключаем динамическую конфигурацию, чтобы правки применялись без перезапуска и обрыва соединений. Отдельно проверяем поведение при недоступном источнике конфигурации.
- Проверка под нагрузкой. Прогоняем профиль, близкий к боевому: пиковые запросы, обрыв соединения на половине ответа, отказ одного узла. Смотрим время отклика и долю ошибок, правим лимиты.
- Поэтапный перевод трафика. Переключаем потоки частями, от менее критичных к основным, с возможностью вернуть маршрут назад одной правкой. На каждом шаге сверяем метрики с базовыми.
- Передача регламентов. Отдаём схему, конфигурацию в системе контроля версий, порядок выпуска изменений и порядок отката, обучаем дежурных.
Дальше маршруты и сертификаты меняет ваша команда — по документированным правилам, без простоев и без нас.
Артефакты конфигурации: схемы, политики, регламенты
Несколько конфигураций прокси, которые правятся руками в редакторе, живут ровно до первого ухода инженера. Рабочая настройка Envoy — это набор согласованных артефактов, где зафиксированы маршруты, правила доступа и порядок их изменения. Ниже — перечень того, что остаётся у заказчика вместе с доступом к стендам.
- Схемы маршрутизации: карта виртуальных хостов, префиксов путей и целевых сервисов с временем ожидания ответа, числом повторов и правилами распределения нагрузки.
- Топология узлов: где стоят экземпляры прокси, как раздаётся конфигурация и что происходит при потере связи с её источником.
- Политики доступа: правила двусторонней проверки сертификатов, списки доверенных клиентов, ограничения по методам и путям, лимиты частоты запросов.
- Роли и права: кто меняет маршруты, кто только читает метрики, кто выдаёт сертификаты, и порядок согласования таких действий.
- Регламент выпуска изменений: проверка синтаксиса, прогон на промежуточном стенде, выкатка по узлам, подтверждение результата.
- Регламент отката: хранение предыдущих версий, признак запуска возврата и время, за которое конфигурация снова становится рабочей.
- Инструкция дежурной смены: типовые симптомы, команды диагностики, порядок эскалации и действия, которые дежурный не выполняет без согласования.
Документация лежит в том же репозитории, что и конфигурация, и обновляется вместе с ней — новый инженер входит в работу без пересказов, а каждое изменение остаётся воспроизводимым.
Пример из практики: цифры до и после изменения
Клиент пришёл с платформой из девяти сервисов: вход в боевой контур держался на одном узле с конфигурацией, которую правили руками. Выкладка новой версии означала перезапуск — трафик на 1–3 минуты уходил в ошибку, а при опечатке в маршруте окно затягивалось до 20 минут. Сертификаты обновлялись по календарю и дважды за квартал ломали взаимную аутентификацию между сервисами — со стороны это выглядело как отказы на ровном месте.
Что изменили
Перевели вход на Envoy с динамической конфигурацией: маршруты и перечень сервисов отдаёт управляющий слой по подписке, поэтому правило применяется без перезапуска и разрыва соединений. mTLS настроили с автоматической выдачей и ротацией — короткий срок жизни сертификата и перевыпуск без участия дежурного. Маршруты и проверки здоровья вынесли в декларативные файлы, изменения проходят проверку до применения.
Что получилось
Простой при выкладке исчез: конфигурация меняется на живом трафике, доля успешных ответов в момент релиза не отличается от обычного дня. Путь от правки до эффекта на всех узлах сократился с 25–40 минут до минуты. Инциденты с истёкшими сертификатами и рассинхроном узлов перестали повторяться: за квартал — ни одного внепланового простоя из-за изменения входа.
Откат теперь — возврат предыдущей версии конфигурации, а не аварийный перезапуск с прогревом, поэтому время восстановления упало с десятков минут до пары минут.
Чем отличается взаимная аутентификация на узле от проверки в сервисе?
Взаимная аутентификация на узле и проверка подлинности сервиса — это два разных уровня, и путать их дорого. На входе Envoy отвечает на вопрос «кто пришёл»: предъявлен ли сертификат, выданный доверенным удостоверяющим центром, сходится ли цепочка до корня, не истёк ли срок действия и совпадает ли имя владельца с ожидаемым. Сервис отвечает на другой вопрос — «что этому вызывающему разрешено»: конкретная операция, роль, область доступа в данных. Первое — про подлинность, второе — про полномочия, и подмена одного другим ломает всю модель.
Зона доверия заканчивается там, где терминируется защищённое соединение. Если проверку оставить только в коде сервисов, каждый из них тащит собственную логику разбора цепочки, контроля отзыва и обновления корневых сертификатов — и рано или поздно один отстаёт в этом от остальных. Расхождение в правилах означает, что часть внутренних обращений проходит по ослабленным требованиям, и никто этого не замечает, пока не начнётся разбор инцидента.
Внутренним считается обращение, которое прошло входной слой и несёт подтверждённую метку зоны. На практике это выглядит так: исходящие вызовы перехватываются на уровне узла, сертификат подставляется автоматически, а сервис вообще не хранит приватные ключи и не умеет их читать. Такой подход убирает целый класс ошибок — забытый таймаут проверки отзыва, зашитый в образ корневой сертификат, самоподписанный ключ, оставшийся с отладки.
На входной слой переносят всё, что можно проверить без знания бизнес-логики: цепочку, сроки, отзыв, набор допустимых протоколов и версий, ограничения по адресам. В сервисе остаётся авторизация — она зависит от предметной области и без неё не работает. Разделение даёт ротацию сертификатов без пересборки сервисов и единую точку, где меняется политика контура безопасности. Поэтому два уровня не заменяют, а дополняют друг друга.
Технические сомнения: откат, отладка, отказоустойчивость
В Envoy динамическая конфигурация приходит от управляющего сервера, и её применение не требует перезапуска процесса: слушатели и кластеры обновляются на лету, а установленные соединения доживают до завершения активных запросов. Если новый набор оказался битым, узел возвращается к последней валидной версии без ручного вмешательства.
Что происходит с установленными соединениями при применении новой конфигурации?
Слушатель переходит на новый набор правил, но активные потоки не обрываются: соединение живёт до закрытия со стороны клиента или до истечения времени ожидания из политики. Для долгих сессий время задаётся отдельно, чтобы обновление не рвало текущую работу.
Как откатить неудачное изменение?
Конфигурация версионируется, поэтому откат — это возврат предыдущего набора, а не ручная правка по памяти. Сценарий отрабатывается заранее: известно, за какое время узел возвращается в рабочее состояние и какие соединения переживают переключение.
Как читать журналы при разборе инцидента?
Журналы доступа, журналы прокси и трассировка связываются по идентификатору запроса: по нему видно узел, правило и причину отказа. Этого хватает, чтобы отделить ошибку маршрутизации от сбоя вышестоящего сервиса.
Что будет, если один узел выйдет из строя?
Узлы работают группой: при падении одного трафик уходит на живые, а проверки доступности выводят нездоровые экземпляры из ротации. Каждый узел хранит конфигурацию локально, поэтому недоступность управляющего сервера не роняет уже работающий контур.
Обсудим задачу: что нужно с вашей стороны и что делаем мы
Старт не должен превращаться в неделю переписки: вводные фиксируем сразу, чтобы оценка опиралась на реальный контур, а не на предположения. Ниже — что нужно от вашей стороны и что закрываем мы.
- Доступы. Только на чтение — к узлам, где работает прокси, к репозиторию с текущей конфигурацией, к системе управления секретами и к зоне DNS. Список учётных записей и ролей передаём заранее, лишнего не запрашиваем.
- Инвентаризация контура. Какие сервисы публикуются наружу, где точки входа, сколько сред и как они изолированы. От этого зависит число конфигураций и схема маршрутизации.
- Потоки и сертификаты. Домены и пути, откуда приходят клиенты, нужна ли взаимная проверка сертификатов на входе и кто их выпускает — ваш удостоверяющий центр или внешний.
- Доставка конфигурации. Правится ли она сейчас руками или доставляется автоматически, есть ли способ вернуться к предыдущей версии и кто имеет право на правку в промышленной среде.
- Наблюдаемость. Куда уходят журналы доступа, метрики и трассировки, какие оповещения уже настроены и по каким порогам срабатывают.
- Ограничения. Требования по доступности, окна, когда изменения запрещены, и порядок согласования правок.
Наша зона — проектирование маршрутизации и политик доступа, разнесение конфигурации Envoy по слоям, обновление без перезапуска узлов и описанный порядок отката. По итогам разбора возвращаемся с оценкой и планом работ: этапы, последовательность выката, риски и проверки на каждом шаге.
