Прямой ответ
Canary deploy развёртывает новую версию на части трафика, поэтому деградация обнаруживается до полного перехода и откат выполняется без затрагивания всех пользователей.
| Шаг | Что выполняется |
|---|---|
| Развертывание | Новая версия на части трафика |
| Мониторинг | Проверка метрик на новой версии |
| Откат | Возврат к старой версии при деградации |
| Полный переход | Новая версия на всём трафике |
# Istio: canary traffic split
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
http:
- route:
- destination:
host: app
subset: v1
weight: 90
- destination:
host: app
subset: v2
weight: 10
Разделение трафика позволяет проверить новую версию на части пользователей, поэтому деградация обнаруживается до полного перехода. О blue‑green стратегии — в статье про blue‑green deploy.
Развертывание, мониторинг и откат
Новая версия развёртывается на части трафика, поэтому деградация обнаруживается до полного перехода на новую версию.
Развертывание на части трафика. Новая версия получает долю трафика, поэтому деградация затрагивает только часть пользователей.
Мониторинг метрик. Метрики новой версии сравниваются с метриками старой, поэтому деградация обнаруживается по расхождению.
Откат при деградации. Возврат к старой версии выполняется без затрагивания всех пользователей, поэтому сбой ограничивается частью трафика.
Практическое следствие: развёртывание новой версии на всём трафике сразу приводит к тому, что деградация затрагивает всех пользователей, поэтому откат выполняется после сбоя.
Отдельный аспект — полный переход. После подтверждения стабильности новой версии доля трафика увеличивается до полной, поэтому переход выполняется постепенно.
Три признака некорректного canary deploy.
Отсутствие мониторинга метрик. Деградация не обнаруживается до полного перехода, поэтому сбой затрагивает всех пользователей.
Отсутствие отката. Возврат к старой версии не настроен, поэтому сбой не устраняется быстро.
Полный переход без проверки. Новая версия развёртывается на всём трафике без проверки, поэтому деградация затрагивает всех.
О rolling update — в статье про rolling update; об откате релиза — в статье про rollback deploy.
Мониторинг и постепенный переход
Мониторинг метрик новой версии обнаруживает деградацию до полного перехода, поэтому откат выполняется без затрагивания всех пользователей.
Сравнение метрик. Метрики новой версии сравниваются с метриками старой, поэтому деградация обнаруживается по расхождению.
Постепенный переход. Доля трафика увеличивается постепенно, поэтому стабильность проверяется на каждом шаге.
Откат при деградации. Возврат к старой версии выполняется без затрагивания всех пользователей, поэтому сбой ограничивается частью трафика.
Практическое следствие: отсутствие мониторинга приводит к тому, что деградация не обнаруживается до полного перехода.
Практика: настройка canary deploy
1. Разворачивайте новую версию на части трафика. Доля трафика ограничивает число пользователей, затронутых деградацией.
2. Мониторьте метрики новой версии. Сравнение с метриками старой версии обнаруживает деградацию до полного перехода.
3. Настройте откат при деградации. Возврат к старой версии выполняется быстро, поэтому сбой ограничивается частью трафика.
4. Увеличивайте долю трафика постепенно. Постепенный переход позволяет проверить стабильность на каждом шаге.
5. Фиксируйте метрики в логе. Запись метрик позволяет определить, когда и на каком шаге возникла деградация.
6. Разделяйте версии по признакам. Признаки позволяют определить, какая версия обрабатывает запрос.
7. Проверяйте полный переход. После подтверждения стабильности доля трафика увеличивается до полной.
Рекомендации:
- Не разворачивайте новую версию на всём трафике сразу. Деградация затрагивает всех пользователей, поэтому откат выполняется после сбоя.
- Учитывайте долю трафика при мониторинге. Метрики новой версии сравниваются с метриками старой, поэтому деградация обнаруживается.
- Сопоставляйте откат с долей трафика. Возврат к старой версии выполняется без затрагивания всех пользователей.
- Фиксируйте метрики в ошибке. Признак в записи ошибки позволяет определить, на каком шаге возникла деградация.
- Пересматриваем долю трафика при изменении нагрузки. Рост числа пользователей требует изменения доли.
Практический сценарий: деградация не обнаружилась до полного перехода
Контекст: новая версия была развёрнута на всём трафике сразу, поэтому деградация затронула всех пользователей.
- Диагностика. Проверка показала, что новая версия была развёрнута на всём трафике без постепенного перехода. Деградация метрик обнаружилась после полного перехода, поэтому сбой затронул всех пользователей.
- Причина. Canary deploy не был настроен, поэтому новая версия развёртывалась на всём трафике сразу.
- Действия. (а) Настроили развёртывание новой версии на части трафика, чтобы деградация затрагивала только часть пользователей; (б) настроили мониторинг метрик новой версии, чтобы деградация обнаруживалась до полного перехода; (в) настроили откат при деградации, чтобы возврат к старой версии выполнялся быстро; (г) настроили постепенное увеличение доли трафика, чтобы стабильность проверялась на каждом шаге; (д) проверили полный переход после подтверждения стабильности.
- Результат. Деградация обнаруживается до полного перехода, поэтому откат выполняется без затрагивания всех пользователей.
Вывод: развёртывание новой версии на всём трафике сразу приводит к тому, что деградация затрагивает всех пользователей. Canary deploy развёртывает новую версию на части трафика, поэтому деградация обнаруживается до полного перехода.
Практический сценарий: деградация не обнаружилась до полного перехода
Контекст: новая версия была развёрнута на всём трафике сразу, поэтому деградация затронула всех пользователей.
- Диагностика. Проверка показала, что новая версия была развёрнута на всём трафике без постепенного перехода. Деградация метрик обнаружилась после полного перехода, поэтому сбой затронул всех пользователей.
- Причина. Canary deploy не был настроен, поэтому новая версия развёртывалась на всём трафике сразу.
- Действия. (а) Настроили развёртывание новой версии на части трафика, чтобы деградация затрагивала только часть пользователей; (б) настроили мониторинг метрик новой версии, чтобы деградация обнаруживалась до полного перехода; (в) настроили откат при деградации, чтобы возврат к старой версии выполнялся быстро; (г) настроили постепенное увеличение доли трафика, чтобы стабильность проверялась на каждом шаге; (д) проверили полный переход после подтверждения стабильности.
- Результат. Деградация обнаруживается до полного перехода, поэтому откат выполняется без затрагивания всех пользователей.
Вывод: развёртывание новой версии на всём трафике сразу приводит к тому, что деградация затрагивает всех пользователей. Canary deploy развёртывает новую версию на части трафика, поэтому деградация обнаруживается до полного перехода.
FAQ
Что такое canary deploy? Стратегия развёртывания, при которой новая версия развёртывается на части трафика. Деградация обнаруживается до полного перехода, поэтому откат выполняется без затрагивания всех пользователей.
Как контролируется деградация? Через мониторинг метрик новой версии и сравнение с метриками старой. Расхождение обнаруживает деградацию до полного перехода.
Как выполняется откат? Возврат к старой версии выполняется без затрагивания всех пользователей, поэтому сбой ограничивается частью трафика.
Как выполняется полный переход? После подтверждения стабильности новой версии доля трафика увеличивается до полной. Постепенный переход позволяет проверить стабильность на каждом шаге.
Источники: Kubernetes Deployment, Istio traffic management, Prometheus naming — ссылки в шапке.