Какую проблему решают liveness и readiness probe и чем они отличаются на базовом уровне?

Короткий ответ

Liveness probe проверяет, что процесс в контейнере жив и работоспособен — при провале Kubernetes перезапускает контейнер; readiness probe проверяет, готов ли контейнер принимать трафик — при провале под временно убирается из endpoints Service, но не перезапускается.

Как это работает подробнее

обе проверки выполняются kubelet на узле по расписанию (HTTP-запрос, TCP-соединение или команда внутри контейнера) и имеют независимые пороги успеха/неудачи. Liveness влияет на решение "перезапустить контейнер", readiness — на решение "включать ли под в балансировку трафика Service".

Пример кода

manifest.yamlКопировать

livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5

Что использовать на практике

• Практика. readiness особенно важна при старте приложения, которому нужно время на прогрев кэша или подключение к базе — без неё трафик пойдёт на под раньше, чем он реально готов отвечать. Liveness нужна для восстановления после зависаний (deadlock), когда процесс жив, но не отвечает.

Подводные камни

• Риски. использовать одну и ту же проверку для liveness и readiness без понимания разницы последствий; настраивать liveness слишком строго (короткий таймаут) для приложения с медленным стартом, что вызывает бесконечные перезапуски ещё до того, как приложение успело подняться — для этого случая нужен startup probe, рассматриваемый отдельно на уровне Middle.