Почему оверлейные сети Docker требуют консенсуса?

Question

Только что прочитал о оверлейных сетях Docker, очень крутые вещи. Я просто не могу найти ответ на одну вещь.

Согласно документам:

• Если вы устанавливаете и используете Docker Swarm, вы автоматически получаете оверлейные сети на хостах вашего менеджера / рабочего, и вам больше не нужно ничего настраивать; но...
• Если вы просто хотите (не Swarm) оверлейную сеть на нескольких хостах, вам необходимо настроить эту сеть с внешним "KV Store" (консенсус-сервером), таким как Consul или ZooKeeper

Мне интересно, почему это так. Очевидно, что оверлейные сети требуют консенсуса среди пиров, но я не уверен, почему или кто эти "пэры" вообще являются.

И я просто догадываюсь, что с Swarm, какой-то внутренний / скрытый консенсус-сервер работает из коробки.

Answer 1

Swarm Mode использует Raft для консенсуса менеджера со встроенным магазином KV. До режима роя наложение сети было возможно со сторонними магазинами KV. Сама оверлейная сеть не требует консенсуса, она просто полагается на то, что говорит хранилище KV, независимо от других узлов или даже от своего локального состояния (я нашел это нелегким путем). Магазины KV там обычно настроены с консенсусом для HA.

Хранилище KV отслеживает распределение IP-адресов для контейнеров, работающих на каждом хосте (IPAM). Это позволяет docker назначать данный адрес только один раз и знать, с каким Docker-хостом он должен общаться, когда вы подключаетесь к контейнеру, запущенному на другом хосте. Это должно быть внешним от любого одного хоста докера и предпочтительно в конфигурации HA (например, консенсус режима роя), чтобы он мог продолжать работать, даже когда некоторые докерские узлы не работают.

В оверлейной сети между док-узлами участвуют только те узлы, которые имеют контейнеры в этой оверлейной сети. Таким образом, как только IP выделен и обнаружен, вся связь происходит только между узлами с соответствующими контейнерами. Это легко увидеть в режиме роя, если вы создаете сеть, а затем перечисляете сети на рабочем месте, ее там не будет. Как только контейнер в этой сети будет запланирован, появится сеть. С помощью докера это снижает накладные расходы на многосетевые сети, а также повышает безопасность архитектуры. Результат выглядит следующим образом:

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

Наконец, вам не нужно настраивать внешнее хранилище KV для использования оверлейной сети вне сервисов режима роя. Вы можете реализовать режим роя, настроить оверлейные сети с помощью --attachable и запускайте контейнеры вне режима роя в этой сети, как это было бы с внешним хранилищем KV. В прошлом я использовал это как переходное состояние, чтобы перевести контейнеры в режим роя, где некоторые работали с docker-compose, а другие были развернуты как стек роя.