Startup даёт завершить начальную подготовку и затем прекращает проверку до следующего запуска. Readiness продолжает отвечать за способность принимать запросы во время работы.
Практический смысл
Почему это важно
Приложение может запускаться минуты и при этом требовать быстрого обнаружения зависания в работе. Startup разделяет эти сроки. Бюджет выбирают по измеренному холодному запуску, в том числе на запасном узле; бесконечное ожидание лишь маскирует неисправную поставку.
Доказательная часть
Что подтверждено
При заданной startup-проверке readiness и liveness этого контейнера не выполняются до её успеха. После исчерпания настроенного числа неудач kubelet завершает контейнер и применяет политику перезапуска.
Граница применимости: Startup probe Kubernetes и границы её действия на другие пробы контейнера.
Успех startup завершает начальную проверку, но не заменяет дальнейшую готовность или работоспособность. После запуска за эти задачи отвечают readiness и liveness, если они настроены.
Граница применимости: Разделение трёх типов проверок Kubernetes.
При failureThreshold=30 и periodSeconds=10 расчётный бюджет startup составляет около 300 секунд. Это ориентир настройки, а не точный момент завершения: фактическое время зависит также от задержек, таймаутов и выполнения проверок.
Граница применимости: Расчёт бюджета startup по документации Kubernetes; не обещание секундомера или времени восстановления сервиса.
Если startup-проверка успешна через 20 секунд при бюджете 300 секунд, она разблокирует readiness и liveness после успеха, не дожидаясь остатка бюджета. Долгий допустимый запуск не обязан замедлять проверки уже запущенного приложения.
Граница применимости: Startup с условным бюджетом; собственные интервалы и задержки readiness/liveness продолжают действовать.
Фиксированная начальная задержка liveness не подтверждает завершение запуска. Startup заканчивает ожидание по успешной проверке, поэтому переменное время подготовки не нужно подменять одним большим таймером.
Граница применимости: Начальная задержка и startup-проверка Kubernetes.
Startup относится к запуску контейнера, а не к каждой пользовательской операции. Перезапуск контейнера требует нового прохождения начальной проверки.
Граница применимости: Жизненный цикл startup-проверки контейнера Kubernetes.
Граница терминов
Не путать
Startup отделяет медленную подготовку от неисправности уже запущенного процесса. Пока startup не прошла, liveness не выполняется; после успеха работают её собственные настройки.
Перед спецификацией
Что проверить
- Измерьте холодный запуск на целевой платформе и на запасном узле.
- Выберите признак завершения подготовки самого приложения.
- Задайте ограниченный бюджет через период и число последовательных неудач.
- Учтите таймауты и начальные задержки при проверке фактического времени.
- После успеха startup проверьте включение readiness и liveness.
- Испытайте и нормальный долгий запуск, и состояние, из которого запуск уже не завершится.
- Сравните полное время появления готовой замены с требованием к восстановлению сервиса.
Открытые основания
Первоисточники
Liveness, Readiness, and Startup Probes
Kubernetes · Kubernetes current documentation
Разделяет проверки готовности, работоспособности и запуска. Объясняет их действия и риск каскадного отказа при неверной настройке.
Открыть первоисточникConfigure Liveness, Readiness and Startup Probes
Kubernetes · документация Kubernetes v1.37, страница открыта 6 сентября 2026 года
Открыт редактором 6 сентября 2026 года, заголовок и версия документа сверены. Пороги последовательных неудач, интервалы, таймауты и расчёт бюджета запуска.
Открыть первоисточникPod Lifecycle
Kubernetes · Kubernetes current documentation
Описывает назначение узла, состояния Pod и контейнеров, перезапуски контейнеров и создание нового Pod с другим UID взамен прежнего.
Открыть первоисточник