Сообщить об ошибкеКороткий ответ
Canary-деплой выкатывает новую версию только на небольшую часть трафика или пользователей (например, 5%), пока основная часть продолжает работать на старой версии; название — отсылка к канарейкам, которых шахтёры брали под землю для раннего обнаружения опасного газа: если «канарейка» (небольшая группа пользователей) не пострадала, версию раскатывают дальше.
Как это работает подробнее
трафик делится между старой и новой версией по весу (например, через Ingress-аннотации, service mesh или API Gateway), и метрики новой версии (ошибки, задержка) сравниваются со старой; при отсутствии проблем доля трафика на новую версию постепенно увеличивается до 100%.
Пример кода
example.yaml
# Пример весов через Ingress-аннотации (nginx-ingress)
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "5"Что использовать на практике
- На практике. canary отличается от rolling update тем, что при rolling update нет контролируемого сравнения старой и новой версии по метрикам — просто происходит последовательная замена подов; canary же осознанно ограничивает воздействие новой версии и даёт время и данные для принятия решения «раскатывать дальше или откатить».
- Пример. Ожидаемое поведение: 5% входящих запросов направляются на canary-версию сервиса, остальные 95% — на стабильную; при увеличении `canary-weight` до 100 вся нагрузка постепенно переходит на новую версию.
Подводные камни
- Частые ошибки. путают canary с обычным поэтапным rolling update, не замечая отсутствия явного сравнения метрик; запускают canary без автоматического или хотя бы чёткого ручного критерия остановки, из-за чего проблемная версия долго остаётся частично в проде незамеченной.