Я полагаю, вы не полностью понимаете датчик готовности и живучести.
Датчик готовности
Датчики готовности разработаны, чтобы сообщить Kubernetes, когда ваше приложение готов служить траффи c. Kubernetes проверяет, прошел ли тест готовности, прежде чем служба отправит трафик c в модуль. Если проверка готовности начинает отказывать, Kubernetes прекращает посылать трафик c в модуль, пока он не пройдет.
Также согласно официальным Kubernetes документация .
В случае сбоя проверки готовности контроллер конечных точек удаляет IP-адрес модуля из конечных точек всех служб, соответствующих модулю. Состояние готовности по умолчанию до начальной задержки - Отказ. Если контейнер не обеспечивает проверку готовности, по умолчанию используется состояние «Успех».
Например, если вашему приложению требуется около 15 секунд, так как оно будет работать правильно, необходимо загрузить огромное количество данных, которые вы можете установить readinessProbe. Это полезно, когда вы масштабируете свое развертывание или вам нужно время, прежде чем Pod получит данные.
Для датчика готовности значение failureThreshold определяет, сколько раз датчик должен выйти из строя перед удалением модуля из списка конечных точек.
Датчик жизнеспособности
Датчики живучести сообщают Kubernetes, живо ли ваше приложение или нет. Если ваше приложение живо, то Kubernetes оставляет его в покое. Если ваше приложение мертво, Kubernetes удаляет модуль Pod и запускает новый для его замены.
Короче говоря, когда ваше приложение работает, Kubernetes проверяет периоды времени, когда он может получить доступ к некоторым общим ресурсам, если да, это возвращает успех. Если нет, он считает его неудачным и пытается снова, пока зонд не достигнет failureThreshold. После достижения этого значения pod будет перезапущен.
===
На основе документа docs .
readinessProbe, когда он будет успешным:
readiness-exec 0/1 Pending 0 0s
readiness-exec 0/1 Pending 0 0s
readiness-exec 0/1 ContainerCreating 0 0s
readiness-exec 0/1 Running 0 8s
readiness-exec 1/1 Running 0 15s
readiness-exec 0/1 Completed 0 98s
readinessProbe при сбое:
readiness-exec 0/1 Pending 0 0s
readiness-exec 0/1 Pending 0 0s
readiness-exec 0/1 ContainerCreating 0 0s
readiness-exec 0/1 Running 0 3s
readiness-exec 0/1 Completed 0 92s
Он не создаст модуль, так как readinessProbe не удалось. В описании модуля:
Warning Unhealthy 2s (x12 over 57s) kubelet, gke-default-pool-bc1968b0-1sh7 Readiness probe failed: cat: /tmp/healthyyyyy: No such file or directory
Относительно livenessProbe при достижении failureThreshold контейнер будет делать то, что было установлено в RestartPolicy .
Поскольку информация, генерируемая зондами, хранится в kubelet вы можете описать модуль для проверки текущего состояния. Если вы хотите получить более подробную информацию, вы должны использовать $ journalctl -u kubelet, как в , в этом случае .
. В Интернете вы можете найти много статей об этом. Например, статья в Google или статья в openshift .
Проверьте эту документацию с информацией при использовании зондов.
Если это не ответил, пожалуйста, отредактируйте ваш вопрос.