Начало работы с режимом мелких объектовGetting Started with Swarm Mode

Что такое "режим мелких объектов"?What is “swarm mode”?

Режим мелких объектов — это функция Docker, которая предоставляет встроенные возможности управление контейнерами, в том числе кластеризацию узлов Docker и планирование рабочих нагрузок контейнера.Swarm mode is a Docker feature that provides built in container orchestration capabilities, including native clustering of Docker hosts and scheduling of container workloads. Группа узлов Docker формирует кластер «мелких объектов», когда их модули Docker работают вместе в «режиме мелких объектов».A group of Docker hosts form a “swarm” cluster when their Docker engines are running together in “swarm mode.” Дополнительные сведения о режиме мелких объектов см. в на основном сайте документации Docker.For additional context on swarm mode, refer to Docker's main documentation site.

Управляющие узлы и рабочие узлыManager nodes and worker nodes

Группа мелких объектов состоит из двух типов узлов контейнера: управляющих узлов и рабочих узлов.A swarm is composed of two types of container hosts: manager nodes, and worker nodes. Каждая группа мелких объектов инициализируется через управляющий узел, при этом все команды интерфейса командной строки Docker для мониторинга группы мелких объектов и управления ей должны выполняться с одного из управляющих узлов.Every swarm is initialized via a manager node, and all Docker CLI commands for controlling and monitoring a swarm must be executed from one of its manager nodes. Управляющие узлы можно рассматривать как «хранителей» состояния группы мелких объектов — вместе они формируют группу согласия, которая предоставляет сведения о состоянии служб, запущенных в группе мелких объектов. Их задача — убедиться, что фактическое состояние группы мелких объектов всегда соответствует желаемому состоянию, заданному разработчиком или администратором.Manager nodes can be thought of as “keepers” of the Swarm state—together, they form a consensus group that maintains awareness of the state of services running on the swarm, and it’s their job to ensure that the swarm’s actual state always matches its intended state, as defined by the developer or admin.

Примечание

В любой группе мелких объектов может быть несколько управляющих узлов, но в каждой группе должен быть по крайней мере один такой узел.Any given swarm can have multiple manager nodes, but it must always have at least one.

Рабочие узлы управляются группой мелких объектов Docker посредством управляющих узлов.Worker nodes are orchestrated by Docker swarm via manager nodes. Чтобы присоединиться к группе мелких объектов, рабочий узел должен использовать «маркер присоединения», созданный с управляющего узла при инициализации группы мелких объектов.To join a swarm, a worker node must use a “join token” that was generated by the manager node when the swarm was initialized. Рабочие узлы просто получают и выполняют задачи от управляющих узлов, поэтому для них не требуется информация о состоянии группы мелких объектов.Worker nodes simply receive and execute tasks from manager nodes, and so they require (and possess) no awareness of the swarm state.

Системные требования для режима мелких объектовSwarm mode system requirements

По крайней мере одна физическая или виртуальная компьютерная система (для использования всех функций режима мелких объектов рекомендуется не менее двух узлов) с установленным обновлением Windows 10 Creators Update или ОС Windows Server 2016 со всеми последними обновлениями* , настроенная как узел контейнера (дополнительные сведения о том, как приступить к работе с контейнерами Docker в Windows 10 см. в разделе Контейнеры Windows в Windows 10 или Контейнеры Windows в Windows Server).At least one physical or virtual computer system (to use the full functionality of swarm at least two nodes is recommended) running either Windows 10 Creators Update or Windows Server 2016 with all of the latest updates*, setup as a container host (see the topic, Windows containers on Windows 10 or Windows containers on Windows Server for more details on how to get started with Docker containers on Windows 10).

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

Модуль Docker версии 1.13.0 или более позднейDocker Engine v1.13.0 or later

Открытые порты: следующие порты должны быть доступны на каждом узле.Open ports: The following ports must be available on each host. В некоторых системах эти порты по умолчанию открыты.On some systems, these ports are open by default.

  • TCP-порт 2377 для управления кластеромTCP port 2377 for cluster management communications
  • Порт TCP и UDP 7946 для связи между узламиTCP and UDP port 7946 for communication among nodes
  • Порт UDP 4789 для трафика сети наложенияUDP port 4789 for overlay network traffic

