Comments 2
Какой же ужасный слог и перевод. Содержит критичные неточности.
Пробы запуска обычно рекомендуется применять с унаследованными приложениями, на запуск которых требуется немало времени. Как только приложение пройдёт пробы запуска, последующие пробы жизнеспособности и готовности не учитываются.
Что значит не учитываются?
Это пока приложение НЕ пройдет startup probe, остальные не учитываются. Специально для запуска долгозапускающихся приложений, чтобы они не были прибиты до полного старта.
В принципе для readiness/lieveness есть отдельная опция initialDelay. Но иногда удобно просто выяснить, что под запустился и неудобно пользоваться initialDelay с другими пробами. Или их вообще нет, поэтому добавили еще и startup пробу. После того как она один раз отработала, контейнер считается успешно запустившимся. Но она отрабатывает один раз и никак не отменяет другие пробы после этого.
Если нет никакой пробы, то как только контейнер создался и началось запускаться приложение, он считается успешно запустившийся, и на него уже может пойти трафик, хотя на самом деле приложение может крешнуться, недозагрузиться, или еще некоторое время быть не готовым для обработки запросов.
Если есть liveness или readiness, то контейнер считается удачно запустившимся, если хотя бы одна из них отработала успешно.
https://habr.com/ru/companies/vk/articles/530752/ на мой взгляд эта статья более полно отражает существующие в k8s проверки работоспособности сервисов. Ну про выводы... да эта целая проблема "правильное" применения проверок работоспособности.
Глубокие проверки работоспособности Kubernetes