Liveness probe настроена неправильно и вызывает каскадные перезапуски сервиса под нагрузкой — как это диагностировать и исправить?

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

Каскадные рестарты по liveness обычно возникают, когда проверка завязана на тот же ресурс (CPU, пул соединений), что и обработка обычных запросов: под нагрузкой приложение не успевает ответить на liveness-запрос вовремя, Kubernetes убивает под как "неживой", оставшийся трафик перераспределяется на другие поды, увеличивая их нагрузку и провоцируя тот же сбой по цепочке — решение в том, чтобы сделать liveness лёгкой и независимой от текущей нагрузки, в отличие от readiness, которая может быть строже.

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

liveness probe должна отвечать на вопрос "жив ли процесс и не завис ли он", а не "может ли сервис сейчас обработать дополнительный запрос" — если endpoint liveness выполняет тяжёлую проверку (запрос к базе данных, полный health-check всех зависимостей) и использует тот же thread pool, что и основная нагрузка, под высокой нагрузкой именно эта проверка первой не успевает уложиться в timeout, хотя процесс полностью работоспособен.

Пример кода

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

livenessProbe:
  httpGet: { path: /livez, port: 8080 }
  timeoutSeconds: 3
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /readyz, port: 8080 }
  timeoutSeconds: 2
  periodSeconds: 5
  failureThreshold: 2

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

• Практика. правильная практика — liveness проверяет минимальный внутренний признак жизни (например, что HTTP-сервер отвечает на простой запрос без обращения к внешним зависимостям), тогда как readiness может быть строже и учитывать зависимости, потому что провал readiness не убивает под, а лишь временно исключает его из трафика, что безопаснее при перегрузке. Также стоит увеличить timeoutSeconds/failureThreshold liveness с запасом относительно p99 задержки самого простого ответа под пиковой нагрузкой.

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

• Риски. использовать один и тот же "тяжёлый" health-check endpoint для liveness и readiness; ставить слишком агрессивный timeoutSeconds (например, 1 секунда) для liveness на сервисе, где GC-паузы или временные пики нагрузки регулярно превышают это значение; не смотреть на корреляцию между ростом нагрузки, ростом рестартов и падением readiness других подов при расследовании инцидента.