Стоит ли ограничивать службы роя рабочими узлами? - PullRequest
0 голосов
/ 07 сентября 2018

Скажем, у меня есть рой докеров с отдельными рабочими и менеджерами. Нужно ли указывать ограничение размещения, чтобы данная служба работала только на рабочем узле?

Как в этом файле docker-compose:

version "3.1"

services: 
  foo:
    image: hello-world
    deploy:
      placement:
         - node.role==worker

Или Swarm автоматически ограничивает работу служб на рабочих узлах?

1 Ответ

0 голосов
/ 08 сентября 2018

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

Самый распространенный метод, как вы уже описали, установить ограничение размещения на node.role==worker для каждой службы, которую вы хотите запускать только на рабочих против менеджера.,Для этого требуется немного поработать с каждым сервисом, который вы планируете планировать в кластере, но это также один из более гибких вариантов, поскольку вы можете указать, что некоторые рабочие нагрузки должны запускаться на менеджерах (например, на любом сервисном сервисе, который должен управлятькластера или иметь доступ к деталям диспетчера кластера, например к самоконфигурирующимся обратным прокси-серверам.

Следующий метод заключается в изменении доступности менеджеров:

$ docker node update --help
Usage:  docker node update [OPTIONS] NODE
Options:
      --availability string   Availability of the node ("active"|"pause"|"drain")
...

По умолчанию всеузлы активны.Однако вы можете приостановить планирование новых рабочих нагрузок на узле или отвести существующие рабочие нагрузки от узла, изменив его доступность.Это не влияет на контейнеры, развертываемые вне режима роя (с docker container run или docker-compose вместо команд docker stack или docker service режима роя).Тем не менее, он негибкий и не позволяет легко запускать некоторые рой-контейнеры для менеджеров и другие для рабочих.Самым распространенным способом изменения параметра доступности является вывод узла из эксплуатации для обслуживания, а не для управления расписанием работы менеджеров.Единственный раз, когда я использовал это, это когда третий менеджер был добавлен в кластер с двумя узлами для HA, где у него никогда не должно быть запланированной рабочей нагрузки.

Третий метод для реализации этого является частью Docker.ЭЭ предложение.При планировании заданий с помощью Docker UCP он действует как уровень безопасности между пользователем, выполняющим команды, и док-узлами.Одной из функций UCP является управление тем, на какие узлы пользователи могут планировать свою рабочую нагрузку, и имеется переключатель верхнего уровня, позволяющий включать или отключать планирование заданий для менеджеров пользователями и даже администраторами.Даже если вы не работали с Docker EE, можно написать собственный прокси-сервер API докера, к которому у пользователей будет доступ, и это добавляет дополнительные ограничения к планируемому развертыванию служб.Но учитывая простоту первого варианта, я еще не видел, чтобы кто-нибудь сделал это.

...