Как спроектировать probes
Вопрос
Как ты настроишь liveness, readiness и startup probe для типичного HTTP-сервиса с базой и кешем?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Liveness: лёгкий эндпоинт, проверяет только процесс (event loop отвечает), без зависимостей
Readiness: готовность принимать трафик, может учитывать критичные зависимости и прогрев
Startup: для медленного старта, `failureThreshold × periodSeconds` с запасом
Таймауты и пороги с запасом, чтобы GC-пауза не убивала под
При остановке readiness быстро становится false, плюс preStop пауза
Проверять поведение: что будет при падении базы, при перегрузке
Что могут спросить следом
- Почему liveness опаснее, чем её отсутствие?
- Должна ли readiness проверять базу?
Разбор
Делаю два эндпоинта. /healthz для liveness: отвечает, если процесс жив и обрабатывает запросы, никаких обращений к базе и соседям. Иначе падение базы приведёт к перезапуску всех подов, и проблема станет каскадной. /ready для readiness: под готов принимать трафик, то есть закончил прогрев, поднял пулы соединений. Учитывать ли базу, решаю по смыслу: если без неё сервис полностью бесполезен, можно, но тогда при падении базы все поды выйдут из балансировки, и клиенты получат ошибку от балансировщика, а не от сервиса, так что часто лучше оставить под в ротации и отдавать понятную ошибку. Если старт долгий, добавляю startupProbe, а не большой initialDelaySeconds. Таймауты не по 1 секунде, а с запасом, и failureThreshold 3 и больше, чтобы короткая пауза GC не убивала под. При остановке приложение сразу начинает отвечать неготовностью, а preStop даёт паузу на вывод из балансировки. И проверяю сценарии: отключаю базу на стенде и смотрю, что поды не перезапускаются.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.