В этом материале
Graceful shutdown требует согласования нескольких таймеров и слоёв. TERM и readiness сами по себе не гарантируют завершение каждого длинного ответа.
Перезапуск API-процесса удобен для обновления, но активные генерации могут занимать больше времени, чем обычный HTTP-запрос. Если сервер сразу прекратит работу, клиенты получат частичные ответы. Если он бесконечно ждёт завершения, rollout не закончится. Поэтому graceful termination — это ограниченный протокол: прекратить допуск новой работы, дать определённое время принятой, затем классифицировать оставшиеся исходы и освободить ресурсы.
Опишите временную последовательность
Kubernetes документирует termination flow, включая preStop, сигналы процессам, grace period и состояние endpoints. Эти этапы связаны, но не являются одной атомарной операцией приложения. Уходящий экземпляр должен перестать получать обычный новый поток и при этом обработать уже открытые соединения по выбранной политике.
Нарисуйте timeline с точками stop-admission, начало draining, последний допустимый момент завершения и принудительная остановка. Это проектные состояния вашего сервиса, а не названия обязательных событий OpenRouter. У каждого состояния нужен наблюдаемый признак, чтобы тест не зависел от предположения оператора.
Согласуйте таймеры приложения
Параметры vLLM serve описывают shutdown timeout выбранной реализации. Применимые значения и поведение проверяются для установленной версии. Нельзя считать, что одно имя настройки автоматически согласуется с grace period оркестратора и таймаутом балансировщика.
Если внутренний срок больше внешнего, процесс может быть остановлен раньше ожидаемого cleanup. Если меньше, приложение завершит активную работу до окончания доступного окна. Сохраните все таймеры в одной записи, отдельно обозначив, какой компонент владеет каждым решением и каким событием начинается отсчёт.
Проверьте уже принятые запросы
Запустите несколько коротких synthetic streams и один заранее ограниченный более долгий. Затем инициируйте штатное завершение тестового экземпляра. Для каждой операции сохраните момент принятия, последнее событие, terminal outcome и состояние клиента после закрытия. Общий HTTP success counter не показывает полноту отдельных ответов.
После начала draining отправьте новый тестовый запрос. Его судьба должна соответствовать объявленной политике допуска. Не требуйте универсального кода отказа от всех слоёв: балансировщик может выбрать другой экземпляр, а приложение — отклонить работу локально. В отчёте должна быть видна фактическая точка обработки.
Учтите транспортные соединения
RFC 9113 описывает HTTP/2 streams и механизмы завершения соединения. Одно соединение может обслуживать несколько операций, поэтому его закрытие не равно одному terminal outcome модели. При преобразовании протокола на прокси исследуйте отдельно downstream и upstream path.
Длинный ответ, который не уложился в grace window, требует ясной классификации. Он не становится успешно завершённым только потому, что сервер корректно обработал TERM. Сохраните причину остановки и последнюю подтверждённую границу, не выдавая частичный текст за полный результат.
Повторите путь восстановления
После запуска новой версии проверьте готовность модели и небольшой контрольный запрос. Такой шаг показывает полный цикл обновления: вывод старого экземпляра, появление нового и доступность выбранного интерфейса. Он не доказывает отсутствие любых сбоев и не заменяет отдельную проверку аварийного завершения.
Связанные темы — canary модели и резервная маршрутизация. Артефакт graceful termination содержит timeline, настройки и исходы запросов, позволяя оценивать конкретный rollout без универсального SLA или заявления о действующей production-инфраструктуре.