Поделиться через

Начало работы с режимом swarm

  • Статья

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Что такое "режим swarm"?

Режим Swarm — это функция Docker, которая предоставляет встроенные возможности оркестрации контейнеров, включая собственную кластеризацию узлов Docker и планирование рабочих нагрузок контейнеров. Группа узлов Docker формирует кластер swarm, когда их подсистемы Docker работают вместе в режиме swarm. Дополнительные сведения о режиме swarm см. на главном сайте документации Docker.

Узлы диспетчера и рабочие узлы

Swarm состоит из двух типов узлов контейнеров: узлов диспетчера и рабочих узлов. Каждый swarm инициализируется с помощью узла диспетчера, и все команды Интерфейса командной строки Docker для управления и мониторинга swarm должны выполняться с одного из его узлов диспетчера. Узлы диспетчера можно рассматривать как "хранители" состояния Swarm — вместе они формируют группу консенсуса, которая обеспечивает осведомленность о состоянии служб, работающих на рое, и это их задача, чтобы убедиться, что фактическое состояние роя всегда соответствует его предполагаемому состоянию, как определено разработчиком или администратором.

Примечание.

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

Рабочие узлы управляются swarm Docker через узлы диспетчера. Чтобы присоединиться к swarm, рабочий узел должен использовать "токен соединения", созданный узлом диспетчера при инициализации swarm. Рабочие узлы просто получают и выполняют задачи от узлов диспетчера, поэтому им не требуется (и обладать) отсутствием осведомленности о состоянии роя.

Требования к системе режима swarm

По крайней мере одна физическая или виртуальная компьютерная система (для использования полной функциональности swarm по крайней мере двух узлов) под управлением Windows 10 Creators Update или Windows Server 2016 со всеми последними обновлениями*, настройка в качестве узла контейнера (см. раздел, контейнеры Windows в Windows 10 или контейнеры Windows на Windows Server для получения дополнительных сведений о том, как приступить к работе с контейнерами Docker в Windows 10).

*Примечание. Для Docker Swarm в Windows Server 2016 требуется KB4015217

Модуль Docker версии 1.13.0 или более поздней

Открытые порты: на каждом узле должны быть доступны следующие порты. В некоторых системах эти порты открываются по умолчанию.

  • TCP-порт 2377 для связи управления кластерами
  • TCP и порт UDP 7946 для обмена данными между узлами
  • Порт UDP 4789 для наложения сетевого трафика

Инициализация кластера Swarm

Чтобы инициализировать swarm, просто выполните следующую команду из одного из узлов контейнеров (заменив <HOSTIPADDRESS> локальным IPv4-адресом хост-компьютера):

# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377

При выполнении этой команды из заданного узла контейнера подсистема Docker на этом узле начинает работать в режиме swarm в качестве узла диспетчера.

Добавление узлов в swarm

Для использования режима мелких объектов и функций сети наложения не требуются несколько узлов. Все функции swarm/overlay можно использовать с одним узлом, работающим в режиме swarm (т. е. узел диспетчера, помещенный в режим swarm с docker swarm init помощью команды).

Добавление рабочих в рой

После инициализации swarm из узла диспетчера другие узлы можно добавить в рой как рабочие роли с другой простой командой:

C:\> docker swarm join --token <WORKERJOINTOKEN> <MANAGERIPADDRESS>

<Здесь MANAGERIPADDRESS> — это локальный IP-адрес узла диспетчера swarm, а <WORKERJOINTOKEN> — это маркер присоединения к рабочей роли, предоставленный в качестве выходных данных командойdocker swarm init, выполняемой с узла диспетчера. Маркер соединения также можно получить, выполнив одну из следующих команд из узла диспетчера после инициализации swarm:

# Get the full command required to join a worker node to the swarm
C:\> docker swarm join-token worker

# Get only the join-token needed to join a worker node to the swarm
C:\> docker swarm join-token worker -q

Добавление менеджеров в рой

Дополнительные узлы диспетчера можно добавить в кластер swarm с помощью следующей команды:

C:\> docker swarm join --token <MANAGERJOINTOKEN> <MANAGERIPADDRESS>

Опять же, <MANAGERIPADDRESS> — это локальный IP-адрес узла диспетчера swarm. Маркер соединения MANAGERJOINTOKEN> — это маркер <присоединения к узлу диспетчера, который можно получить, выполнив одну из следующих команд из существующего узла диспетчера:

# Get the full command required to join a **manager** node to the swarm
C:\> docker swarm join-token manager

# Get only the join-token needed to join a **manager** node to the swarm
C:\> docker swarm join-token manager -q

Создание сети наложения

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

# Create an overlay network
C:\> docker network create --driver=overlay <NETWORKNAME>

Здесь ИМЯ NETWORKNAME> — это имя, <которую вы хотите предоставить сети.

Развертывание служб в swarm

После создания сети наложения службы можно создавать и присоединять к сети. Служба создается со следующим синтаксисом:

