A/B Deployment в Kubernetes: настройка разделения трафика и сбор метрик

A/B Deployment: где ломается разделение трафика

Разделение трафика в Kubernetes настраивается за полчаса: веса на входном балансировщике, два набора подов, переключатель. Ломается A/B Deployment не на конфиге, а на том, что две версии сервиса живут одновременно. Пока новая версия набирает трафик, старая продолжает писать в ту же схему данных — если миграция ушла вперёд и обратной совместимости нет, часть запросов падает именно на старой ветке. Внешне релиз при этом выглядит успешным: сборка прошла, поды в Ready, в логах тихо.

Липкие сессии при выпуске добавляют второй класс отказов. Пользователь привязан к конкретному поду на время сценария, а под через минуту выводится из ротации — сценарий обрывается на середине, корзина теряет состояние, и воспроизвести это в тестовом контуре почти невозможно. Метрики в этот момент слепые: агрегированная доля ошибок размывается по обеим версиям, и по ней нельзя сказать, какая ветка деградирует, а какая держит нагрузку.

Третий отказ — откат релиза вручную по звонку. Дежурный уточняет у аналитика, можно ли доверять цифрам, трафик всё это время идёт на проблемную версию, а переключение весов делает человек в консоли: без истории изменений и без проверки, что предыдущая версия совместима с текущим состоянием схемы данных.

Разбираем, как это закрывается: как развести миграции и релизы по времени, удержать сессии при смене весов и собрать метрики, по которым решение об откате принимается без звонка.

Что даёт управляемое разделение трафика

Когда трафик распределяется весами на маршруте, а не переключением «выкатить всё сразу», доля новой версии становится управляемым параметром. В Istio это описывается декларативно: часть запросов уходит на новую версию, остальное — на текущую, и вес меняется одной правкой правила без пересборки образов.

Отсюда два измеримых следствия. Доля отказов при релизе падает: новая версия сначала видит малую часть живого трафика, а не весь поток, поэтому дефект задевает ограниченный круг сессий. Время восстановления сервиса измеряется минутами — откат возвращает веса, не пересоздавая поды и не разрывая установленные соединения.

Сравнение версий на живом трафике перестаёт быть спором о гипотезах. Запросы разделяются по вариантам, метрики собираются параллельно, поэтому разница в задержке, доле ошибок и конверсии видна на одних и тех же сценариях. Наблюдаемость выпуска держится именно на этом: у релиза есть графики, по которым решение о расширении доли или об откате принимают по данным, а не по ощущению дежурного.

Управляемый откат доступен на всём протяжении выката и не требует участия автора релиза — достаточно снять долю трафика. Оба варианта при этом остаются живыми столько, сколько нужно, а второй снимается после того, как метрики сошлись.

Варианты разделения трафика: сравнение подходов

Выбор способа разделения трафика определяет, сколько времени займёт откат и какие метрики придётся сверять на каждом шаге. Ниже — рабочие альтернативы: они не взаимоисключающие, но требуют разной степени контроля над маршрутизацией и разной зрелости наблюдаемости.

На практике варианты комбинируют: маршрутизация по весам задаёт долю, канареечные шаги управляют её ростом, а переключатели функциональности страхуют отдельный тяжёлый узел, который нельзя откатывать вместе со всей сборкой.

Внедрение A/B Deployment: этапы работ

Разделение трафика между версиями живёт на общем входе в кластер, поэтому ошибка в правилах маршрутизации бьёт не по эксперименту, а по всем пользователям сразу. Мы ведём работы по фиксированному порядку: сначала описываем, как трафик ходит сейчас, потом проектируем схему и только затем включаем её в проде.

