Startup даёт завершить начальную подготовку и затем прекращает проверку до следующего запуска. Readiness продолжает отвечать за способность принимать запросы во время работы.
Контейнеры и оркестрация
Проверка запуска Kubernetes
Определение
Проверка запуска, или startup probe, — это периодический опрос контейнера, по успеху которого kubelet считает его начальную подготовку законченной. Пока она не прошла, readiness и liveness не выполняются, а после исчерпания отведённого числа попыток kubelet завершает контейнер и применяет политику перезапуска.
Также ищут: Kubernetes startup probe · проба запуска · startup health gate · Startup probe
Зачем это знать
Приложение может запускаться минуты и при этом требовать быстрого обнаружения зависания в работе. Startup разделяет эти сроки. Бюджет выбирают по измеренному холодному запуску, в том числе на запасном узле; бесконечное ожидание лишь маскирует неисправную поставку.
Связи из словаря
Карта понятия
Проверка запуска Kubernetes
Доказательная часть
Что подтверждено
При заданной 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.
- Испытайте и нормальный долгий запуск, и состояние, из которого запуск уже не завершится.
- Сравните полное время появления готовой замены с требованием к восстановлению сервиса.
Открытые основания
Первоисточники
- Configure Liveness, Readiness and Startup Probes
Открыт редактором 6 сентября 2026 года, заголовок и версия документа сверены. Пороги последовательных неудач, интервалы, таймауты и расчёт бюджета запуска.
- Pod Lifecycle
Описывает назначение узла, состояния Pod и контейнеров, перезапуски контейнеров и создание нового Pod с другим UID взамен прежнего.
Утверждения: 06