Инициализация кластера мелких объектовInitializing a Swarm cluster

Чтобы инициализировать группу мелких объектов, выполните следующую команду на одном из узлов контейнера (изменив <HOSTIPADDRESS> на локальный IPv4-адрес хост-компьютера):To initialize a swarm, simply run the following command from one of your container hosts (replacing <HOSTIPADDRESS> with the local IPv4 address of your host machine):

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

После выполнения этой команды на узле контейнера модуль Docker на нем начинает работать в режиме мелких объектов в качестве управляющего узла.When this command is run from a given container host, the Docker engine on that host begins running in swarm mode as a manager node.

Добавление узлов в группу мелких объектовAdding nodes to a swarm

Для использования режима мелких объектов и функций сети наложения не требуются несколько узлов.Multiple nodes are not required to leverage swarm mode and overlay networking mode features. Все функции группы мелких объектов и сети наложения доступны при наличии одного узла, работающего в режиме мелких объектов (т. е. управляющего узла, переведенного в режим мелких объектов с помощью команды docker swarm init).All swarm/overlay features can be used with a single host running in swarm mode (i.e. a manager node, put into swarm mode with the docker swarm init command).

Добавление рабочих узлов в группу мелких объектовAdding workers to a swarm

После инициализации группы мелких объектов управляющим узлом в нее можно добавить рабочие узлы с помощью другой простой команды:Once a swarm has been initialized from a manager node, other hosts can be added to the swarm as workers with another simple command:

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

Здесь <MANAGERIPADDRESS> — это локальный IP-адрес управляющего узла группы мелких объектов, а <WORKERJOINTOKEN> — маркер присоединения рабочего узла из выходных данных команды docker swarm init, которая была выполнена на управляющем узле.Here, <MANAGERIPADDRESS> is the local IP address of a swarm manager node, and <WORKERJOINTOKEN> is the worker join-token provided as output by the docker swarm init command that was run from the manager node. Маркер присоединения также можно получить, выполнив одну из следующих команд на управляющем узле после инициализации группы мелких объектов:The join-token can also be obtained by running one of the following commands from the manager node after the swarm has been initialized:

# 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

Добавление управляющих узлов в группу мелких объектовAdding managers to a swarm

Дополнительные управляющие узлы можно добавить в кластер мелких объектов с помощью следующей команды:Additional manager nodes can be added to a swarm cluster with the following command:

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

Опять же, <MANAGERIPADDRESS> — это локальный IP-адрес управляющего узла группы мелких объектов.Again, <MANAGERIPADDRESS> is the local IP address of a swarm manager node. Маркер присоединения <MANAGERJOINTOKEN> — это маркер присоединения управляющего узла для группы мелких объектов, который можно получить, выполнив одну из следующих команд на существующем управляющем узле:The join token, <MANAGERJOINTOKEN>, is a manager join-token for the swarm, which can be obtained by running one of the following commands from an existing manager node:

# 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

Создание сети наложенияCreating an overlay network

После настройки кластера мелких объектов можно создать сети наложения.Once a swarm cluster has been configured, overlay networks can be created on the swarm. Для этого выполните следующую команду на управляющем узле группы мелких объектов:An overlay network can be created by running the following command from a swarm manager node:

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

Здесь <NETWORKNAME> — это имя вашей сети.Here, <NETWORKNAME> is the name you'd like to give to your network.

Развертывание служб в группе мелких объектовDeploying services to a swarm

После создания сети наложения можно создать службы и привязать их к сети.Once an overlay network has been created, services can be created and attached to the network. Служба создается с помощью следующего синтаксиса:A service is created with the following syntax:

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

