Пост🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?

🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу? Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s). Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская. Разберем две крайности и как делать правильно. ❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек) Вы проверяете только то, что процесс веб-сервера запущен и порт слушается. 🔘Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода. 🔘Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки. 🔘Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса. ❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек) Вы решили быть умными и в /health эндпоинт засунули проверку коннекта к Базе, Редису и S3. 🔘Сценарий: База данных немного приуныла (медленные запросы). 🔘Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать. 🔘Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself. ✅ Как делать правильно: Liveness vs Readiness В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент. 1. Liveness Probe (Я жив?) 🔘Цель: Понять, не завис ли процесс намертво. 🔘Действие при сбое: РЕСТАРТ контейнера. 🔘Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться. 2. Readiness Probe (Я готов работать?) 🔘Цель: Понять, можно ли пускать на меня трафик. 🔘Действие при сбое: УБРАТЬ из балансировки (не убивать!). 🔘Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров. 📝 Пример (K8s Manifest): livenessProbe: httpGet: path: /health/live # Максимально тупой ответ 200 OK port: 8080 initialDelaySeconds: 5 periodSeconds: 10 readinessProbe: httpGet: path: /health/ready # Проверка БД, очередей и т.д. port: 8080 initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 3 💡 Главный совет Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он Ready, или отдавать ошибку юзеру, оставаясь "живым". #k8s #devops #fails #stability #bestpractices Подпишись 👉@devopslib