🛑 Не убивай меня сразу! Настраиваем Graceful Shutdown
Коллеги, бывало такое? Вы делаете
Проблема часто не в балансировщике, а в том, что ваше приложение не умеет "красиво уходить" (Graceful Shutdown).
Когда Kubernetes хочет остановить под, происходит следующий танец:
1. K8s посылает процессу сигнал SIGTERM.
2. K8s ждет
3. Если процесс еще жив -прилетает SIGKILL (выстрел в голову).
❌ Как делают новички
Приложение получает
🔘 Результат: Все запросы, которые обрабатывались в эту миллисекунду (транзакция в БД, загрузка файла), обрываются. Клиент получает ошибку.
✅ Как надо (Уровень Code)
Приложение должно перехватывать
Получив сигнал, оно должно:
1. Перестать принимать новые соединения.
2. Дождаться завершения текущих запросов.
3. Закрыть коннекты к БД/очередям.
4. Выйти (
💀 Скрытая проблема Kubernetes (Race Condition)
Даже если ваш код идеален, вы все равно можете словить 502.
Почему?
В тот момент, когда K8s посылает
Это асинхронный процесс. Может случиться так, что Ingress Controller все еще шлет трафик на под, а приложение уже получило SIGTERM и закрыло порт.
💊 Решение: "The Sleep Hack"
Как бы глупо это ни звучало, но best practice в мире K8s - это вставить небольшую паузу перед остановкой.
Мы используем
Что это дает?
1. K8s запускает хук:
2. Под помечается как
3. За эти 5 секунд Ingress/Service успевают обновить свои таблицы маршрутизации и перестают слать новый трафик на этот под.
4.
⚙️ Чек-лист для идеального деплоя:
1. В коде обработан
2. В K8s добавлен
3.
Уважайте своих пользователей, не сбрасывайте их сессии посередине оплаты! 😉
#k8s #devops #architecture #go #python #bestpractices
Подпишись 👉@devopslib
Коллеги, бывало такое? Вы делаете
kubectl rollout restart, Kubernetes обещает бесшовное обновление, но в момент переключения подов пару юзеров все равно ловят 502 Bad Gateway или обрывы соединений.Проблема часто не в балансировщике, а в том, что ваше приложение не умеет "красиво уходить" (Graceful Shutdown).
Когда Kubernetes хочет остановить под, происходит следующий танец:
1. K8s посылает процессу сигнал SIGTERM.
2. K8s ждет
terminationGracePeriodSeconds (по дефолту 30 сек).3. Если процесс еще жив -прилетает SIGKILL (выстрел в голову).
❌ Как делают новички
Приложение получает
SIGTERM и... мгновенно закрывается.✅ Как надо (Уровень Code)
Приложение должно перехватывать
SIGTERM.Получив сигнал, оно должно:
1. Перестать принимать новые соединения.
2. Дождаться завершения текущих запросов.
3. Закрыть коннекты к БД/очередям.
4. Выйти (
exit 0).💀 Скрытая проблема Kubernetes (Race Condition)
Даже если ваш код идеален, вы все равно можете словить 502.
Почему?
В тот момент, когда K8s посылает
SIGTERM, он параллельно начинает удалять IP пода из Endpoints (Service).Это асинхронный процесс. Может случиться так, что Ingress Controller все еще шлет трафик на под, а приложение уже получило SIGTERM и закрыло порт.
💊 Решение: "The Sleep Hack"
Как бы глупо это ни звучало, но best practice в мире K8s - это вставить небольшую паузу перед остановкой.
Мы используем
preStop хук. Он выполняется ДО отправки SIGTERM.
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 5"]
Что это дает?
1. K8s запускает хук:
sleep 5.2. Под помечается как
Terminating.3. За эти 5 секунд Ingress/Service успевают обновить свои таблицы маршрутизации и перестают слать новый трафик на этот под.
4.
sleep заканчивается -> летит SIGTERM -> приложение спокойно доделывает старые запросы -> Profit! 🚀⚙️ Чек-лист для идеального деплоя:
1. В коде обработан
SIGTERM.2. В K8s добавлен
preStop хук со слипом (5-10 сек).3.
terminationGracePeriodSeconds выставлен с запасом (напр. 60 сек, если у вас долгие запросы), чтобы SIGKILL не прилетел слишком рано.Уважайте своих пользователей, не сбрасывайте их сессии посередине оплаты! 😉
#k8s #devops #architecture #go #python #bestpractices
Подпишись 👉@devopslib
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤩1