Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку.
👉 Разница:
LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует.
ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается.
⚙️ Частые ошибки:
- Делают одинаковый endpoint для обоих проб. В итоге под либо вечно рестартует, либо никогда не попадает в сервис.
- Ставят слишком жёсткие таймауты - приложение ещё грузит кэш, а kubelet уже думает «оно мёртвое».
- Забывают про
startupProbe - и получают вечный рестарт на тяжёлых приложениях (например, Java с долгим стартом).✅ Хорошая практика:
-
liveness → простой healthcheck (например, GET /ping).-
readiness → что-то посложнее (например, проверка подключения к БД).-
startupProbe → обязательно для всего, что стартует дольше пары секунд.Kubernetes умеет заботиться о твоих подах, но только если ты правильно объяснишь ему, что значит «жив» и «готов».
Подпишись 👉@devopslib