Как настроить readiness/liveness пробы так, чтобы они не создавали ложные алерты при нормальных событиях (например, при деплое или временной нагрузке на зависимость)?

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

Нужно разделять liveness (лёгкая проверка "процесс жив", без внешних зависимостей) и readiness (может включать проверку готовности обслуживать трафик, включая зависимости, но с корректными таймаутами); для избежания ложных срабатываний при деплое использовать startupProbe с увеличенным временем на инициализацию и разумные initialDelaySeconds/periodSeconds/failureThreshold.

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

startupProbe даёт приложению время на "холодный старт" (прогрев кэша, подключение к БД) без того, чтобы liveness probe считала его неработающим и перезапускала контейнер раньше времени; после успешного прохождения startupProbe включаются обычные liveness/readiness проверки. Readiness probe, в отличие от liveness, не перезапускает контейнер при неудаче, а только временно выводит под из балансировки трафика (из Service endpoints), что безопаснее для временных проблем с зависимостью.

Пример кода

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

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

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

• Практика. liveness probe должна проверять минимум — что процесс отвечает и не "подвис" (deadlock), и не должна зависеть от внешних систем, иначе временная недоступность БД вызовет массовый перезапуск здоровых подов. Readiness может быть строже и учитывать реальную готовность (например, прогрета ли локальная кэш-структура), так как её провал просто временно исключает под из трафика без разрушительного перезапуска.
• Практика. startupProbe даёт до 60 секунд (30 × 2с) на инициализацию прежде, чем включится liveness; после старта временная недоступность зависимости приведёт к провалу /ready и выводу пода из Service, но не к перезапуску контейнера — это можно проверить, временно заблокировав доступ к БД и наблюдая kubectl get endpoints без роста RESTARTS в kubectl get pods.

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

• Частые ошибки. использовать одну и ту же проверку для liveness и readiness, из-за чего временная проблема с зависимостью приводит не просто к выводу из балансировки, а к каскадному перезапуску всех подов одновременно; не настраивать startupProbe для приложений с долгим стартом, из-за чего liveness probe убивает контейнер ещё во время нормальной инициализации; ставить слишком агрессивный failureThreshold/periodSeconds, из-за чего единичный медленный ответ (GC pause, кратковременный пик нагрузки) считается сбоем.