1. Аудит маршрутизации кластера. Собираем карту входных точек, объектов сервисов и правил: что уже отвечает за распределение, какие настройки заданы вне репозитория вручную и какие версии приложений реально принимают трафик.
2. Проектирование схемы разделения трафика. Выбираем признак деления — доля запросов, заголовок или метка группы пользователей — и фиксируем, какие правила должны срабатывать при недоступности одной из версий. Схема ложится в декларативные манифесты, а не в ручные правки в интерфейсе.
3. Настройка разделения. Разворачиваем правила и веса, привязываем сессию пользователя к версии, ограничиваем долю пробной версии, чтобы она не забрала на себя всю нагрузку при сбое.
4. Метрики и наблюдаемость. Помечаем запросы признаком версии, чтобы метрики считались раздельно: доля ошибок, время ответа, глубина прохождения ключевых сценариев по каждой версии отдельно.
5. Проверка под нагрузкой. Прогоняем профиль, близкий к реальному трафику: смотрим фактическое распределение, поведение при отказе одной версии и время переключения весов.
6. План отката. Фиксируем, какой сигнал считаем аварийным и по какой команде весь трафик возвращается на стабильную версию в один шаг — без пересборки и повторного развёртывания.
7. Передача в эксплуатацию. Отдаём документацию по схеме, регламент запуска новых экспериментов и инструкцию для дежурной смены: как прочитать метрики и что делать при отклонении.

Артефакты на выходе: манифесты, схемы, регламенты

Работа заканчивается не презентацией, а набором файлов в вашем репозитории и на вики. Мы передаём всё, что нужно, чтобы разделение трафика между версиями ваша команда обслуживала сама — правила отбора, доли, разбор инцидента на дежурстве.

• Конфигурации маршрутизации — манифесты с весами версий, правилами отбора по заголовкам запроса и признакам сессии. Изменение доли трафика — правка одного параметра, без пересборки приложения.

• Политики доступа и роли — кто меняет веса, кто только читает метрики, кто выкатывает вторую версию; права выданы по минимально необходимому набору.

• Схема потоков трафика — от внешнего балансировщика до подов каждой версии, с отмеченными точками снятия метрик и местом срабатывания правила отбора.

• Набор метрик и правила сравнения — какие показатели считаем сигналом отставания версии, на каком окне наблюдения и с какой задержкой они приходят дежурному.

• Регламент выпуска — порядок выката второй версии, критерии расширения доли, условия и время возврата всего трафика на прежнюю версию.

• Инструкции для дежурной смены — пошаговые сценарии: метрика ушла в минус, вторая версия перестала отвечать, нужно срочно снять эксперимент.

• Чек-лист передачи — что ваша команда проходит вместе с нашими инженерами на первом самостоятельном выпуске.

Кейс: разделение трафика с метриками до и после

До: ручное переключение и откат по инструкции

Клиент — сервис с постоянным потоком запросов, где каждый выпуск делали вручную: вес новой версии в балансировщике правили через панель, а состояние сравнивали по логам приложения и сообщениям поддержки. На один релиз приходилось 11 ручных шагов — от правки конфигурации до проверки на части узлов. Откат занимал от 25 до 40 минут: возврат веса, перезапуск пода и прогрев кэша делали по инструкции, и всё это время часть пользователей получала ошибки. На релизных окнах доля ответов с кодом 5xx доходила до 1,8%, а причина выяснялась уже после факта.

После: сравнение вариантов на живом трафике

Дальше по входящему шлюзу мы подняли Istio и развели версии по двум группам: одна получает трафик по весу, вторая — по заголовку, чтобы тестировать конкретных пользователей без влияния на остальных. Вес меняется правкой одного ресурса, а не через панель, и снимается одним шагом — откат стал занимать около 40 секунд без перезапуска.

Метрики теперь собираются отдельно по каждой группе: доля ошибок, доля медленных ответов, глубина прохождения по сценарию и число отказов на этапе оформления. Сравнение идёт по одинаковым окнам времени, поэтому видно не «стало лучше», а насколько именно отличается версия.

По итогам трёх месяцев выпусков: ручных операций осталось две вместо одиннадцати, доля ошибок на проде упала до 0,2%, а 94% релизов прошли без возврата на предыдущую версию — откат перестал быть штатной частью выпуска.

Чем канареечный выпуск отличается от сине-зелёного

