Лучшие практики развертывания flask -api в производственном кластере Google kubernetes

Question

A flask -api (с использованием gunicorn) используется в качестве API вывода модели глубокого обучения. Этот конкретный c процесс вывода очень интенсивно использует процессор (пока не использует gpu).

Какова лучшая практика развертывания его в кластер kubernetes, основанный на следующих аспектах:

1. Должен ли я создавать несколько пакетов для обработки запросов с использованием одного работника-оружейника или меньше, чтобы разрешить работать с несколькими работниками? (объем памяти узла)

2. , поскольку google предоставляет доступ к вашему развертыванию как службе с помощью внешнего балансировщика нагрузки, нужен ли мне веб-сервер nginx в моем стеке flask -gunicorn?

3. создание нескольких идентичных модулей на одном и том же узле 1016 *, является ли это более интенсивным, чем обработка всех этих запросов с использованием многопоточности на одном модуле?

Answer 1

1. Чем меньше стручков, тем лучше, при условии, что вы остаетесь ниже «тысяч». В кластере проще разместить модуль, требующий 1 ЦП и 1 ГБ ОЗУ, 16 раз, чем класть один модуль, требующий 16 ЦП и 16 ГБ ОЗУ один раз. Обычно вам требуется несколько реплик для обеспечения избыточности, терпимости сбоя узла и для обновления без простоев в любом случае.

2. Если система Istio Ingress работает для вас, вам может не потребоваться отдельное Слой маршрутизации URL (Nginx) внутри вашего кластера. Если у вас все в порядке с прямым доступом к вашим серверам Gunicorn без какой-либо маршрутизации или фильтрации, прямое указание на них службы LoadBalancer - правильный выбор.

3. Запуск 16 копий из 1 приложения, как правило, потребуется больше памяти, чем 1 копия с 16 потоками; сколько еще зависит от приложения.

   В частности, если вы загружаете вашу модель в память, а сама модель имеет большой размер, но ваша многопоточная установка может совместно использовать одну ее копию, 1 большой модуль может использовать значительно меньше памяти, чем 16 маленьких стручков. Если модель COPY редактируется непосредственно в Docker образе и код приложения mmap() s, то вы, вероятно, сможете разделить память на уровне ядра.

   Если сама модель мала и большая часть памяти используется для обработки, она будет по-прежнему использовать «больше» памяти для нескольких модулей, но это будет просто стоимость вашей системы времени выполнения и службы HTTP; он не должен существенно изменять объем памяти, требуемый для каждого потока / задачи / модуля, если это не используется совместно.