докерский рой с разнородными узлами: лимит по доступным ресурсам?

0

В моем офисе работает небольшой док-рой: один 40-ядерный (128 ГБ ОЗУ) и два 8-ядерных (16 ГБ ОЗУ каждый). Когда я развертываю службу через рой, задания выполняются, но они распространяются равномерно без учета производительности на машину.

Я начал рой на менеджера с:

docker swarm init
docker swarm update --task-history-limit 2

и на каждом узле:

docker swarm join --token <token-string> <ipaddr:port>

Затем я начинаю службу с:

docker service create --detach \
     --mount type=bind,src=/s/mypath,dst=/home/mypath \
     --entrypoint "/home/mypath/myscript.sh arg1 arg2" \
     --name "mystuff" -w /home/mypath myregistry.me.com:5433/myimage

Процесс работает индивидуально. Я не нашел указаний на вес присваивания или сходство на основе силы узла.

В идеале я бы хотел сказать что-то вроде этого:

  1. присоединяйся к рое, возьми не более n задачи (немного наивно)
  2. присоединяйся к рою, веси мою (cpu-) мощность как 0.2 (или же 5 на более крупные)
  3. Запустите эту службу, назначьте не более одной задачи для каждого доступного ядра

Я саморегулируем общий масштаб обслуживания с docker service scale, но это не обеспечивает никакой детализации. Можно ли регулировать службы Docker Swarm для каждого узла доступными ресурсами?

(Это может быть еще большим стимулом для перехода на k8s, который, как я полагаю, обеспечивает функциональность в этом направлении. Есть трудности с обучением и переходом, который я усердно готовил.)

r2evans
источник

Ответы:

1

Все это действительно возможно при создании или обновлении сервиса Swarm.

Это подпадает под опции «размещение контейнера» в этих командах. Если вас беспокоит только резервирование ресурсов, тогда посмотрите на --reserve-cpu а также --reserve-memory, Это обеспечит наличие у узла свободного процессора или памяти на узле перед выполнением задач каждого контейнера.

Пример: если вам нужен сервис swarm для развертывания двух реплик php, и каждый из них должен убедиться, что он находится на узле с 1 ГБ памяти и 1 ЦП, тогда service create --reserve-cpu 1 --reserve-memory 1GB php будет только планировать контейнеры на узлах, которые, как знает планировщик Swarm, имеют такое количество доступного оборудования. Если узел имеет только 2 логических ЦП, он никогда не развернет более 2 реплик этой службы на этом узле.

Bret Fisher
источник
Существует множество других способов управления размещением задач, включая ограничение ЦП / памяти, «режим» (глобальный / замененный), сервисные ограничения (сопоставление меток), настройки размещения и доступность узлов, но я упомяну, вероятно, ваш ответ.
Bret Fisher
Это было проще, чем я ожидал, не знаю, как я это пропустил. Спасибо, Брет!
r2evans
Будет ли другой вопрос, если вы предпочитаете: есть ли простой способ ограничить общее количество запущенных экземпляров? То есть «выполнить эту задачу 100 раз» (и распределить ее соответствующим образом по разнородным работникам) «и затем остановить»?
r2evans
не встроен. Swarm предполагает, что Сервис работает долго. Два варианта: попробовать и взломать что-то вместе с опциями создания сервиса поиск перезапуска но это обычно не хороший опыт. Лучший вариант - проверить JaaS (работа как услуга) Алекс Эллис github.com/alexellis/jaas который работает на вершине роя и может запускать одноразовые вещи.
Bret Fisher
Я подозревал столько же с роем (одна из причин, по которой k8s может быть привлекательной). Я еще не видел JaaS, проверю. Спасибо!
r2evans