#kubernetes #multiprocessing #gunicorn #python-multiprocessing
#kubernetes #многопроцессорность #gunicorn #python-многопроцессорность
Вопрос:
При машинно-ориентированном развертывании обычно люди используют gunicorn для развертывания нескольких рабочих элементов для обслуживания входящих запросов. (да, worker_class будет дополнительно определять поведение в рабочем процессе)
При развертывании в кластере Kubernetes мы все еще gunicorn (или, если быть точным, нам все еще нужно многопроцессорное развертывание)?
По сути, каждый запущенный контейнер представляет собой процесс (в конфигурации «один контейнер на модуль»). Несколько модулей, запущенных за сервисом, уже эквивалентны тому, что gunicorn может предложить. Другими словами, полагайтесь на службу Kubernetes вместо gunicorn
gunicorn Все еще нужен?
Да, модуль — это не совсем то же самое, что процесс (некоторые накладные расходы в каждом модуле для сопутствующего контейнера), но кроме этого, что-нибудь еще, что мы можем упустить из-за отсутствия gunicorn ?
Отредактировано
Уточнение: да, все еще нужен gunicorn или другой wsgi http сервер для запуска приложения python. Мой вопрос действительно касается multiprocess аспекта (как multiprocess / gunicor в названии).
Комментарии:
1. Я не думаю, что пока существует лучшая практика (и многое из того, что люди говорят, продиктовано старыми привычками). Как ни странно, при развертывании gunicorn в Kubernetes было трудно выявить проблемы с памятью. ООМ-убийца уничтожает дочерние процессы gunicorn в модуле, что означает, что модуль фактически никогда не умирает, если у него заканчивается память. Главный процесс просто перезапускает дочерний. Это проблема, потому что ничего не регистрируется. Кроме того, управление процессами в gunicorn расходится с Kubernetes, у которого есть собственные проверки работоспособности.
2. Я пришел сюда, задаваясь вопросом, достаточно ли uvicorn в настройке kubernetes без необходимости диспетчера процессов, как описано на uvicorn.org/deployment/#using-a-process-manager .
3. @Risadinha Это именно то, для чего нужен мой OP. Таким образом, все масштабирование вверх / вниз, перезапуски, проверки готовности / жизнеспособности, ssl уже выполняются k8s. в настоящее время мы запускаем gunicorn с 1 сотрудником uvicorn. Позже gunicorn может полностью удалиться
Ответ №1:
Gunicorn используется для обслуживания приложений WSGI (Web Server Gateway Interface), так что это сервер, а не просто инструмент для многопроцессорной оркестровки. Kubernetes под рукой — это инструмент оркестровки, который помогает управлять инфраструктурой. Он не использует HTTP и ничего не знает о спецификациях WSGI. Другими словами, вы не можете запускать приложения WSGI на простых модулях kubernetes, вам все равно понадобится сервер WSGI, подобный Gunicorn, uWSGI и т.д., Для обслуживания приложения.
Комментарии:
1. привет, @Ken4scholars, спасибо за комментарий. Я отредактировал свой вопрос, чтобы прояснить вопрос.
2. @MartinNowosad
python manage.py runserverзапускает сервер разработки Django, в который встроен сервер WSGI. Итак, у вас все еще есть сервер WSGI. В рабочей среде этот сервер не используется, поскольку он не готов к работе и ему не хватает многих функций, необходимых в производственной среде. Вот почему в рабочей среде вы используете Gunicorn / uWSGI или другие готовые к работе серверы WSGI. Вы не можете просто запустить модуль k8s, поскольку он не сможет взаимодействовать с вашим приложением Django или использовать HTTP. Конечно, вы можете запускать k8s поверх сервера разработки, но это категорически не рекомендуется по вышеуказанным причинам.3. @MartinNowosad прочитайте мой пост еще раз и мои комментарии — вы не можете заменить gunicorn на k8s без сервера WSGI. Сервер разработки, на который вы постоянно ссылаетесь, также является сервером WSGI. Я специально упомянул Gunicorn, потому что это было в сообщении, но я также сказал, что без сервера WSGI. Может быть, попробуйте прочитать сообщение еще раз. Я не вижу смысла продолжать этот разговор, так что это мой последний комментарий. Хорошего дня
Ответ №2:
Все еще нужен gunicorn?
На самом деле это не нужно. Kubernetes может обрабатывать масштабирование вверх и вниз (модули / контейнеры) так же, как это делает gunicorn, используя, например, HPA или VPA, в сочетании с другими функциями, такими как автоматическое масштабирование кластера.
Тот факт, что вам это не нужно, это не нужно, вы не можете использовать gunicorn. Вы вполне можете иметь несколько процессов в модуле / контейнере, управляемом с помощью ограничений ресурсов. Имейте в виду, что диспетчер ресурсов Kubernetes в конечном итоге будет определять, какими будут запрашиваемые и верхняя граница ресурса для ваших контейнеров (работающих в pod).
Комментарии:
1. Я не понимаю, я думал, вам нужен gunicorn для обслуживания приложения, без него как работает приложение flask? Как выглядит приложение flask? Похоже ли это на базовые приложения для разработки, которые мы видим онлайн (hello world)? Также, если мы включим gunicorn, мы просто установим для рабочих процессов значение 1?
2. Вы можете выбрать подход, подобный hello world, без gunicorn или gunicorn с 1 процессом, оба работают. Я просто не вижу преимуществ gunicorn, если только один процесс не работает быстрее, чем подход hello world
3. НЕ ИСПОЛЬЗУЙТЕ RUNSERVER В ПРОИЗВОДСТВЕННЫХ УСЛОВИЯХ. Он не проходил аудит безопасности или тесты производительности. (И так оно и останется. Мы занимаемся созданием веб-фреймворков, а не веб-серверов, поэтому улучшение этого сервера для работы с производственной средой выходит за рамки Django.) Смотрите: forum.djangoproject.com/t/which-http-server-for-k8s-gunicorn /…
Ответ №3:
Это действительно зависит от ваших вариантов использования. Здесь нет правильного при неправильном, если одно решение подходит вам лучше, чем другое.
У нас похожий вариант использования. Мы запускаем около 30 копий одного и того же сервиса. Каждый модуль запускает 1 контейнер, который снова запускает 50 дублирующих сервисов.
В итоге мы могли бы иметь 1500 модулей, работающих с одной службой, но мы проверили, что производительность по сравнению с требуемыми ресурсами была намного выше при запуске только 30 реплик, что позволяет запускать 50 служб на реплику.
Единственное, что мы делаем дополнительно, это отслеживаем эти 50 служб на модуль, поэтому, если одна из них останавливается, она перезапускается. Если у всех из них какая-то ошибка, мы запускаем проверку работоспособности модуля, и модуль создается заново.
Ответ №4:
Возможно, вы захотите рассмотреть возможность использования сервера моделей tensorflow (см. https://www.tensorflow.org/tfx/tutorials/serving/rest_simple ).
На практике при выполнении прогнозов модели я столкнулся с тем, что производительность при одних и тех же ресурсах CPU / GPU ухудшается при попытке параллельного выполнения нескольких прогнозов (т. Е. многопроцессорности). Матричные вычисления, как правило, используют низкоуровневый параллелизм с помощью библиотек, а попытка использовать несколько процессов, как правило, приводит к замедлению, по моему опыту. Как отмечали другие, лучшим подходом всегда является собственное тестирование производительности для вашего варианта использования.