Деплой без простоя: graceful shutdown как свойство флота

Каждый урок до сих пор был про то, как один процесс умирает хорошо. Но ты никогда не деплоишь один процесс — ты катишь флот. Rolling-деплой проходит по твоим репликам, заменяя каждый старый под новым, и видимое пользователю обещание — «ноль простоя»: ни один запрос не падает, ни один клиент не замечает, хотя каждый инстанс разбирается и пересобирается под ними. Вот неуютная часть: идеальное выключение каждого инстанса не даёт тебе этого обещания само по себе. У тебя может быть безупречный SIGTERM-обработчик, верная readiness, чистый дренаж, идемпотентные возвраты — и всё равно простой на деплое, потому что координация между инстансами неверна. Снеси старый под до того, как его замена готова, — и ты сжал мощность посреди деплоя. Снеси слишком много сразу — и ты в брауноуте. Дай балансировщику держать устаревший маршрут несколько секунд — и ты отвергаешь соединения. Пошли каждому клиенту Connection: close в один миг — и они все переподключатся одним синхронизированным громовым всплеском, что повалит те самые поды, что ты только поднял. Деплой без простоя — не сумма хороших выключений; это свойство того, как выключения скоординированы по флоту. Это капстоун юнита: всё, что ты выучил, поднятое с одного процесса до многих.

Мощность не должна проседать: новый готов до дренажа старого

Первый инвариант уровня флота — что общая обслуживающая мощность никогда не падает ниже спроса во время раската. Rolling-деплой управляется двумя ручками (Kubernetes называет их maxUnavailable и maxSurge, но концепт универсален): сколько старых подов может быть недоступно сразу и сколько лишних новых подов можно поднять сверх желаемого числа. Безопасный паттерн — сёрджи вверх, затем дренируй: доведи новый под полностью до ready — прохождение readiness-пробы, прогрет, подключён к хранилищам — до того, как начнёшь дренировать старый, что он заменяет. Если перевернуть это, завершая старый под до того, как новый обслуживает, у тебя есть окно, где флот на один инстанс короче, и под устойчивой нагрузкой эта недостающая мощность — потерянные или поставленные в очередь запросы. maxUnavailable: 0 с положительным maxSurge кодирует «никогда не падать ниже полной мощности»; это медленнее и стоит временных лишних инстансов, но это та настройка, что реально даёт ноль простоя под нагрузкой.

Дерегистрируй до завершения, размеряй по реальному распространению

Это гонка дерегистрации из урока три, но теперь как дисциплина флота. Каждый старый под должен быть убран из ротации балансировщика до того, как перестанет принимать — и поскольку дерегистрация в конечном счёте согласована, ты должен переждать распространение до закрытия слушателя. На масштабе флота числа становятся конкретными и большими. Задержка дерегистрации (таймаут дренажа соединений) типичного облачного балансировщика по умолчанию 30–60 секунд; для сервисов с долгоживущими соединениями или большими загрузками команды толкают её до 600 секунд или больше. Правило размера, что выживает в контакте с продом: ставь окно дренажа примерно в 3× твоей p99-длительности запроса, чтобы все, кроме самых патологических, запросы в полёте завершились, затем зажми его страховочным таймаутом. Ошибись в этом по сотне подов — и каждый деплой сбрасывает тонкий, коррелированный слой 502 — невидимый в одном запросе, кричащий в агрегированном проценте ошибок.

Громовое переподключение: джиттери закрытие

Последняя ловушка — та, что показывает только флот. Когда ты дренируешь, ты шлёшь Connection: close, чтобы клиенты переподключились к здоровым инстансам — верно. Но если каждый под закрывает свои keep-alive соединения в один миг, каждый клиент переподключается в один миг, и флот из тысяч клиентов приземляется одним синхронизированным громовым переподключением на выжившие (и только запущенные, холодные) поды — самоинфликтное громовое стадо, ровно тот режим отказа, что юниты про circuit breaker и идемпотентность кружили снова и снова. Фикс — тот же, что использовали те юниты: джиттер. Размажь закрытие соединений по рандомизированному окну вместо одного мига, чтобы переподключения смазались по времени, а не всплеснули. В сочетании с сёрдж-мощностью и правильно размеренной дерегистрацией джиттеренное закрытие — то, что превращает «каждый инстанс выключился корректно» в «флот ни разу не икнул». Ноль простоя — это graceful shutdown плюс координация: мощность, порядок и размазывание.