0004. Канареечный релиз без маршрутизатора трафика¶
Дата: август 2026. Состояние: принято.
Контекст¶
Нужен релиз, который сам отказывается от плохой версии. Argo Rollouts умеет это двумя способами.
С маршрутизатором трафика — Istio, Traefik со взвешенными службами, шлюз Kubernetes — контроллер задаёт долю запросов новой версии точно: 5 %, потом 20 %, потом 50 %. Без маршрутизатора вес задаётся долей реплик: за одной службой стоят поды обеих версий, и распределение получается пропорциональным их числу.
Istio на этом узле занял бы 500–700 МБ. Traefik со взвешенными службами требует
своих объектов TraefikService вместо обычной публикации и своей настройки
контроллера.
Решение¶
Канарейка по доле реплик, без маршрутизатора. Шаги: 34 % — пауза 90 секунд — 67 % — пауза 60 секунд — 100 %. На каждом шаге автоматический анализ трёх показателей по Prometheus, отобранных по метке хеша шаблона пода — то есть только по новым подам.
Последствия¶
Что получили. Автоматический откат работает по-настоящему: при нарушении порога контроллер возвращает вес в ноль, и трафик остаётся на прежних подах. Человек не участвует. Проверено на стенде: версия с намеренно неверным адресом базы данных была отклонена за 61 секунду, прежние поды не пострадали, внешний адрес всё время отвечал кодом 200 — протокол проверки.
Метка хеша шаблона пода добавлена в ServiceMonitor как метка цели, поэтому
запросы к Prometheus различают старые и новые поды. Без этого анализ смотрел бы
на смесь версий и не заметил бы деградации новой.
Чем заплатили. При двух репликах доли получаются грубыми: 34 % — это один под из трёх во время перехода. Точное деление 5 % на стенде недостижимо.
Второе, менее очевидное: при малом числе реплик отдельный посетитель может попасть на новую версию с первой секунды. Промышленный канареечный релиз обычно даёт гарантию «не больше пяти процентов пользователей»; здесь такой гарантии нет.
Что рассматривалось¶
Обычное последовательное обновление — проще, но не умеет автоматически отказываться от плохой версии. Проверка готовности отловит только под, который не поднялся; версию, которая поднялась и отвечает медленно или с ошибками, она пропустит.
Istio — отклонён по памяти. На узле с 8 ГБ это был бы правильный выбор, потому что даёт и точное деление, и взаимный TLS между службами.
Синяя и зелёная среды — потребовали бы двойного запаса памяти на время переключения. На узле с 4 ГБ вторая полная копия приложения с базой не поместится.