Rollout: выкатка через Canary

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

#Что нужно

В кластере:

• Argo Rollouts. Сервис описан объектом Rollout со стратегией canary. С маршрутизацией трафика доля Canary точная, без неё — приблизительная, по числу подов.
• Prometheus, доступный из кластера.
• Метрики запросов сервиса с меткой эндпоинта, а лучше и с методом и кодом ответа. Ещё нужен способ отличить Canary от Stable (текущей версии в продакшене): по поду или по метке версии. Очереди, задачи и запросы к базе попадают в проверки, только если есть метрики из трейсов.
• Если нужны feature flags — свой Unleash, а код читает флаги через OpenFeature. Выкатка через Canary работает и без флагов.

На компьютере:

• kubectl и kubeconfig с контекстом этого кластера;
• модуль Observe, подключённый к Prometheus: без него модуль «Rollout» не работает. Если метрик нет совсем, выкатка не запустится, потому что у неё не было бы автоматического отката.

#Как строится план

Риск модуль определяет по смыслу изменения:

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

После последнего этапа на Canary идёт 100 % трафика. Если трафика мало, этап длится дольше; короче, чем в таблице, он не бывает. Если изменение касается миграций, схемы базы, удаления данных, платежей или авторизации, оно запустится только после того, как вы нажмёте «Approve».

#Вид «Rollout»

Нажмите кнопку «Другие инструменты» в шапке окна, сразу после кнопок инструментов, и выберите «Rollout». Слэш-команды у вида нет. Кнопки запуска в виде тоже нет: выкатку запускает агент, попросите его об этом в чате. Вкладки:

• «Решения» — всё, что ждёт вашего ответа: «Approve запуска» («Approve» или «Cancel»), «Stage N: Promote?» и «Stage N: Inconclusive» («Promote», «Hold» или «Rollback»). Каждое решение приложение просит подтвердить и называет кластер, namespace и объект. Причина отката попадёт в инцидент.
• «Rollouts» — выкатки с фазой («Running», «Succeeded», «Rolled back»…), этапами и вердиктом по каждому этапу: «Healthy», «Inconclusive» или «Degraded». Вердикт написан словами задачи, например «на POST /orders Canary проваливает 4 % запросов против 0,3 % у Stable». Здесь же — «Почему план такой» и что не удалось измерить.
• «Queue» — очередь выкаток по каждому сервису: одновременно идёт одна выкатка, остальные ждут.

#Что может агент

С модулем «Rollout» агент читает план, запускает по нему выкатку, следит за ней, читает вердикт этапа и откатывает свою выкатку. Ещё он создаёт feature flag и включает свой флаг группам пользователей по очереди, по тем же этапам и с теми же вердиктами, что у выкатки через Canary. Чтобы откатить флаг, агент выключает его для всех. Карточки подтверждения у запуска выкатки нет: изменение, которое не трогает базу, платежи и авторизацию, агент запускает сам.

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

#Без открытого приложения

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

#Ограничения

• Для проекта на сервере по SSH выкатками управляет сервер: работают его kubectl и kubeconfig.
• Модуль пишет в ваш кластер служебные объекты: записи выкаток, планы, очередь и шаблоны проверок. Их можно узнать по метке app.kubernetes.io/managed-by: koder-rollout.

#Какие данные куда уходят

Модуль работает с кластером через ваш kubectl и пишет только в ваш кластер и ваш Unleash. На серверы DevMachine он ничего не отправляет. План, вердикты и выдержки из логов, которые читает агент, попадают в запрос к модели и идут к ней через сервер DevMachine. Подробнее — на странице «Данные и приватность».

#Что дальше

• Observe: логи, трейсы, метрики и ошибки
• Инциденты
• Kubernetes
• Модули