По умолчанию docker настраивает каждую службу с Виртуальным IP (VIP), который реализован с использованием ipvs в ядре. При этом выполняется циклическая балансировка нагрузки между каждой репликой службы для каждого отдельного сетевого подключения (постоянные сетевые подключения будут оставаться подключенными к одной и той же реплике в течение срока службы этого TCP-подключения).
Когда IP-адрес пересылается на находится на другом узле, он использует оверлейную сеть, реализованную в ядре vxlan, для отправки этих пакетов на другие узлы. Если что-то в сети блокирует наложенные сетевые порты, вы увидите проблемы, заставляющие это работать. Docker содержит обязательные порты в своей документации:
- TCP-порт 2377 для связи управления кластером
- TCP и UDP-порт 7946 для связи между узлы
- UDP-порт 4789 для оверлейного сетевого трафика c
Я часто отлаживаю проблемы с подключением, используя tcpdump на каждом узле, чтобы увидеть, принимаются ли пакеты, отправленные с одного узла, на пункт назначения. И если необходимо, порт наложения может быть изменен с флагом docker swarm init --data-path-port при инициализации кластера роя.
Я предпочитаю использовать наложение сети по умолчанию в большинстве сценариев ios, поскольку это устраняет класс проблем с кэшированием DNS , Если вы используете циклический перебор DNS, каждый контейнер в кластере роя может кэшировать результаты DNS для реплик вашей службы и общаться со старыми IP-адресами, используемыми этой службой, до тех пор, пока результаты кэширования DNS сохраняются в приложении этого контейнера. Это может привести к значительному простою во время непрерывного обновления, пока вы ждете, пока приложение обновит sh это результаты DNS для выбранного контейнера. Хотя в прошлом я сталкивался с проблемами с ipvs, я не сталкивался с проблемами в последних версиях docker с более новым ядром, и этот же модуль ядра сейчас используется многими сетевыми провайдерами kubernetes, что приводит к гораздо большему тестированию и стабильности .
Если вы хотите получить отдельные IP-адреса для реплик службы или использовать DNS RR, вы можете сделать это один раз, не отключая службу VIP. Вместо этого, если вы запросите web для VIP веб-службы, вы можете запросить tasks.web для DNS RR всех реплик этой службы (заменив web на имя вашей службы). Я делал это только тогда, когда у меня есть приложения, которым нужно запускать команду для каждой реплики, и я вижу, как это может быть полезно для липких сессий.
Что касается того, как это относится к входящей сети и сервису me sh, входная сеть настроена на маршрутизацию указанного порта c к этому VIP в входной сети на каждом узле в кластере. Вы увидите VIP для каждой оверлейной сети, к которой подключена служба, включая входную сеть, если у вас есть опубликованные порты, когда вы запустите docker network inspect -v ... в своей сети.
Единственный раз, когда я рассматриваю отключение входа Сеть - это если у меня есть глобальная служба, кластер из одного узла или служба, работающая в предсказуемом списке узлов, и я хочу избежать дополнительного сетевого скачка, добавляемого службой me sh. В этих сценариях ios я публикую sh порт в режиме «хоста» (см. Длинный синтаксис для публикации портов). Это не позволит вам запустить более одной реплики на узле, но в большинстве моих случаев использования это приложение с состоянием, где несколько реплик не имеют смысла.