Rolling Update: что ломается при выкате новой версии
Самая частая поломка при выкате новой версии — замена всех экземпляров сервиса одной волной. Пока старые процессы гасятся, а новые поднимаются, часть запросов уходит в никуда: соединения обрываются на середине транзакции, проверки готовности не успевают прогреться, и доля ответов с ошибкой подскакивает ровно у активных пользователей — тех, кто прямо сейчас платит или оформляет заказ. Недоступность сервиса длится минуты, но в пиковые часы это самая дорогая минута суток.
Вторая, более неприятная проблема — гонка версий схемы данных. Если миграция базы проходит до выката кода, старые экземпляры ещё живут и не знают о новом поле или переименованной колонке; если после — новый код уже читает то, чего нет. Неудачный релиз в этот момент перестаёт быть одним событием: ошибки приходят из двух версий сразу, и по журналам не видно, кто именно виноват.
Ручной откат версии под нагрузкой усугубляет всё. Инженер поднимает предыдущий образ, но схема данных уже уехала вперёд, и старый код на неё не встаёт: восстановление растягивается с минут на часы, а трафик всё это время идёт на деградирующий контур.
Разбираем, как это закрывается: волны по одной реплике с прогревом и удержанием соединений, обратимые миграции в два совместимых поколения схемы и автоматический откат по метрикам вместо ручного вмешательства.
Эффект управляемого выката: что меняется в цифрах
Измеримые результаты появляются там, где выкат описан формальными параметрами: сколько экземпляров поднимается параллельно, через какие проверки готовности проходит новый экземпляр и по какому условию старый выводится из балансировки. В оркестраторе вроде Kubernetes это задаётся декларативно, поэтому состояние до и после внедрения сравнивается по одним и тем же метрикам, а не по ощущениям дежурной смены.
Чек-лист того, что проверяем и что фиксируем в отчёте:
- Окно недоступности. До — от нескольких минут до получаса на релиз, часть трафика получает ошибки. После — ноль: новый экземпляр принимает трафик только после успешной проверки готовности, старый снимается с балансировки последним.
- Сокращение окна релиза. Замена идёт порциями, поэтому выкат перестаёт быть остановкой работ: сборка и проверки идут параллельно замене экземпляров.
- Доля неудачных релизов. Раньше — по факту падения прода, теперь — по числу экземпляров, не прошедших проверку готовности. Такие релизы останавливаются автоматически, не доходя до всей группы.
- Откат за один шаг. Возврат к рабочей версии — переключение на предыдущий набор экземпляров, а не повторная сборка и ручной разбор. Время возврата измеряется десятками секунд.
- Устранённый класс отказов. Корректное завершение процессов с паузой больше самого длинного запроса убирает обрывы длинных соединений и всплески ошибок шлюза на старте.
- Нагрузка на дежурного. Ручные действия при выкате сводятся к запуску и наблюдению: прогресс, доля заменённых экземпляров и причина остановки видны в одном месте.
Все шесть пунктов замеряются до и после на одинаковом профиле нагрузки — иначе сравнение ничего не доказывает. Опишите вашу задачу: вернёмся с оценкой, планом замера и конфигурацией под ваш контур.
Сравнение подходов: Rolling Update и альтернативы
Стратегии выката различаются тем, сколько версий одновременно обслуживают трафик и насколько быстрым получается возврат назад. Ниже — четыре рабочих варианта и их честные ограничения: они определяют, нужен ли резерв мощности под второй контур, готовы ли внешние потребители к двум адресам сервиса и умеет ли команда гасить несовместимые изменения схемы данных.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Полный перезапуск | Внутренние сервисы, ночное окно обслуживания, короткий простой допустим | Простой на время старта всех реплик; откат — повторный запуск прошлого образа; переключение без плавности |
| Rolling Update | Длительно живущие сервисы без состояния на узле, несколько реплик за балансировщиком, выкат без простоя | Две версии работают одновременно: ломается на несовместимых изменениях API и схемы; откат — обратный проход по репликам; при запрете недоступных реплик нужен запас мощности |
| Канареечный выкат | Нужно проверить версию на 1–5% трафика, есть метрики и маршрутизация по весам | Требует управляемого балансировщика и наблюдаемости; выкат растянут во времени; две версии соседствуют дольше |
| Сине-зелёный выкат | Критичный сервис, нужен откат переключением трафика за секунды | Двойной расход ресурсов на время выката; требуется прогрев нового контура; сложнее с состоянием, очередями и миграциями |
Как выбрать под свой контур
Если внешние потребители не готовы к двум адресам сервиса и нет метрик в разрезе версий, выбор сужается до полного перезапуска или Rolling Update. Порядок работ здесь всегда один: сначала наблюдаемость и обратная совместимость схемы, потом стратегия — иначе откат превращается в угадывание.
Как мы внедряем стратегию: этапы инженерных работ
Порядок работ одинаков и для одного сервиса, и для платформы с десятками компонентов — отличается только объём. Цель одна: обновление не должно быть заметно ни пользователю, ни дежурной смене. Идём от аудита инфраструктуры до передачи в эксплуатацию.
Этапы внедрения
- Аудит инфраструктуры. Считаем реплики и их разброс по узлам, проверяем пробы готовности и живучести, политику прерываний и то, как балансировщик выводит узел из ротации.
- Схема выката. Определяем, сколько новых реплик поднимается одновременно и какая просадка доступности допустима (maxSurge и maxUnavailable), как чередуются версии в сервисе.
- Настройка параметров. Правим пробы, время ожидания остановки, обработчик preStop и повторы запросов у клиентов — иначе остановленная реплика рвёт соединения прямо во время выката.
- Проверка на нагрузке. На стенде с профилем боевого трафика гоняем выкат и откат: доля ошибок, время ответа на редких медленных запросах, сколько занимает возврат к прошлой версии.
- Документирование. Регламент выката и отката, критерии остановки при росте ошибок, что смотреть в первую очередь.
- Передача в эксплуатацию. Отдаём дежурной смене метрики и алерты на застрявший выкат, проговариваем порядок действий и границу, за которой зовут нас.
Критерий приёмки — выкат под рабочей нагрузкой без роста ошибок; если условие не выполнено, возвращаемся к параметрам и повторяем проверку.
Конфигурации, схемы и регламенты релиза
Комплект артефактов после внедрения стратегии Rolling Update собираем так, чтобы следующий релиз ваша команда выпустила без нас. Всё версионируется рядом с кодом: конфигурации, схемы, регламенты и политики доступа — с историей правок и понятной точкой входа.
- Конфигурация окружений — манифесты постепенного выката: доля трафика на новую версию, сколько экземпляров обновляется разом, пауза между шагами, пороги готовности. Параметры разведены по средам разработки, предпродуктивной и продуктивной — стенд не повторяет продуктив вслепую.
- Схема выката — порядок шагов от сборки артефакта до полного перевода трафика, точки остановки автоматики и то, что видит пользователь в момент перехода.
- Регламент релиза — кто инициирует выпуск, кто подтверждает, какие проверки обязательны до старта, по какому сигналу объявляется откат.
- Порядок возврата — возврат на предыдущую версию одним действием, срок жизни прошлых артефактов в реестре и проверка, что откат работает не только в день релиза.
- Политики доступа — роли в кластере и реестре: кто меняет конфигурацию продуктивной среды, кто читает логи, кто подтверждает выпуск; люди и сервисные учётные записи разведены.
- Документация и наблюдаемость — описание окружений, переменных и секретов, схема сети, инструкции по типовым операциям, панели мониторинга и оповещения по доле ошибок и числу доступных экземпляров.
Каждый пункт передаём с коротким разбором: что настроено, почему выбран именно такой порог и как действовать, если поведение системы отклонилось от ожидаемого.
Кейс: как выкат версии перестал ронять сервис
Сервис с суточным пиком нагрузки: онлайн-заказы, десятки тысяч запросов в минуту, окно низкого трафика — только ночью. Выпуск версии шёл через остановку группы серверов: 4–6 минут недоступности на каждом релизе, а примерно каждый седьмой релиз откатывали вручную и почти всегда ночью.
Схему выпуска перестроили на rolling update в Kubernetes: инстансы заменяются партиями, maxSurge и maxUnavailable задают, сколько новых поднимать одновременно и сколько старых допустимо снять. Readiness-проба не пропускает трафик в прогревающийся инстанс, preStop-hook с задержкой даёт активным соединениям закрыться — на смене версии не теряется ни один запрос.
| Метрика | До | После |
|---|---|---|
| Время недоступности при выпуске | 4–6 минут | нет — трафик уходит на живые инстансы |
| Доля неудачных релизов | около 14% | 2% |
| Возврат к рабочей версии | 25–40 минут вручную | одна команда, меньше минуты |
| Окно выпуска | только ночью | любой момент, включая пик |
Контроль остался у дежурного инженера, но решение принимает автоматика: при росте доли ошибок выкат останавливается сам и возвращает предыдущий набор образов, не дожидаясь деградации сервиса. Бюджет ошибок на релиз задан заранее — исчерпали, выкат заблокирован до разбора причин.
В результате выпуск перестал быть событием с дежурством по ночам: версии выходят в рабочее время, откат занимает меньше минуты, а доля неудачных релизов упала в семь раз на том же объёме трафика.
Что делать, если сервис уже работает в кластере?
Работающий кластер нельзя просто «переключить» на поэтапную замену: старый и новый экземпляры какое-то время обслуживают трафик одновременно. Поэтому первым делом проверяем, переживёт ли сервис параллельную работу двух версий — по коду, по данным и по фоновым задачам. Без этой проверки переход без остановки превращается в лотерею.
Совместимость со схемой данных — главный ограничитель. Изменения разбиваем на волны: сначала добавляем поля и индексы, понятные старой версии, затем выпускаем код, читающий оба формата, и только следующей волной убираем старое. Разрушительные операции — переименование, сужение типа, удаление колонки — с выпуском кода в один шаг не совмещаются никогда.
Отдельно проверяем всё, что плохо делится на части: планировщики, кэши с собственным состоянием, длительные соединения. Фоновая задача, размноженная на несколько экземпляров, даёт двойной прогон, поэтому на время выпуска её оставляют в одной активной копии. Проверка готовности должна отражать реальную готовность, иначе трафик придёт на экземпляр, ещё не поднявший соединения.
Порядок перехода — от простого к связанному. Сначала слои без собственного состояния: обработчики запросов и прикладной API. Затем потребители очередей и рабочие процессы. Последними — компоненты с данными: базы, кэши, брокеры, которые обновляются поштучно с проверкой на каждом шаге.
Риски перехода сводятся к окну смешанных версий и отсутствию пути назад. Откат планируем заранее: пока новая версия не подтверждена, старая остаётся работоспособной и совместимой с новыми данными. Долю трафика на новую версию ограничиваем и растягиваем замену по времени, чтобы ошибки проявлялись на малой части кластера, а не на всей нагрузке.
Технические сомнения и ограничения подхода
Rolling Update выравнивает версию кода, но не состояние: пока новый под поднимается, старый принимает трафик, и соединение, живущее дольше вытеснения пода, обрывается на стороне пользователя. Лечится это не самой стратегией, а связкой — preStop-хук, задержка вывода из балансировщика, корректное завершение по сигналу. Без них плавность видна только на графике деплоя.
Схема данных ограничивает сильнее. Две версии кода работают одновременно, поэтому и старая, и новая должны переживать любую версию схемы: поля добавляются как необязательные, запись идёт в оба формата, удаление — только после вывода предыдущего релиза. Откат ломается ровно в тот момент, когда миграция убрала колонку: вернуть её без потери данных уже нельзя.
Инфраструктура задаёт верхнюю границу. Подъём нового пода требует запаса по процессору и памяти, иначе планировщик держит его в ожидании и обновление зависает на середине. Квоты окружения, дисковые тома, число адресов в балансировке — это предел, за которым подход не применяется без смены схемы развёртывания.
Пользователь попадёт на старую версию во время обновления?
Да, и это нормально, если версии совместимы по контракту интерфейсов и схеме данных. Задача не в том, чтобы исключить одновременную работу, а в том, чтобы сделать её безопасной: версионирование интерфейсов, обратная совместимость ответов, отсутствие общего изменяемого состояния в памяти. В Kubernetes это дополняется пробой готовности, чтобы трафик шёл только в под, реально способный отвечать.
Как откатываться, если миграция уже выполнена?
Безопасный возврат возможен только до необратимых изменений. Поэтому миграции делят на этапы: расширение схемы, перенос данных, переключение кода, удаление старого — на каждом шаге приложение остаётся работоспособным на предыдущей версии. Если удаление уже прошло, откат означает восстановление из резервной копии с потерей изменений за этот промежуток.
Обсудим задачу и вернёмся с планом выката
Чтобы оценка выката была предметной, а не «плюс-минус неделя», инженерам нужен доступ к реальной картине окружения: манифестам рабочей нагрузки, настройкам проб, параметрам обновления и схеме миграций. Чем меньше допущений на входе, тем точнее план работ и тем меньше сюрпризов в самом окне выката.
Что полезно прислать до обсуждения:
- текущие манифесты рабочей нагрузки и параметры сервиса, через который идёт внешний трафик;
- настройки проб: что считается живым процессом, что — готовым принимать запросы, какие таймауты и задержки старта;
- параметры rolling-обновления: сколько экземпляров можно поднять сверх нормы, сколько вывести из строя, сколько ждать готовности;
- как хранятся образы — есть ли неизменяемые теги, кто и на каком шаге помечает сборку;
- схема миграций базы и требование совместимости версий вперёд и назад;
- куда смотреть при деградации: метрики, логи, алерты, кто получает уведомление;
- ограничения по окну выката — рабочие часы, периоды заморозки, необходимость согласования;
- кто владеет решением об откате и по какому сигналу он запускается.
В ответ вернёмся с планом: разбивка выката по волнам и долям трафика, набор параметров конфигурации под ваш профиль нагрузки, готовые манифесты и правила ревизий, критерии стоп-сигнала с процедурой возврата на предыдущую версию и чек-лист для дежурного.
Опишите задачу и текущее окружение — вернёмся с оценкой и планом работ.