Здесь <SERVICENAME> — это имя службы, которое будет использоваться для создания ссылки на службу при обнаружении служб (для чего применяется нативный DNS-сервер Docker).Here, <SERVICENAME> is the name you'd like to give to the service--this is the name you will use to reference the service via service discovery (which uses Docker's native DNS server). <NETWORKNAME> — это имя сети, к которой следует подключить эту службу (например, myOverlayNet).<NETWORKNAME> is the name of the network that you would like to connect this service to (for example, "myOverlayNet"). <CONTAINERIMAGE> — это имя образа контейнера, в котором будет определена служба.<CONTAINERIMAGE> is the name of the container image that will defined the service.

Примечание

Второй аргумент этой команды, --endpoint-mode dnsrr, необходим, чтобы указать модулю Docker, что для балансировки сетевого трафика между конечными точками контейнера службы будет использоваться политика циклического перебора DNS.The second argument to this command, --endpoint-mode dnsrr, is required to specify to the Docker engine that the DNS Round Robin policy will be used to balance network traffic across service container endpoints. Сейчас циклический перебор DNS — единственная стратегия балансировки, поддерживаемая в Windows Server 2016. Сетка маршрутизации для узлов Docker в Windows поддерживается в Windows Server 2019 (и более поздних версий), но не поддерживается в Windows Server 2016.Currently, DNS Round-Robin is the only load balancing strategy supported on Windows Server 2016.Routing mesh for Windows docker hosts is supported on Windows Server 2019 (and above), but not on Windows Server 2016. Пользователи, которым требуется другая стратегия балансировки в Windows Server 2016, могут установить внешнюю подсистему балансировки нагрузки (например, NGINX) и использовать режим публикации порта группы мелких объектов для предоставления доступа к портам узла контейнера, для которого требуется балансировка трафика.Users seeking an alternative load balancing strategy on Windows Server 2016 today can setup an external load balancer (e.g. NGINX) and use Swarm’s publish-port mode to expose container host ports over which to balance traffic.

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

После развертывания службы в кластере мелких объектов экземпляры контейнера, из которых она состоит, развертываются в кластере.Once a service is deployed to a swarm cluster, the container instances composing that service are deployed across the cluster. По умолчанию количество экземпляров контейнера, поддерживающих службу (число «реплик» или «задач» для службы) равно одному.By default, the number of container instances backing a service—the number of “replicas,” or “tasks” for a service—is one. Тем не менее службу можно создать с несколькими задачами, используя параметр --replicas для команды docker service create или масштабируя службу после ее создания.However, a service can be created with multiple tasks using the --replicas option to the docker service create command, or by scaling the service after it has been created.

Масштабируемость службы — важное преимущество Docker Swarm, и им можно воспользоваться с помощью одной команды Docker:Service scalability is a key benefit offered by Docker Swarm, and it, too, can be leveraged with a single Docker command:

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

Здесь <SERVICENAME> — это имя масштабируемой службы, а <REPLICAS> — число задач или экземпляров контейнера, до которого масштабируется служба.Here, <SERVICENAME> is the name of the service being scaled, and <REPLICAS> is the number of tasks, or container instances, to which the service is being scaled.

Просмотр состояния группы мелких объектовViewing the swarm state

Существует несколько полезных команд для просмотра состояния группы мелких объектов и служб, запущенных в ней.There are several useful commands for viewing the state of a swarm and the services running on the swarm.

Перечисление узлов группы мелких объектовList swarm nodes

Выполните следующую команду, чтобы просмотреть список узлов, присоединенных к группе мелких объектов, включая сведения о состоянии каждого узла.Use the following command to see a list of the nodes currently joined to a swarm, including informaiton on the state of each node. Эту команда необходимо выполнить на управляющем узле.This command must be run from a manager node.

C:\> docker node ls

В выходных данных этой команды можно заметить, что один из узлов помечен звездочкой (*). Этот символ просто обозначает текущий узел, на котором была выполнена команда docker node ls.In the output of this command, you will notice one of the nodes marked with an asterisk (*); the asterisk simply indicates the current node--the node from which the docker node ls command was run.

Перечисление сетейList networks

Выполните следующую команду, чтобы просмотреть список сетей на заданном узле.Use the following command to see a list of the networks that exist on a given node. Для просмотра сетей наложения эту команда следует выполнить на управляющем узле, работающем в режиме мелких объектов.To see overlay networks, this command must be run from a manager node running in swarm mode.

