# preStop съедает grace period: как распределить время завершения Pod

Диагностика: preStop съедает grace period: как распределить время завершения Pod. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-prestop-termination-budget/
Language: ru

preStop выполняется внутри общего terminationGracePeriodSeconds. Hook не получает отдельный неограниченный бюджет перед TERM. Если он занимает почти всё окно, основному процессу остаётся мало времени для завершения, и контейнер может дойти до принудительного KILL.

## Нарисуйте шкалу завершения

Сохраните момент deletionTimestamp и журналы начала/окончания hook. Затем отметьте получение сигнала приложением и фактический выход процесса. У Kubernetes есть дополнительные детали реализации и небольшой разовый extension для незавершённого hook, но его не следует использовать как штатный резерв. Рассчитывайте бюджет по явной конфигурации. Сетевая публикация terminating состояния идёт параллельно локальному завершению и не создаёт строгую последовательность всех событий для каждого клиента.


[Официальный источник 1](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/).

## Определите обязанности hook

preStop может синхронизировать локальное завершение, однако простая задержка sleep сама по себе не подтверждает, что весь путь трафика перестал выбирать Pod. Отделите прекращение новой работы, завершение уже принятой работы и освобождение ресурсов процесса. Каждому действию нужен наблюдаемый признак. Не помещайте в hook сетевую команду без собственного timeout: недоступная зависимость способна израсходовать весь grace period до отправки TERM основному приложению.


[Официальный источник 2](https://docs.docker.com/reference/cli/docker/container/run/).

## Разберите ограниченный пример

Представим grace period 40 секунд и hook, который обычно занимает 25 секунд. Для основного завершения остаётся примерно 15 секунд общего окна, а не ещё 40. Это арифметический пример, не измерение production поведения. Если в тесте обработчик TERM требует 20 секунд, конфигурация не соответствует замыслу. Исправление может уменьшить hook, перераспределить действия или увеличить общий бюджет при допустимых эксплуатационных последствиях.

| Отметка | Диагностический вопрос |
| --- | --- |
| Начало удаления | Когда начался общий отсчёт |
| Окончание preStop | Сколько бюджета уже потрачено |
| TERM обработан | Получил ли процесс команду завершиться |
| Фактический выход | Уложилось ли завершение в окно |

## Учтите дерево процессов

Если PID 1 — wrapper, проверьте доставку сигнала детям и reaping. Увеличение grace period не исправляет потерянный TERM. Для sidecar учитывайте документированный порядок завершения в используемой версии Kubernetes. Не полагайтесь на произвольный порядок остановки обычных контейнеров Pod. Действия записи финального состояния должны иметь доступный путь и ограниченное время; иначе даже правильная последовательность сигналов оставит процесс ждать недоступный файл или сервис.

## Проверьте штатное удаление

На тестовом workload повторите удаление во время простоя и работы, сохранив одну и ту же конфигурацию. Итоговый артефакт — таблица событий, границы времени каждого действия и ожидаемые exit conditions. Успех означает, что hook завершился, процесс получил сигнал и вышел по предусмотренному пути. Состояние объекта Terminating не подтверждает выполненный cleanup. Эти проверки касаются жизненного цикла Pod; договорённости о streaming API, повторной отправке запросов и расчёте usage требуют самостоятельного описания.

Проверьте доступность журналов после удаления Pod. Без внешнего сохранения финальных маркеров принудительное завершение может стереть различие между выполненным cleanup и остановкой процесса на середине обработки сигнала.

Связанные разборы: [gpu exit plan](/ru/journal/gpu-exit-plan/); [kubernetes gpu scheduling](/ru/journal/kubernetes-gpu-scheduling/).