Blue-Green Deployment в Kubernetes: реализация и Argo Rollouts

Blue-Green Deployment: почему выпуск ломает прод

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

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

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

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

Что даёт переключение между двумя средами

Механика простая: параллельно живут две среды — активная и подготовленная, трафик направляется на одну из них переключателем Service или правилом Ingress. Откат — это переключение селектора обратно, а не пересборка: время отката измеряется секундами и не зависит от размера образа или числа подов. Предыдущая версия остаётся запущенной и прогретой, поэтому возврат не сопровождается всплеском ошибок из-за холодного старта.

Готовность среды и проверка перед выпуском

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

Что это даёт в измеримых величинах

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

Отдельно уходит целый класс отказов, связанный с «откатили код — потеряли данные»: схема базы меняется так, чтобы быть совместимой с обеими версиями, и возврат становится безопасным.

Сравнение схем выпуска: blue-green deployment и канареечная

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

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

Порядок внедрения: от разбора схемы до передачи

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

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

Конфигурации, схемы стендов и регламент отката

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

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

Такой комплект снимает зависимость от конкретного специалиста: переключение и откат воспроизводимы по документу, а не по памяти.

Разбор внедрения: как сократили окно недоступности

Что было до

Сервис из десятка микросервисов в Kubernetes выпускался раз в две недели, и только в ночное окно. Один релиз занимал 3-4 часа: треть времени уходила на ручное переключение трафика, прогрев контуров и проверки, а при ошибке в новой сборке сервис уходил в отказ на 20-40 минут — пока дежурный не откатит образ и не поднимет прежний контур. Таких эпизодов набиралось до семи за квартал.

Что изменили и что стало

Подняли второй контур с идентичной конфигурацией и вынесли переключение трафика на уровень маршрутизации по схеме blue-green, а управление выкатом отдали Argo Rollouts. Новая версия сначала принимала долю трафика и только потом основной поток, критерии продвижения и отката задали метриками: доля ошибок, время ответа, состояние проверок готовности. Если показатели выходили за порог, выкат останавливался сам, а трафик возвращался на прежний контур без участия дежурного.

Время выпуска сократилось с 3-4 часов до 20-25 минут, и ночное окно перестало быть обязательным. Число инцидентов на релизах упало с семи за квартал до одного, доля откатов без простоя дошла до 100%: возврат на предыдущую версию занимает меньше минуты и не разрывает соединения пользователей. Освободившееся время команда перенесла на проверки в тестовом контуре.

Что делать, если релизный конвейер уже развёрнут?

Перестраивать действующий конвейер целиком не нужно. Blue-green встраивается как отдельный этап выпуска: сборка, тесты и проверки остаются на своих местах, меняется только способ доставки версии в кластер. Прежний процесс продолжает работать, пока новый не пройдёт проверку на одном сервисе.

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

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

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

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

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

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

Что происходит с базой данных при переключении?

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

Как разводятся секреты и ключи?

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

Как убедиться, что зелёная версия здорова, и не удвоится ли нагрузка?

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

Обсудим задачу и вернёмся с оценкой

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

Разговор идёт быстрее, когда уже понятно:

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

Если речь о blue-green deployment, отдельно проговорим, как сосуществуют две версии и по какому признаку принимается решение о переключении и откате. По этим вводным мы собираем состав работ, оценку сроков и порядок этапов — и возвращаемся с планом работ, от которого можно начинать, без недоговорённостей на старте проекта.