Что такое readiness probe и liveness probe

Readiness probe и liveness probe — это встроенные проверки Kubernetes, которые позволяет kubelet проверять состояние контейнера и принимать решения: отдавать ли контейнеру трафик и нужно ли перезапускать контейнер.

Readiness probe

• Отвечает на вопрос «готов ли контейнер принимать трафик».

• Если проверка провалена, Pod удаляется из Endpoints объекта Service (трафик больше не направляется на этот контейнер), но сам контейнер остаётся запущенным.

• Полезна для graceful-вывода из нагрузки при старте/перезагрузке/временных проблем (например, подключение к БД ещё не установлено).

Liveness probe

• Отвечает на вопрос «жив ли контейнер, не завис ли он».

• При последовательных неудачах kubelet убьёт контейнер и попытается перезапустить его в соответствии с restartPolicy Pod-а.

• Используют для автоматического восстановления при deadlock’ах, утечках памяти, зависаниях main-процесса.

Типы проверок (в pod.spec.containers[].livenessProbe|readinessProbe):

• httpGet — HTTP GET на указанный путь/порт; ожидается код 200–399.

• tcpSocket — попытка установить TCP-соединение на порт; успешна если соединение установлено.

• exec — выполнение команды внутри контейнера; успешна если код возврата 0.

Основные параметры:

• initialDelaySeconds — задержка перед первой проверкой после старта контейнера.

• periodSeconds — интервал между проверками.

• timeoutSeconds — время ожидания ответа (если превышено — считаем провалом).

• failureThreshold — число последовательных неудач до срабатывания (для liveness — перезапуск, для readiness — снятие из Endpoints).

• successThreshold — число последовательных успехов для перехода из «неготов» в «готов» (обычно для readiness).

Взаимодействие со startupProbe:

• startupProbe— отдельная проверка, используемая при очень долгом старте приложения. Если указан startupProbe, kubelet использует её пока приложение не стартанёт; только после успеха включаются liveness/readiness. Это предотвращает преждевременные рестарты.

Примеры (упрощённо):

HTTP-проверки:

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2

Exec-проверка:

readinessProbe:
exec:
command: \["cat", "/tmp/ready"\]
initialDelaySeconds: 5
periodSeconds: 5

Рекомендации по настройке:

• Для web-сервисов делайте отдельные endpoints /live и /ready с минимальной логикой в /live (проверяет, что процесс отвечает) и более строгой в /ready (зависимости, инициализация).

• Увеличьте initialDelaySeconds и failureThreshold, если приложение требует времени на старт.

• exec-проверки полезны для специфичных внутренних проверок, но обходятся дороже по ресурсам.

• Не делайте проверки слишком частыми или «тяжёлыми» — они добавляют нагрузку.

Диагностика:

• kubectl get pods — столбец READY показывает число готовых контейнеров.

• kubectl describe pod <pod> — в событиях увидите Readiness probe failed / Liveness probe failed и причины.

• Повторяющиеся рестарты после провала liveness обычно приводят к CrashLoopBackOff.

• Readiness влияет на Endpoints: kubectl get endpoints <svc> покажет, попал ли Pod в список.

Особенности:

• Пробы определяются на уровне контейнера (в одном Pod разные контейнеры могут иметь свои probes).

• Liveness триггерит перезапуск и подчиняется restartPolicy Pod-а — в некоторых типах Pod (Jobs с restartPolicy: Never) поведение может отличаться.

• Readiness не трогает жизненный цикл контейнера — это только маршрутизация трафика.