C:\> docker network ls

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

Выполните следующую команду, чтобы просмотреть список служб, запущенных в группе мелких объектов, а также сведения об их состоянии.Use the following command to see a list of the services currently running on a swarm, including information on their state.

C:\> docker service ls

Перечисление экземпляров контейнера, которые определяют службуList the container instances that define a service

Выполните следующую команду, чтобы просмотреть сведения об экземплярах контейнера, запущенных для указанной службы.Use the following command to see details on the container instances running for a given service. В выходные данные этой команды включены идентификаторы и узлы, на которых работает каждый контейнер, а также информация о состоянии контейнеров.The output for this command includes the IDs and nodes upon which each container is running, as well as infromation on the state of the containers.

C:\> docker service ps <SERVICENAME>

Кластеры со смешанными ОС Linux и WindowsLinux+Windows mixed-OS clusters

Недавно член нашей команды опубликовал короткое руководство из трех частей, рассказывающее о том, как с помощью режима мелких объектов Docker настроить приложение для смешанных ОС Windows + Linux.Recently, a member of our team posted a short, three-part demo on how to set up a Windows+Linux mixed-OS application using Docker Swarm. Если вы только начинаете работать с режимом мелких объектов Docker или использовать его для запуска приложений для смешанных ОС, это руководство будет очень полезным.It's a great place to get started if you're new to Docker Swarm, or to using it to run mixed-OS applications. Ознакомьтесь с ним.Check it out now:

Инициализация кластера смешанных ОС Linux + WindowsInitializing a Linux+Windows mixed-OS Cluster

Инициализировать кластер мелких объектов смешанных ОС не составит труда, если правила вашего брандмауэра корректно настроены и у ваших узлов есть доступ друг к другу. Для добавления узла Linux в группу мелких объектов потребуется лишь стандартная команда docker swarm join:Initializing a mixed-OS swarm cluster is easy--as long as your firewall rules are properly configured and your hosts have access to one another, all you need to add a Linux host to a swarm is the standard docker swarm join command:

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

Из узла Linux группу мелких объектов можно также инициализировать с помощью той же команды, которая используется для инициализации группы мелких объектов из узла Windows:You can also initialize a swarm from a Linux host using the same command that you would run if initializing the swarm from a Windows host:

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

Добавление меток в узлы группы мелких объектовAdding labels to swarm nodes

Чтобы запустить службу Docker в кластере мелких объектов смешанных ОС, должен быть способ определить, какие узлы группы мелких объектов работают под управлением ОС, для которой предназначена эта служба, а какие нет.In order to launch a Docker Service to a mixed-OS swarm cluster, there must be a way to distinguish which swarm nodes are running the OS for which that service is designed, and which are not. Метки объектов Docker — это удобный способ помечать узлы таким образом, чтобы службы можно было создавать и настраивать для выполнения только на тех узлах, которые соответствуют их ОС.Docker object labels provide a useful way to label nodes, so that services can be created and configured to run only on the nodes that match their OS.

Примечание

Метки объектов Docker можно использовать для применения метаданных к различным объектам Docker (в том числе к образам контейнеров, контейнерам, томам и сетям), а также в других целях (например, метки можно использовать для разделения внешних интерфейсов и серверных компонентов приложения путем планирования запуска микрослужб внешних интерфейсов только на узлах с меткой внешнего интерфейса, а микрослужб серверных компонентов — на узлах с меткой серверного компонента соответственно).Docker object labels can be used to apply metadata to a variety of Docker objects (including container images, containers, volumes and networks), and for a variety of purposes (e.g. labels could be used to separate 'front-end' and 'back-end' components of an application, by allowing front-end microservices to be secheduled only on 'front-end' labeled nodes and back-end mircoservices to be scheduled only on 'back-end' labeled nodes). В этом случае метки используются для того, чтобы узлы ОС Windows можно было отличить от узлов ОС Linux.In this case, we use labels on nodes, to distinguish Windows OS nodes and Linux OS nodes.

