Деплой и инфра
Rollout strategies: обзор с выбором ответа
Суть Синтез всего раздела в формате выбора — компромиссы стратегий, maxSurge/maxUnavailable, readiness probe, gate канарейки и безопасный для схемы rollback.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь раздел. Каждый — это решение, которое вы принимаете во время реального релиза: не определение для пересказа, а компромисс, который надо взвесить, пока на сервис идёт трафик.
Цель
Убедитесь, что умеете связать выбор стратегии, knobs rolling update, readiness-гейтинг, метрические gate канарейки и безопасный для схемы rollback — тот синтез, к которому вёл обзорный урок.
Викторина
Completed
Платёжный API на Kubernetes выкатывает рискованный рефакторинг. У вас есть дашборды Prometheus, SLO-алерты и запас ёмкости кластера, и вы хотите минимально возможное влияние на пользователей, если что-то пойдёт не так. Какая стратегия и почему?
Heads-up У recreate максимальный blast radius и гарантированный простой: все пользователи бьют в новую версию одновременно, с разрывом обслуживания посередине. Это для не-HA сервисов или окон обслуживания, а не для высокодоступного платёжного API.
Heads-up Blue-green даёт мгновенный rollback, но переключение в момент cutover открывает новую версию сразу всему трафику — blast radius больше, чем у canary, при удвоении ресурсов. С хорошей observability gate канарейки ловит сбой на 5%, а не на 100%.
Heads-up Именно observability и делает canary возможной: метрический gate бесполезен, если вы не читаете срез канарейки. Хорошие дашборды делают canary менее рискованным выбором здесь, а не несущественной деталью.
Викторина
Completed
Rolling update сообщает Deployment как 'available', все реплики подняты, однако ~30% запросов возвращают 502 в первые секунды после того, как каждый под входит в ротацию. В чём корневая причина?
Heads-up maxSurge управляет только дополнительной ёмкостью во время выката; лишние поды не вызывают 502. Симптом — трафик в неготовые поды — указывает на отсутствующий readiness-гейт, а не на размер surge.
Heads-up Recreate дал бы полный простой, а не частичный поток 502. Проблема в том, что трафик доходит до недозагруженных подов, что предотвращает readiness probe во время rolling update.
Heads-up maxUnavailable: 0 — безопасная настройка и не вызывает 502: она лишь означает, что ни один старый под не удаляется, пока его замена не готова. Ошибки идут от трафика в неготовые новые поды.
Викторина
Completed
Команда хочет строгий zero-downtime на Deployment из 4 реплик, который никогда не должен падать ниже полной ёмкости. Какая конфигурация rolling update верна и чего она стоит? ```yaml strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 ```
Heads-up Зависания нет — maxSurge: 1 сначала создаёт новый под, и только когда он готов, завершается старый. Эта пара — каноничная конфигурация zero-downtime; она просто катит по одному поду за раз.
Heads-up Knobs гарантируют, что ёмкость не проседает, но без реального readiness probe Kubernetes всё равно направляет трафик в поды в момент старта. Zero-downtime требует maxUnavailable: 0 И readiness probe, а не одни knobs.
Heads-up Дефолты 25% позволяют четверти ёмкости быть недоступной во время выката — это не zero-downtime. Быстрее не значит безопаснее: требование команды — никогда не падать ниже полной ёмкости.
Викторина
Completed
Вы используете blue-green и хотите, чтобы rollback оставался безопасным. Релиз green переименовывает колонку в БД. Что вы делаете?
Heads-up Приложение переключается атомарно, но база общая и не переключается. Переименование ломает blue относительно живой схемы, поэтому откат назад падает — мгновенный rollback исчезает ровно тогда, когда нужен.
Heads-up Восстановление медленное и теряет каждую запись, сделанную после переключения. Обратносовместимые изменения expand-contract сохраняют обе версии рабочими без разрушительного restore.
Heads-up Recreate меняет проблему миграции на гарантированный простой, а несовместимая вперёд схема всё равно блокирует rollback. Expand-contract решает реальное ограничение: схему, которую читают обе версии.
Викторина
Completed
Canary-деплой наращивает 5%, затем 25%, затем 50% без метрического gate — инженер на глаз смотрит дашборд и вручную промоутит на каждом шаге. В 3 часа ночи релиз с 4% ошибок доезжает до 100%. В чём настоящий провал?
Heads-up Меньший первый шаг уменьшает начальный blast radius, но всё равно доезжает до 100%, если метрики никто не читает. Недостающее звено — автоматический gate, а не размеры шагов.
Heads-up Blue-green открывает 100% трафика на переключении — больший blast radius. Canary здесь правильна; провалилось то, что у неё не было метрического gate — именно того, что делает canary менее рискованной.
Heads-up 4% ошибок на продакшен-сервисе обычно сильно за SLO — именно это и должен ловить gate. Смысл canary в том, что решает о промоушене gate, а не уставший человек.
Викторина
Completed
Нужно выбрать выкат для сервиса, где две версии действительно не могут сосуществовать — in-place изменение stateful-синглтона без совместимой промежуточной схемы. Ёмкость в обрез, короткое окно обслуживания допустимо. Какая стратегия и какой компромисс вы принимаете?
Heads-up Rolling update держит обе версии живыми одновременно — именно то, чего этот ворклоад не терпит. Дефолт не универсален; ограничение по несосуществованию его исключает.
Heads-up Canary тоже держит обе версии разом, чтобы обслуживать разделённый трафик, нарушая ограничение по несосуществованию. Выгода blast radius неуместна, когда смешанные версии портят состояние.
Heads-up Во время cutover существуют оба окружения, а blue-green удваивает стоимость ресурсов, что исключает ограниченная ёмкость; expand-contract не поможет, когда совместимой промежуточной схемы нет. Чистая замена версий у recreate подходит под ограничение.
Итог
Сквозная линия — одно решение: взвесить blast radius (canary минимальный, recreate тотальный) против стоимости ресурсов (blue-green удваивает) против скорости rollback (blue-green и canary почти мгновенны, rolling катится назад, recreate — второй простой). Затем предпосылки, которые делают любой выбор реальным: maxSurge/maxUnavailable плюс readiness probe для zero-downtime rolling, автоматический метрический gate для canary и миграции expand-contract, чтобы rollback пережил изменение схемы. Observability решает, какой стратегии вы реально можете доверять.