Канареечный выпуск делит трафик между старой и новой версией долями — 5, 25, 50 процентов — и повышает их по мере роста показателей. Скорость отката здесь измеряется секундами: возврат веса к нулю уводит поток на прежнюю версию без пересборки и перезапуска.

Сине-зелёное развёртывание держит два полных окружения и переключает весь трафик одним движением — сменой селектора сервиса или правила маршрутизации. Откат так же быстр, но переключается сразу вся аудитория, поэтому ошибка видна всем, а открытые соединения при смене окружения рвутся.

Стоимость ресурсов при выпуске различается сильнее всего. Канареечному контуру нужна ёмкость лишь под текущую долю трафика, и она растёт вместе с весом; сине-зелёному — полный дубль окружения, который простаивает всё время подготовки и проверок.

Схема данных — главный водораздел. Канареечный выпуск держит обе версии в проде одновременно, поэтому схему меняют расширением: новое поле добавляют необязательным, старая версия его игнорирует, и лишь после её вывода код мигрирует данные. Сине-зелёное допускает миграцию внутри окна переключения, но общая база остаётся, и несовместимое изменение ломает одну из сторон.

Для сравнения метрик канареечный режим удобнее: трафик режется по метке версии, и конверсия, доля ошибок и задержки сравниваются на однородной выборке. Сине-зелёное даёт результат «всё или ничего» — разная база мешает набрать статистику, и решение принимают по факту, а не по данным.

Частые технические сомнения перед стартом

Разделение трафика на входе в кластер не требует переписывать сервис: версии остаются двумя отдельными развёртываниями, а маршрут по заголовку или cookie решает, куда уйдёт запрос. Ниже — то, что чаще всего уточняют на этапе оценки.

Можно ли оставить общую базу между версиями?

Да, пока схема обратно совместима: новые поля добавляем необязательными, старые не удаляем, пока вторая версия в работе. Ломающее изменение разводим на два шага — сначала обе версии читают обе структуры.

Насколько достоверна статистика выпуска?

Нужна устойчивая привязка человека к группе — cookie или идентификатор, иначе один пользователь попадёт в обе группы и метрики смешаются. Объём выборки считаем до запуска, иначе разница окажется в пределах шума.

Что делать с уже настроенной маршрутизацией?

Существующие правила сохраняем: A/B-маршрут вешаем поверх с более высоким приоритетом и перехватываем только нужный заголовок или долю трафика. Перед включением прогоняем приоритеты на стенде.

Совместимы ли окружения между собой?

Стенд и продуктив держим на одинаковых версиях кластера и наборе дополнений, иначе маршрутизация ведёт себя по-разному. Манифесты храним однотипными наборами — отличия только в значениях.

Обсудим задачу: что нужно от вашей стороны

Чтобы оценка была предметной, а не «на глаз», нам нужен минимум исходных данных по вашему контуру. Достаточно описать словами и подтвердить доступами — дальше мы соберём схему разделения трафика и план внедрения под ваш релизный цикл.

• Схема маршрутизации как есть: ingress или service mesh, какие правила весов уже настроены, есть ли канареечные релизы и как сейчас распределяется поток между версиями.
• Целевые метрики выпуска: по каким сигналам считаем версию удачной — доля ошибок, задержка ответа, конверсия ключевого сценария, глубина бизнес-события.
• Доступы к контуру: тестовый и продуктивный кластеры, права на изменение маршрутов и политик, отдельный контур для репетиции переключения весов.
• Границы эксперимента: какие версии сравниваем, нужно ли удержание пользователя в одной группе между сессиями, как поступать с авторизованными и гостевыми сессиями.
• Бюджет риска: допустимая доля трафика на новую версию, условие автоматического отката и время, за которое переключение должно происходить.
• Наблюдаемость: какие сборщики метрик и трассировки уже стоят, куда пишутся логи, есть ли готовые панели и алерты по расхождению групп.
• Ограничения среды: режимы сети между сервисами, требования по шифрованию, регламент изменений в продуктиве и окна, когда релиз допустим.

Опишите задачу в свободной форме — пришлём оценку работ по разделению трафика, схему конфигурации и пошаговый план внедрения с точками отката.