Стратегия деплоя: что происходит после команды релиза

При деплое новой версии Kubernetes может одновременно обслуживать пользователей старым и новым приложением. Вопрос не в том, как заменить контейнеры, а в том, кто и когда получает трафик, что считается признаком готовности и можно ли остановить релиз до того, как ошибка затронет всех. Разберём механику на примере Kubernetes Deployment API, ориентируясь на Kubernetes 1.30; поведение конкретных расширений и контроллеров зависит от кластера.

Деплой — это управление состоянием, а не команда копирования

Вы описываете желаемое состояние: например, нужны три реплики приложения с новым образом. Deployment controller сравнивает его с текущим состоянием и создаёт или обновляет ReplicaSet — ресурс, который поддерживает заданное число Pod. Затем контроллер ReplicaSet добивается нужного количества Pod. Это происходит асинхронно: команда может завершиться, пока кластер ещё выполняет замену.

Поэтому результат релиза нельзя сводить к факту, что образ загружен или Pod создан. Нужно различать как минимум три события: контейнер запустился, приложение готово принимать запросы, новая версия действительно получает пользовательский трафик. Между ними могут пройти секунды или минуты, а на каждом переходе возможен сбой.

Готовность Pod проверяет readiness probe¹. Пока проверка не проходит, Pod не считается готовым для обычной маршрутизации через Service. Но готовность — не доказательство, что приложение корректно обрабатывает реальные запросы: проверка может быть слишком поверхностной, а зависимость, доступная при запуске, отказать позднее.

Стратегия деплоя задаёт не только скорость замены версий. Она определяет, сколько пользователей окажется под воздействием ошибки до того, как вы её заметите.

Что именно контролирует RollingUpdate

Для Deployment по умолчанию используют стратегию RollingUpdate: новые Pod поднимаются постепенно, старые удаляются по мере появления готовых новых. Параметры maxSurge и maxUnavailable задают границы процесса. Первый ограничивает, сколько дополнительных Pod может появиться сверх желаемого числа реплик; второй — сколько реплик можно временно оставить недоступными. Значения можно задавать числом или процентом.

Например, при трёх репликах настройка без дополнительного запаса может означать, что контроллер сначала освободит место, завершив старый Pod, и только затем запустит новый. Это экономит ресурсы, но может временно уменьшить запас доступности. Разрешённый surge ускоряет замену ценой дополнительной нагрузки на узлы и зависимости. Точные значения зависят от числа реплик и настроек Deployment; не переносите параметры одного сервиса на другой без проверки ёмкости.

RollingUpdate не переключает весь трафик в один атомарный момент. Пока обновление идёт, часть запросов может попадать на старую версию, часть — на новую. Если версии несовместимы по формату данных, API или очередям, успешное прохождение readiness probe не спасёт от функциональной ошибки.

Три стратегии — три профиля риска

В чистом Kubernetes Deployment управляет репликами, а не процентом пользовательского трафика. Для canary обычно нужен отдельный механизм маршрутизации — например, контроллер ingress или service mesh. Его возможности и конфигурация зависят от выбранного продукта, поэтому нельзя считать, что изменение числа реплик автоматически даст нужную долю запросов.

Как понять, что релиз безопасен

У Kubernetes есть состояние прогресса Deployment и ограничения на ожидание продвижения, но они не заменяют проверку качества приложения. Контроллер может успешно завершить rollout, если Pod стали готовыми, даже когда бизнес-операция возвращает неправильный результат. Система доставки должна сопоставлять состояние выкладки с сигналами приложения и, для canary, уметь остановить дальнейшее увеличение трафика.

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

• Ошибки запросов: доля ответов 5xx и прикладных ошибок, отдельно для старой и новой версий, если такую разбивку можно получить.
• Задержка: p95 или p99, а не только среднее. Среднее может скрыть ухудшение для небольшой, но важной части запросов.
• Нагрузка на зависимости: пул соединений, очередь, база данных и внешние API. Новая версия может пройти проверку готовности, но создать резкий всплеск запросов.
• Состояние выкладки: число доступных реплик, перезапуски контейнеров и события Kubernetes. Они помогают отделить проблему запуска от ошибки в пользовательском трафике.

Если сравниваете релизы, записывайте версию образа, время начала, объём трафика и изменения конфигурации. Иначе падение метрики легко приписать новой версии, хотя одновременно могла измениться нагрузка или зависимость.

Где стратегия ломается

Проверка готовности говорит не о том

Если probe проверяет только открытый порт, Pod может считаться готовым до загрузки модели, прогрева кеша или подключения к критичной зависимости. Если проверка, наоборот, требует доступности слишком большого числа внешних систем, временный сбой зависимости способен остановить выкладку всех экземпляров. Разделяйте условия запуска и условия приёма трафика и проверяйте, что именно означает успех каждой проверки.

Старый и новый код несовместимы

Во время rolling update обе версии могут одновременно читать и записывать данные. Изменение схемы базы «в один шаг» опасно, если старые Pod ещё работают или откат вернёт старый код. Безопаснее проектировать миграции так, чтобы переходный период выдерживали обе версии: сначала добавить совместимую структуру, затем переключить приложение, а удаление старого поля отложить до отдельного релиза.

Откат меняет образ, но не историю

Возврат ReplicaSet к прежней версии способен восстановить прежний код, но не отменяет записи в базу, отправленные сообщения и внешние побочные эффекты. Перед релизом определите, какие изменения обратимы, кто принимает решение об остановке и как действовать, если трафик уже прошёл через новую версию.

Запас ресурсов рассчитан только на обычную работу

Surge увеличивает число Pod на время выкладки. Если узлам не хватает CPU или памяти, новые экземпляры могут остаться в ожидании ресурсов, а замена затянется. Замеряйте не только обычную загрузку, но и пиковую потребность при обновлении. Для canary отдельно проверяйте, не создаёт ли дополнительный контур неприемлемую нагрузку на общую базу или очередь.

Что измерить до выбора

Универсального честного замера «какая стратегия быстрее» нет: результат зависит от размера образа, времени запуска, числа реплик, ресурсов кластера, readiness probe и нагрузки на зависимости. Для своего сервиса проведите тест на стенде, близком к продакшену. Зафиксируйте время от старта выкладки до готовности, длительность смешанной работы версий, число ошибок и максимальное потребление ресурсов. Повторите тест с ограничением ресурсов и отказом одной зависимости — именно там обнаруживаются слабые места.

Выбирайте rolling update, если версии совместимы в период сосуществования и важна экономия ресурсов. Blue-green подходит, когда нужен ясный момент переключения и хватает ёмкости на параллельные контуры. Canary имеет смысл, когда трафик можно надёжно дозировать, а метрики позволяют обнаружить регрессию до расширения аудитории. Если ни мониторинг, ни маршрутизация не готовы, canary останется названием процесса, а не ограничителем риска.

¹ Readiness probe — проверка Kubernetes, по результату которой система решает, готов ли контейнер принимать трафик. Она отличается от liveness probe: та помогает обнаружить контейнер, который перестал нормально работать, и может привести к его перезапуску.

Что делать дальше

Возьмите один сервис и опишите его релиз как последовательность состояний: новая версия создана, готова, получает трафик, признана успешной или остановлена. Затем проверьте три вещи: совместимость старой и новой версий, запас ресурсов для surge и метрики, по которым релиз остановится. Следующий практический шаг — испытать откат вместе с миграцией данных на тестовом окружении, а не только проверить, что Kubernetes вернул старый образ.