Развертывание Python Flask Kubernetes с датчиком жизнеспособности

Question

Как мы можем развернуть приложение фляги в Kubernetes, у которого также есть probePath , чтобы проверить жизнеспособность приложения?

Большинство обучающих программ / примеров, на которые я натолкнулся, не берутпозаботьтесь об этом и просто запустите приложение с application.run () внутри образа докера.

Мне кажется, что проблема с этим подходом состоит в том, что если какой-либо запрос занимает слишком много времени для загрузки на модуль, и в это время URL-адрес probePath вызывается Kubernetes на модуле, он истекает.Kubernetes, следовательно, убьет стручок, предполагая, что это не отвечает.

Я что-то упустил?

Answer 1

Я нашел решение после некоторых исследований.

UWSGI может помочь в этом случае с более дешевым режимом.

Чтобы включить более дешевый режим, добавьте более дешевый параметр = N в файл конфигурации uWSGI, где N - минимальное количество работников uWSGI.может бежать.Более дешевое значение должно быть меньше, чем максимальное количество сконфигурированных рабочих (опция рабочих или процессов).

установить более дешевый алгоритм для использования, если не установлено, будет использоваться значение по умолчанию

дешевле-алгоритм = запасной

минимальное количество рабочих, которое нужно всегда держать

дешевле = 2

количество рабочих, которые должны появитьсяпри запуске

дешевле-начальное = 5

максимальное количество рабочих, которые могут быть порождены

рабочих = 10

сколько рабочих должно порождаться за раз

дешевле-шаг = 1

Эта конфигурация скажет uWSGI запустить до 10 рабочих под нагрузкой.Если приложение бездействует, uWSGI остановит работников, но при этом всегда будет работать хотя бы 2 из них.С более дешевым начальным значением вы можете контролировать, сколько рабочих должно появляться при запуске.Если ваша средняя нагрузка требует больше, чем минимальное количество работников, вы можете сразу же их запустить, а затем «удешевить» (убить), если нагрузка достаточно мала.Когда более дешевый алгоритм решит, что ему нужно больше работников, он создаст более дешевый шаг.Это полезно, если у вас большое максимальное количество рабочих - в случае внезапного скачка нагрузки в противном случае потребуется много времени, чтобы порождать достаточное количество рабочих один за другим.

Примечание: uWSGI уведомляет работникапрежде чем быть дешевым.Рабочий должен завершить работу до истечения времени ожидания (это настраивается с помощью параметра конфигурации worker-reload-mercy ).В противном случае UWSGI убивает работника.Убийство работника во время запроса на обслуживание может привести к ошибкам или частичным ответам клиента.

Для получения дополнительной информации см. Эту ссылку: https://uwsgi -docs.readthedocs.io / en / latest / Cheaper.html