# Deploy a service to the swarm
C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Здесь SERVICENAME> — это имя, <которое вы хотите предоставить службе. Это имя, которое будет использоваться для ссылки на службу с помощью обнаружения служб (который использует собственный DNS-сервер Docker). <NETWORKNAME> — это имя сети, к которой следует подключить эту службу (например, myOverlayNet). <CONTAINERIMAGE> — это имя образа контейнера, в котором будет определена служба.

Примечание.

Второй аргумент этой команды, --endpoint-mode dnsrr, необходим, чтобы указать модулю Docker, что для балансировки сетевого трафика между конечными точками контейнера службы будет использоваться политика циклического перебора DNS. Сейчас циклический перебор DNS — единственная стратегия балансировки, поддерживаемая в Windows Server 2016. Сетка маршрутизации для узлов Docker в Windows поддерживается в Windows Server 2019 (и более поздних версий), но не поддерживается в Windows Server 2016. Пользователи, которым требуется другая стратегия балансировки в Windows Server 2016, могут установить внешнюю подсистему балансировки нагрузки (например, NGINX) и использовать режим публикации порта группы мелких объектов для предоставления доступа к портам узла контейнера, для которого требуется балансировка трафика.

Масштабирование службы

После развертывания службы в кластере swarm экземпляры контейнеров, составляющие службу, развертываются в кластере. По умолчанию число экземпляров контейнеров, поддерживаемых службой, — число "реплик" или "задач" для службы — одно. Однако службу можно создать с несколькими задачами с помощью --replicas docker service create параметра команды или масштабирования службы после ее создания.

Масштабируемость службы — это ключевое преимущество, предлагаемое Docker Swarm, и его также можно использовать с помощью одной команды Docker:

C:\> docker service scale <SERVICENAME>=<REPLICAS>

<Здесь SERVICENAME> — это имя масштабируемой службы, а <РЕПЛИКИ> — это количество задач или экземпляров контейнеров, для которых выполняется масштабирование службы.

Просмотр состояния swarm

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

Вывод списка узлов swarm

Используйте следующую команду, чтобы просмотреть список узлов, присоединенных к swarm, включая informaiton в состоянии каждого узла. Эта команда должна выполняться с узла диспетчера.

C:\> docker node ls

В выходных данных этой команды вы заметите один из узлов, помеченных звездочкой (*); звездочка просто указывает текущий узел- узел, из которого docker node ls была выполнена команда.

Список сетей

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

C:\> docker network ls

Перечисление служб

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

C:\> docker service ls

Вывод списка экземпляров контейнеров, определяющих службу

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

C:\> docker service ps <SERVICENAME>

Кластеры Linux+Windows mixed-OS

Недавно член нашей команды опубликовал короткую, трехкомпонентную демонстрацию о том, как настроить приложение смешанной ОС Windows+Linux с помощью Docker Swarm. Это отличное место, чтобы приступить к работе, если вы не знакомы с Docker Swarm или использовать его для запуска приложений смешанной ОС. Ознакомьтесь со следующими сведениями:

Инициализация кластера Linux+Windows mixed-OS

Инициализация кластера swarm с смешанной ОС проста, если правила брандмауэра настроены правильно, и узлы имеют доступ к другому, все, что вам нужно добавить узел Linux в swarm, является стандартной docker swarm join командой:

C:\> docker swarm join --token <JOINTOKEN> <MANAGERIPADDRESS>

Вы также можете инициализировать swarm из узла Linux с помощью той же команды, что и при инициализации swarm из узла Windows:

# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377

Добавление меток в узлы swarm

Чтобы запустить службу Docker в кластере swarm с смешанной ОС, необходимо определить, какие узлы роев работают под управлением ОС, для которой разработана эта служба, и которые не предназначены. Метки объектов Docker предоставляют полезный способ метки узлов, чтобы службы могли создаваться и настраиваться для запуска только на узлах, соответствующих их ОС.

Примечание.

Метки объектов Docker можно использовать для применения метаданных к различным объектам Docker (в том числе к образам контейнеров, контейнерам, томам и сетям), а также в других целях (например, метки можно использовать для разделения внешних интерфейсов и серверных компонентов приложения путем планирования запуска микрослужб внешних интерфейсов только на узлах с меткой внешнего интерфейса, а микрослужб серверных компонентов — на узлах с меткой серверного компонента соответственно). В этом случае мы используем метки на узлах, чтобы различать узлы ОС Windows и узлы ОС Linux.

Чтобы пометить существующие узлы swarm, используйте следующий синтаксис:

C:\> docker node update --label-add <LABELNAME>=<LABELVALUE> <NODENAME>