Чтобы пометить существующие узлы группы мелких объектов, используйте следующий синтаксис:To label your existing swarm nodes, use the following syntax:

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

Здесь <LABELNAME> — имя создаваемой метки. В этом примере мы проводим различие между узлами по их ОС, поэтому логичным именем для этой метки может быть "os".Here, <LABELNAME> is the name of the label you are creating--for example, in this case we are distinguishing nodes by their OS, so a logical name for the label could be, "os". <LABELVALUE> — это значение метки. В этом случае можно использовать значения "windows" и "linux".<LABELVALUE> is the value of the label--in this case, you might choose to use the values "windows" and "linux". Разумеется, вы можете присваивать собственные имена и значения меткам, однако они не должны противоречить друг другу.(Of course, you may make any naming choices for your label and label values, as long as you remain consistent). <NODENAME> — имя помечаемого узла; имена узлов можно выводить с помощью команды docker node ls.<NODENAME> is the name of the node that you are labeling; you can remind yourself of the names of your nodes by running docker node ls.

Например, если у вас есть четыре узла группы мелких объектов в кластере (то есть два узла Windows и два узла Linux), команды для обновления метки могут иметь следующий вид:For example, if you have four swarm nodes in your cluster, including two Windows nodes and two Linux nodes, your label update commands may look like this:

# 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

Развертывание служб в группе мелких объектов смешанных ОСDeploying services to a Mixed-OS swarm

Метки для узлов группы мелких объектов упрощают развертывание служб в кластере; для этого достаточно использовать параметр --constraint для docker service create команды:With labels for your swarm nodes, deploying services to your cluster is easy; simply use the --constraint option to the docker service create command:

# 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) будет иметь следующий вид:For example, using the label and label value nomenclature from the example above, a set of service creation commands--one for a Windows-based service and one for a Linux-based service--might look like this:

# 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

ОграниченияLimitations

Сейчас режим мелких объектов в Windows имеет следующие ограничения.Currently, swarm mode on Windows has the following limitations:

  • Шифрование плоскости данных не поддерживается (т. е. трафика между контейнерами с использованием параметра --opt encrypted).Data-plane encryption not supported (i.e. container-container traffic using the --opt encrypted option)
  • Сетка маршрутизации для узлов Docker в Windows поддерживается только в Windows Server 2019 (и более поздних версий) и не поддерживается в Windows Server 2016.Routing mesh for Windows docker hosts is not supported on Windows Server 2016, but only from Windows Server 2019 onwards. Пользователи, которым требуется другая стратегия балансировки, могут установить внешнюю подсистему балансировки нагрузки (например, NGINX) и использовать режим публикации порта группы мелких объектов для предоставления доступа к портам узла контейнера, для которого требуется балансировка нагрузки.Users seeking an alternative load balancing strategy today can setup an external load balancer (e.g. NGINX) and use Swarm’s publish-port mode to expose container host ports over which to load balance. Подробнее об этом рассказывается ниже.More detail on this below.

Примечание

Дополнительные сведения о настройке сетки маршрутизации Docker Swarm см. в этой записи блога .For more details on how to setup Docker Swarm Routing Mesh, please see this blog post

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

Пользователи, которым требуется опубликовать порты для конечных точек службы, могут сделать это с помощью режима публикации портов или компонента Сетка маршрутизации в Docker Swarm.Users seeking to publish ports for their service endpoints can do so today using either publish-port mode, or Docker Swarm's routing mesh feature.

Чтобы опубликовать порты узла для каждой конечной точки задачи/контейнера, определяющей службу, используйте аргумент --publish mode=host,target=<CONTAINERPORT> для команды docker service create:To cause host ports to be published for each of the tasks/container endpoints that define a service, use the --publish mode=host,target=<CONTAINERPORT> argument to the docker service create command:

# 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 и порт узла, выбранный случайным образом.For example, the following command would create a service, 's1', for which each task will be exposed via container port 80 and a randomly selected host port.

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

После создания службы с помощью режима публикации портов службе можно отправить запрос на просмотр сопоставления портов для каждой задачи службы:After creating a service using publish-port mode, the service can be queried to view the port mapping for each service task:

