Graceful Shutdown в Python-приложениях на Kubernetes: внедрение и практический опыт

Вот важная новость с фронта ИИ: al3x_mart 44 минуты назад Graceful Shutdown в Python-приложениях на Kubernetes: внедрение и практический опыт 8 мин 1K Блог компании Selectel Python * Kubernetes * Программирование * DevOps * Часто ли вы сталкиваетесь с проблемой потери данных, неконсистентными состояниями или ошибками в Sentry о внезапно закрытых соединениях при рестарте сервисов? Если вы когда-нибудь пытались это исправить, то наверняка слышали про Graceful Shutdown. Меня зовут Антон, я бэкенд-разработчик Python в Selectel.

В этой статье поделюсь опытом внедрения Graceful Shutdown в наши сервисы и расскажу, с какими сложностями мы столкнулись. Что такое Graceful ShutdownДословно Graceful Shutdown переводится как «изящное выключение». Можем сделать логичный вывод, что это процесс корректного завершения работы приложения.

Технические детали

Когда процесс получает сигнал остановки, он последовательно выполняет следующие шаги:прекращает принимать новые запросы;ожидает завершения всех активных задач;закрывает соединения с базами данных, брокерами сообщений и другими внешними ресурсами;завершает свою работу. Благодаря этому активные запросы не обрываются на середине транзакции, а сообщения в брокере обрабатываются до конца. Спойлер: возможно, полностью исключить редкие сбои в распределенных системах и не выйдет, но такой подход поможет свести их количество к минимуму.

Основные понятияПеред тем как перейти к реализации, быстро пройдемся по ключевым терминам:In-flight запросы — активные запросы, которые начали обрабатываться до сигнала завершения и продолжают выполняться после его получения. Drain-период — временной интервал, в течение которого сервис перестает принимать новые запросы и завершает обработку всех in-flight-запросов. Grace-период — время, которое контейнеризатор (например, Docker) или оркестратор (в нашем случае — Kubernetes) выделяет на полное завершение работы сервиса до принудительной остановки.

Сигнал SIGTERM — сигнал, который отправляется для запуска сценария плавного завершения работы процесса. Сигнал SIGKILL — сигнал принудительной остановки процесса. Как это работаетРазберем, как на практике устроен процесс плавного завершения, какие тайминги мы используем и что произойдет, если сервис не уложится в отведенное время.

Отраслевые последствия

Идеальный сценарийВ штатном режиме процесс остановки выглядит так:Kubernetes отправляет поду сигнал SIGTERM. Приложение перехватывает сигнал и прекращает принимать новые запросы. Сервер завершает обработку in-flight запросов.

Закрываются все соединения с внешними ресурсами и базами данных. Приложение завершает работу. На втором шаге поведение API и воркеров различается.

В первом случае за остановку приема новых запросов будет отвечать WSGI-сервер. Для воркеров же реализовывать данную логику придется вручную, если используемая библиотека не поддерживает ее «из коробки». Что может пойти не такЕсли сервису не хватит drain- или grace-периода, события могут развиваться по двум сценариям.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.