<LABELNAME> Ниже приведено имя создаваемой метки, например, в данном случае мы различаем узлы по своей ОС, поэтому логическое имя метки может быть "ос". <LABELVALUE> — это значение метки. В этом случае можно использовать значения "windows" и "linux". (Конечно, вы можете сделать любой вариант именования для значений меток и меток до тех пор, пока вы остаетесь согласованными. <NODENAME> — имя помечаемого узла; имена узлов можно выводить с помощью команды docker node ls.

Например, если в кластере есть четыре узла swarm, включая два узла Windows и два узла Linux, команды обновления меток могут выглядеть следующим образом:

# Example -- labeling 2 Windows nodes and 2 Linux nodes in a cluster...
C:\> docker node update --label-add os=windows Windows-SwarmMaster
C:\> docker node update --label-add os=windows Windows-SwarmWorker1
C:\> docker node update --label-add os=linux Linux-SwarmNode1
C:\> docker node update --label-add os=linux Linux-SwarmNode2

Развертывание служб в swarm Mixed-OS

С метками для узлов swarm развертывание служб в кластере легко; Просто используйте --constraint параметр для docker service create команды:

# Deploy a service with swarm node constraint
C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --network=<NETWORKNAME> --constraint node.labels.<LABELNAME>=<LABELVALUE> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Например, используя нуменклатуру меток и меток из приведенного выше примера, набор команд создания службы —один для службы под управлением Windows и один для службы на основе Linux может выглядеть следующим образом:

# Example -- using the 'os' label and 'windows'/'linux' label values, service creation commands might look like these...

# A Windows service
C:\> docker service create --name=win_s1 --endpoint-mode dnsrr --network testoverlay --constraint 'node.labels.os==windows' microsoft/nanoserver:latest powershell -command { sleep 3600 }

# A Linux service
C:\> docker service create --name=linux_s1 --endpoint-mode dnsrr --network testoverlay --constraint 'node.labels.os==linux' redis

Ограничения

В настоящее время режим swarm в Windows имеет следующие ограничения:

  • Шифрование плоскости данных не поддерживается (т. е --opt encrypted . трафик контейнера с помощью параметра)
  • Сетка маршрутизации для узлов Docker в Windows поддерживается только в Windows Server 2019 (и более поздних версий) и не поддерживается в Windows Server 2016. Пользователи, ищущие альтернативную стратегию балансировки нагрузки, сегодня могут настроить внешнюю подсистему балансировки нагрузки (например, NGINX) и использовать режим публикации порта Swarm для предоставления портов узла контейнера, по которым требуется балансировка нагрузки. Дополнительные сведения об этом описаны ниже.

Примечание.

Дополнительные сведения о настройке сетки маршрутизации Docker Swarm см. в этой записи блога .

Публикация портов для конечных точек службы

Пользователи, которым требуется опубликовать порты для конечных точек службы, могут сделать это с помощью режима публикации портов или компонента Сетка маршрутизации в Docker Swarm.

Чтобы вызвать публикацию портов узла для каждой из конечных точек задач или контейнеров, определяющих службу, используйте --publish mode=host,target=<CONTAINERPORT> аргумент docker service create для команды:

# Create a service for which tasks are exposed via host port
C:\ > docker service create --name=<SERVICENAME> --publish mode=host,target=<CONTAINERPORT> --endpoint-mode dnsrr --network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Например, следующая команда создаст службу "s1", для которой каждая задача будет предоставляться через порт контейнера 80 и случайный выбранный порт узла.

C:\ > docker service create --name=s1 --publish mode=host,target=80 --endpoint-mode dnsrr web_1 powershell -command {echo sleep; sleep 360000;}

После создания службы с помощью режима публикации порта служба может запрашиваться для просмотра сопоставления портов для каждой задачи службы:

C:\ > docker service ps <SERVICENAME>

Приведенная выше команда возвращает сведения о каждом экземпляре контейнера, работающем для службы (во всех узлах swarm). В одном из столбцов данных вывода (столбец "ports") будут содержаться сведения о портах для каждого узла в виде <HOSTPORT>-><CONTAINERPORT>/tcp. Значения <HOSTPORT> будут разными для каждого экземпляра контейнера, так как публикация каждого контейнера выполняется на его собственном порте узла.

Советы и аналитика

Существующая прозрачная сеть может блокировать инициализацию группы мелких объектов или создание сети наложения

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

Таким образом, если узел контейнера имеет только один сетевой адаптер, можно столкнуться с проблемой прозрачной блокировки сети создания сети наложения (или наоборот), так как прозрачная сеть в настоящее время занимает единственный виртуальный сетевой интерфейс узла.

Существует два способа обойти эту проблему:

  • Вариант 1. Удаление существующей прозрачной сети. Перед инициализацией swarm убедитесь, что на узле контейнера отсутствует прозрачная сеть. Удалите прозрачные сети, чтобы убедиться, что на узле есть бесплатный виртуальный сетевой адаптер, который будет использоваться для создания сети наложения.
  • Вариант 2. Создайте на узле дополнительный (виртуальный) сетевой адаптер. Вместо удаления любой прозрачной сети на узле можно создать дополнительный сетевой адаптер на узле, который будет использоваться для создания сети наложения. Для этого просто создайте внешний сетевой адаптер (с помощью PowerShell или диспетчера Hyper-V); с новым интерфейсом при инициализации swarm сетевой службы узла (HNS) автоматически распознает его на узле и будет использовать его для привязки внешнего vSwitch для создания сети наложения.