Я не разработчик, и это, кажется, непростая задача, но, пожалуйста, следуйте рекомендациям по повышению производительности за счет оптимизации конфигурации Gunicorn .
Кроме того, в kubernetes есть различные механизмы для масштабирования вашего развертывания, такие как HPA, из-за загрузка ЦП и ( Как Python масштабируется с Gunicorn и Kubernetes? )
Вы также можете использовать Запросы ресурсов и лимиты Pod и Container.
Согласно Документация по Gunicorn
НЕ масштабируйте количество работников до числа клиентов, которых вы ожидаете иметь. Gunicorn нужно только 4-12 рабочих процессов для обработки сотен или тысяч запросов в секунду.
Gunicorn полагается на операционную систему, которая обеспечивает балансировку нагрузки при обработке запросов. Как правило, мы рекомендуем (2 x $ num_cores) + 1 в качестве числа рабочих, с которых нужно начинать. Несмотря на то, что формула не слишком научна, она основана на предположении, что для данного ядра один работник будет читать или писать из сокета, в то время как другой работник обрабатывает запрос.
# обновление :
В зависимости от вашего подхода вы можете выбрать другое решение (развертывание, набор демонов), все вышеперечисленные операторы, которых вы можете достичь в kubernetes, обработав в соответствии с Назначение ресурсов ЦП контейнерам и блокам
- Использование развертывания с ресурсами (лимитами, запросами) дает вам возможность изменить размер вашего приложения на несколько модулей на одном узле в зависимости от аппаратных ограничений, но в зависимости от "загрузки приложения" это может быть недостаточно хорошим решением.
Запросы и ограничения ЦП связаны с контейнерами, но полезно думать о модуле как имеющем запрос и ограничение ЦП. Запрос ЦП для модуля - это сумма запросов ЦП для всех контейнеров в модуле. Аналогично, ограничение ЦП для модуля - это сумма ограничений ЦП для всех контейнеров в модуле.
Примечание:
Ресурс ЦП измеряется в единицах ЦП. Один процессор в Kubernetes эквивалентен:
F.E. 1 ядро GCP.
- Как уже упоминалось в посте, второй подход (масштабирование приложения на несколько узлов) также является хорошим выбором. В этом случае вы можете использовать f.e. Кроме того, установка состояния или развертывание в GKE с использованием « cluster austoscaler » позволяет добиться более расширяемого решения, когда вы пытаетесь создать новые модули, у которых недостаточно мощности для работы внутри кластера. В этом случае кластер автоматического масштабирования автоматически добавляет дополнительные ресурсы.
С другой стороны, вы можете рассмотреть возможность использования других решений, таких как Cerebral , что дает вам возможность создавать пользовательские политики для увеличения или уменьшения размера пулов узлов внутри вашего кластера.
Автоматическое масштабирование кластеров в GKE автоматически изменяет размеры кластеров в зависимости от требований рабочих нагрузок, которые вы хотите запустить. При включенном автоматическом масштабировании GKE автоматически добавляет новый узел в ваш кластер, если вы создали новые блоки, у которых недостаточно мощности для запуска; и наоборот, если узел в вашем кластере используется недостаточно и его модули могут быть запущены на других узлах, GKE может удалить этот узел.
Пожалуйста, имейте в виду, что вопрос носит очень общий характер, и на этот вопрос нет единого хорошего ответа. Вы должны учитывать все преимущества и недостатки, исходя из ваших требований, нагрузки, активности, емкости, затрат ...
Надеюсь, эта помощь.