27.01.2026 07:00
🚑 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
Подпишись 👉 @i_DevOps
Продолжаем тему стабильности. Сегодня про 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
Подпишись 👉 @i_DevOps