C:\ > docker service ps <SERVICENAME>

Приведенная выше команда возвращает подробные сведения о каждом экземпляра контейнера, запущенном для вашей службы (на всех узлах группы мелких объектов).The above command will return details on every container instance running for your service (across all of your swarm hosts). В одном из столбцов данных вывода (столбец ports) будут содержаться сведения о портах для каждого узла в виде <HOSTPORT>-><CONTAINERPORT>/tcp.One column of the output, the “ports” column, will include port information for each host of the form <HOSTPORT>-><CONTAINERPORT>/tcp. Значения <HOSTPORT> будут разными для каждого экземпляра контейнера, так как публикация каждого контейнера выполняется на его собственном порте узла.The values of <HOSTPORT> will be different for each container instance, as each container is published on its own host port.

Советы и полезные рекомендацииTips & Insights

Существующая прозрачная сеть может блокировать инициализацию группы мелких объектов или создание сети наложенияExisting transparent network can block swarm initialization/overlay network creation

В Windows внешний виртуальный коммутатор сетевых драйверов "overlay" и "transparent" должен быть привязан к (виртуальному) сетевому адаптеру узла.On Windows, both the overlay and transparent network drivers require an external vSwitch to be bound to a (virtual) host network adapter. При создании сети наложения также создается новый коммутатор, который затем подключается к открытому сетевому адаптеру.When an overlay network is created, a new switch is created then attached to an open network adapter. В режиме прозрачного сетевого подключения также используется сетевой адаптер узла.The transparent networking mode also uses a host network adapter. В то же время любой сетевой адаптер одновременно можно привязать только к одному коммутатору. Если узел содержит только один сетевой адаптер, его можно подключить только к одному внешнему виртуальному коммутатору независимо от того, для какой сети предназначен этот виртуальный коммутатор — сети наложения или прозрачной сети.At the same time, any given network adapter can only be bound to one switch at a time--if a host has only one network adapter it can attach to only one external vSwitch at a time, whether that vSwitch be for an overlay network or for a transparent network.

Следовательно, если узел контейнера содержит только один сетевой адаптер, может возникнуть проблема, при которой прозрачная сеть будет блокировать создание сети наложения (или наоборот), так как прозрачная сеть будет занимать виртуальный сетевой интерфейс только на узле.Hence, if a container host has only one network adapter it is possible to run into the issue of a transparent network blocking creation of an overlay network (or vice-versa), because the transparent network is currently occupying the host's only virtual network interface.

Эту проблему можно устранить двумя способами.There are two ways to get around this issue:

  • Способ 1. Удаление существующей прозрачной сети. Перед инициализацией группы мелких объектов убедитесь, что в узле контейнера отсутствует прозрачная сеть.Option 1 - delete existing transparent network: Before initializing a swarm, ensure there is not an existing transparent network on your container host. Удалите прозрачные сети, чтобы обеспечить наличие свободного виртуального сетевого адаптера на узле. Этот адаптер будет использоваться для создания сети наложения.Delete transparent networks to ensure there is a free virtual network adapter on your host to be used for overlay network creation.
  • Способ 2. Создание дополнительного (виртуального) сетевого адаптера на узле. Вместо удаления прозрачной сети, расположенного на узле, можно создать дополнительный сетевой адаптер на вашем узле, который будет использоваться для создания сети наложения.Option 2 - create an additional (virtual) network adapter on your host: Instead of removing any transparent network that's on your host you can create an additional network adapter on your host to be used for overlay network creation. Чтобы сделать это, создайте новый внешний сетевой адаптер (с помощью PowerShell или диспетчера Hyper-V). После создания нового интерфейса и при инициализации группы мелких объектов сетевая служба узлов (HNS) будет автоматически распознавать ее на вашем узле и использовать ее для привязки внешнего виртуального коммутатора в ходе создания сети наложения.To do this, simply create a new external network adapter (using PowerShell or Hyper-V Manager); with the new interface in place, when your swarm is initialized the Host Network Service (HNS) will automatically recognize it on your host and use it to bind the external vSwitch for overlay network creation.