В чём разница между Liveness Probe и Readiness Probe в Kubernetes?

Liveness Probe и Readiness Probe в Kubernetes

• Механизмы Kubernetes для проверки состояния контейнеров
• Liveness Probe определяет, остаётся ли контейнер работоспособным и корректно ли выполняется его процесс
• Если Liveness завершается ошибкой, kubelet останавливает контейнер и создаёт его заново
• Readiness Probe показывает, способен ли контейнер в данный момент принимать входящий трафик
• При сбое Readiness контейнер временно убирается из сервисов и балансировщиков нагрузки
• Liveness предназначена для восстановления контейнеров, которые зависли или завершились с ошибкой
• Readiness не допускает отправку запросов к неготовым контейнерам и помогает корректно распределять трафик

Итог: Liveness — перезапуск; Readiness — маршрутизация трафика.

Подробный ответ

Основной ответ

Liveness Probe и Readiness Probe — два механизма Kubernetes для проверки состояния контейнеров, управления их жизненным циклом и определения готовности к обработке трафика. Liveness Probe устанавливает, жив ли контейнер и требуется ли его перезапуск, например если он "завис". Readiness Probe определяет, может ли контейнер принимать запросы: завершилась ли инициализация и функционирует ли приложение корректно.

Ключевые моменты

• С помощью Liveness Probe выявляют ситуации, когда контейнер "завис" или перешёл в некорректное состояние, например при мёртвомлоке. Если проверка не проходит, Kubernetes перезапускает под, восстанавливая работоспособность. Это повышает устойчивость сервисов.
• Результат Readiness Probe определяет, будет ли под включён в Service endpoints. При неудачной Readiness probe под временно исключается из балансировки трафика — например, пока приложение ещё загружается или выполняет настройку.
• На практике обе пробы часто применяют одновременно: Liveness обеспечивает автоисцеление, а Readiness — корректное распределение нагрузки. Если Readiness не настроена, под по умолчанию считается готовым всегда, из-за чего запросы могут завершаться ошибками.

Практический контекст

В рабочих проектах, включая микросервисы на Kubernetes 1.24+, нередко задают для Liveness probe HTTP GET /healthz, проверяющий "живость" приложения, а для Readiness probe используют тот же endpoint либо более подробную проверку ресурсов, например доступности БД. Такой подход помогает поддерживать высокий SLA и отказоустойчивость, сокращая простой и количество пользовательских ошибок.