У нас есть одно развертывание, состоящее только из одного модуля (с сервисом и входом). Он использует контейнер Docker, который выполняет настраиваемый скрипт запуска в качестве своей команды.
Когда мы выпускаем новую версию, изображение извлекается, создается новый модуль и запускается этот сценарий. В этот момент новый модуль находится в состоянии «Работает», а старый модуль - в состоянии «Завершено», потому что количество желаемых модулей по-прежнему равно 1.
Однако суть нашей проблемы заключается в том, что выполнение этого сценария выполнения иногда может занять несколько минут. Он включает в себя некоторые миграции БД и другие вещи, которые нельзя выполнить во время сборки (например, поместить в Dockerfile). В результате наш новый модуль работает несколько минут, но не готов обслуживать запросы, что приводит к некоторому простою нашей службы.
У меня вопрос: есть ли способ «отложить» завершение работы более старого модуля, чтобы предотвратить это? Или отложить отметку нового модуля как «Выполняется»?
Я знаю, что идеальное решение - иметь более 1 модуля, но это (в настоящее время) невозможно, поскольку рассматриваемая служба не полностью не имеет состояния. Но даже если бы это было так, если бы у нас было, например, 3 модуля, все они перешли бы в состояние «Выполняется», фактически не завершая задачи, и снова вызывали некоторое (хотя и меньшее) время простоя.
Как мне решить такую проблему?
Я не уверен на 100%, можно ли отложить завершение работы модуля до тех пор, пока работа не будет завершена, но вы можете установить проверку, чтобы убедиться, что модуль полностью готов к работе. Есть два типа проверок живучести и готовности.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
живучесть - это когда у вас есть приложение, которое по какой-то причине просто перестает принимать трафик, и перезапуск может решить проблему.
Готовность - это то, что вы ищете, когда приложению может потребоваться немного времени для полной загрузки для приема трафика.
Идеальным решением было бы настроить проверку готовности и сделать приложение достаточно умным на какой-то конечной точке, например /
или /ready
вернуть 200
ответ, чтобы Kubernetes знал, что можно принимать трафик.