В этом материале
Если Kubernetes постоянно убивает Pod во время нормальной долгой загрузки, проверьте startupProbe. Она даёт контейнеру отдельное окно старта, пока liveness и readiness ещё не выполняются. Увеличивать только initialDelaySeconds наугад менее полезно, чем измерить реальные стадии запуска.
Если Kubernetes постоянно убивает Pod во время нормальной долгой загрузки, проверьте startupProbe. Она даёт контейнеру отдельное окно старта, пока liveness и readiness ещё не выполняются. Увеличивать только initialDelaySeconds наугад менее полезно, чем измерить реальные стадии запуска.
Найдите причину каждого рестарта
Сохраните Pod events, lastState и журналы предыдущего контейнера. Отличите отказ probe от OOMKilled, завершения приложения и ошибки загрузки образа. Временная шкала должна содержать создание контейнера, начало подготовки, первое успешное состояние проверки и остановку. Если процесс сам выходит раньше проверки, startupProbe не устраняет первичную причину. Также убедитесь, что команда или адрес проверки соответствуют именно этому контейнеру, а не соседнему sidecar.
Рассчитайте окно старта
Для startupProbe произведение failureThreshold и periodSeconds задаёт ориентир допустимого времени неуспешных проверок с учётом конкретных параметров и реализации. После её успеха начинают действовать остальные probes. Readiness управляет пригодностью для Service traffic, liveness может инициировать перезапуск. Нельзя заменять одно другим только потому, что все проверки используют HTTP. Слишком тяжёлая проверка также способна создавать нагрузку и искажать измерение времени старта.
Используйте измеренный учебный пример
Представим, что нормальная подготовка занимает около 180 секунд в отдельном тесте. StartupProbe с periodSeconds 10 и failureThreshold 30 даёт номинальное окно 300 секунд. Это иллюстрация арифметики, а не рекомендованный timeout для любой модели. Проверьте несколько холодных запусков и запуск с доступными локальными артефактами: загрузка из сети и инициализация процесса могут давать разные распределения времени.
| Стадия | Подтверждение |
|---|---|
| Контейнер существует | Состояние runtime |
| Старт ещё продолжается | Журнал подготовки и startupProbe |
| Можно принимать трафик | Readiness по назначению приложения |
| Процесс завис после старта | Отдельная liveness проверка |
Измените только probe policy
Сохраните образ, ресурсы и входной набор, затем обновите Pod template с измеренным startup budget. Не повышайте одновременно лимиты памяти и параметры движка: так будет трудно понять причину улучшения. Для Kubernetes exec probe проверьте наличие команды в образе; для сетевой — адрес, порт и timeout. Если startupProbe никогда не проходит, возвращайтесь к состоянию приложения и зависимостей вместо бесконечного расширения окна ожидания.
Проверьте выход из режима старта
Убедитесь, что успешная startupProbe действительно передаёт контроль дальнейшим проверкам, а readiness не допускает неподготовленный процесс в поток. Затем отдельно воспроизведите зависание после нормального старта на тестовом приложении. Сохраните probe manifest, временную шкалу и события рестарта. Такой артефакт показывает обе стороны политики: достаточное ожидание штатной подготовки и обнаружение позднего сбоя. Он не является доказательством качества генерации или гарантией предельной задержки пользовательского ответа.
Времена старта записывайте отдельно для успешных и прерванных попыток. Постоянно убиваемый процесс не даёт измерить нормальную продолжительность подготовки, поэтому timeout нельзя корректно выбрать только по длительности неудачных рестартов.
Связанные разборы: vllm health ready; autoscaling gpu cold start.