Вопрос об ограничении в 100 модулей на узел

#kubernetes

#kubernetes

Вопрос:

Я пытаюсь создать веб-приложение, в котором каждый пользователь получает свой собственный экземпляр приложения, работающий в его собственном контейнере. Я новичок в kubernetes, поэтому, вероятно, я что-то неправильно понимаю.

У меня будет несколько физических серверов для использования, которые в kubernetes, как я понимаю, называются узлами. Для каждого узла существует ограничение в 100 модулей. Итак, если я создаю приложение так, чтобы каждый пользователь получал свой собственный модуль, буду ли я ограничен 100 пользователями на физический сервер? (Если у меня 10 серверов, у меня может быть только 500 пользователей?) Я полагаю, я мог бы запустить несколько виртуальных машин, которые действуют как узлы на каждом физическом сервере, но разве это не противоречит цели контейнеризации?

Ответ №1:

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

Когда вы создаете модуль, среда выполнения должна постоянно отслеживать, выполняя проверки (готовность и жизнеспособность), мониторинг, правила маршрутизации и многие другие мелкие детали, которые увеличивают нагрузку на узел.

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

Каждый поставщик платформы также устанавливает свои собственные ограничения для обеспечения хорошего качества обслуживания и SLA, перегрузка узлов также сопряжена с риском, поскольку узел является единственной точкой отказа, и любая ошибка в узлах с высокой плотностью может оказать огромное влияние на кластер и приложения.

Вам следует либо рассмотреть:

  • Уменьшать узлы и добавлять больше узлов в кластер или
  • Вместо этого используйте актеров, где каждый клиент будет одним актером. И многие участники будут запущены в одном контейнере. Чтобы сделать его более сбалансированным для кластера, вы разделяете участников на несколько экземпляров контейнеров.

Что касается ограничений, в этом потоке есть хорошее обсуждение проблем

Комментарии:

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

Ответ №2:

Из-за жесткого лимита если у вас 10 серверов, вы ограничены 1000 модулями.

Возможно, вы захотите также подсчитать модули управления самолетом в ваших 1000 доступных модулях. Обычно расположенный в пространстве имен kube-system , он может включать (но не ограничивается) :

  • экспортеры журналов узлов (по 1 на узел)
  • экспортеры показателей
  • прокси-сервер kube (обычно 1 на узел)
  • панель управления kubernetes
  • DNS (масштабирование в соответствии с количеством узлов)
  • контроллеры, подобные certmanager

Довольно хорошим эмпирическим правилом может быть 80-90 модулей приложений на узел, поэтому 10 узлов смогут обрабатывать 800-900 клиентов, учитывая, что у вас нет другого крупного развертывания на этих узлах.


Если вы используете контейнеры для получения производительности, создание виртуальных машин узла будет противоречить вашей цели. Но если вы используете контейнеры как способ развертывания согласованных сред и масштабирования приложений без состояния, то использование виртуальных машин в качестве узла может иметь смысл.

Волшебных правил не существует, и ваш контекст будет диктовать, что делать.

Поскольку управление кластером виртуализации и кластером kubernetes может резко увеличить сложность вашей инфраструктуры, возможно, kubernetes не самый эффективный инструмент для управления вашей рабочей нагрузкой.

Возможно, вы также захотите взглянуть на Nomad, который, похоже, не имеет таких ограничений и может предоставлять функции, которые ближе к вашим потребностям.

Комментарии:

1. Спасибо за ваш ответ. Идея заключалась в том, чтобы предоставить пользователям согласованную среду и не позволять действиям одного пользователя влиять на физические ресурсы, доступные другим пользователям. Однако я понимаю, что до тех пор, пока пользователи потенциально используют один и тот же узел для обработки своих запросов, они будут совместно использовать ресурсы.