☰

Модуль Kubernetes достигает максимума в 1 ЦП

tag-icon • tag-icon kubernetes
Модуль Kubernetes достигает максимума в 1 ЦП

У меня есть кластер GKE Kubernetes и развертывание.

Я установил раздел ресурсов в развертывании на

resources.requests.memory: 4G
resources.requests.cpu: 2
resources.limits.memory: 4G

ограничение процессора не установлено

Я развертываю pod (веб-приложение Django) и нагружаю его нагрузочным тестом. При насыщении использование CPU pod увеличивается до 1CPU -- но по сути отказывается подниматься выше 1CPU

Есть идеи, какие неполадки мне следует устранить?

решение1

Я оставил этот пост открытым, так что давайте его закроем.

В моем конкретном случае узкое место фактически оказалось выше по течению от K8S Pod, в базе данных. Экземпляр postgres был просто недостаточно большим и достигал пика при 100% использовании ЦП и вызывал тайм-ауты ниже по течению.

Я подозреваю, хотя и не уверен, что выравнивание загрузки ЦП на модулях произошло просто потому, что модули ждали ответа от вышестоящего узла и не могли использовать ЦП на уровне 1, поскольку им больше нечего было делать.

Кроме того, экземпляры Django используют каналы Django и асинхронную модель ASGI, которая является однопоточной и не имеет той же модели «дочернего потока», что и UWSGI; это еще одна причина — или, может быть, настоящая причина — того, что использование ЦП в Pod достигает максимума в 1 ЦП.

Поэтому я уверен, что правильный способ масштабирования — это

  • Вертикальное масштабирование Postgres
  • Увеличьте базовое количество модулей
  • Уменьшите пороговое значение автомасштабирования (HPA) для масштабирования и добавления новых модулей

EDIT: Дополнительная информация

Проблема также связана с тем, как спроектировано само приложение. Мы пытаемся использовать асинхронный python Django Channels и запустить htat в контейнере Daphne ASGI; однако не все приложение асинхронное, и, по-видимому, это плохо. Я провел много исследований этой проблемы асинхронного и синхронного приложений и возникающих в результате взаимоблокировок, и пока я заставляю команду разработчиков перепроектировать приложение, я также перепроектировал развертывание

  • Добавьте сервер uWSGI к развертыванию
  • Развертывание кодовой базы в два развертывания/модуля
    • У одного есть ASGI Pod
    • У одного есть модуль uWSGI
  • Направьте все конечные точки ASGI (их всего одна) в модуль ASGI в правилах Ingress Path.
  • Направьте все конечные точки uWSGI в синхронный Pod в правилах Ingress Path

Это работает, однако я еще не провел полное нагрузочное тестирование.

Связанный контент