Пост💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes.

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