Що таке overlay network і коли вона потрібна?

docs.questions.sections.docker~4 хв читання

Docker overlay network це відповідь на «як container на host A говорять з container на host B?». Він будує віртуальну L2-мережу поверх існуючої IP-мережі через VXLAN-енкапсуляцію, тож container бачать одне одного, ніби на тому самому фізичному LAN, незалежно від того, на якому host вони реально крутяться.

Теорія

TL;DR

Overlay = мережа, що охоплює кілька Docker host (Swarm node).
Побудовано на VXLAN (Virtual eXtensible LAN, RFC 7348). Кожен пакет container загортається у UDP-пакет і шиппиться через underlay-мережу.
Потребує Docker Swarm, спочатку docker swarm init. Без Swarm docker network create --driver overlay падає з помилкою.
Шифрується через --opt encrypted при створенні; використовує IPsec/AES-GCM у сучасному Swarm.
Бери, коли: Swarm-сервіси потребують cross-host service discovery і load balancing.
Пропусти, коли: single host (bridge достатньо) або Kubernetes (свої CNI-плагіни, не Docker overlay).

Швидкий приклад

bash

# Ініціалізуємо Swarm на першому node
node-1$ docker swarm init --advertise-addr 192.168.1.10
# Видає join-токен; запускай на кожному worker:
node-2$ docker swarm join --token SWMTKN-... 192.168.1.10:2377

# На менеджері створюємо overlay
node-1$ docker network create --driver overlay --attachable appnet

# Деплоїмо сервіс через node
node-1$ docker service create --name api --network appnet --replicas 5 myapp
# 5 container розкидані по обох node; усі на appnet, всі дістають одне одного.

# Container на node-1 і node-2 пингують один одного по service-імені
node-1$ docker exec <api-container> ping api  # round-robin через Swarm DNS

Без overlay container api на node-1 не має IP-маршруту до container на node-2. З overlay трафік VXLAN-загортається і тунелюється.

Як працює VXLAN-енкапсуляція

  container A (10.0.0.5) на node-1                container B (10.0.0.6) на node-2
         |                                                  |
         |  пакет: src=10.0.0.5 dst=10.0.0.6                 |
         v                                                  ^
  +-----------------+                              +-----------------+
  |   overlay vxlan |                              |   overlay vxlan |
  | загортає у UDP/4789|  underlay: 192.168.1.10/.20 | розгортає    |
  +-----------------+ ────────────────────────────►+-----------------+
         |                                                  ^
         |  на проводі: UDP 4789, payload = оригінальний пакет|
         v                                                  |
  host eth0 (192.168.1.10) ──────────────────────────► host eth0 (192.168.1.20)

Overlay-мережа має свій IP-простір (наприклад, 10.0.0.0/24). Кожен container отримує IP там. Host має окремий IP на underlay (192.168.1.0/24). Пакети container загортаються у UDP-пакети до underlay-IP цільового host.

Service discovery на overlay

Overlay-мережі включають embedded DNS Docker Swarm плюс вбудований load balancer («routing mesh»):

bash

# Сервіс "api" має 5 реплік на 3 node. Всередині будь-якого container на appnet:
$ nslookup api
Server:    127.0.0.11
Address 1: 10.0.1.5 api
# Віртуальний IP, що балансує між 5 реплік через IPVS.

Service-ім'я резолвиться у virtual IP. З'єднання з цим VIP розподіляються між здоровими репліками через kernel-модуль IPVS на кожному node. Container не мають знати, який фізичний host крутить яку репліку.

Шифровані overlay

bash

docker network create --driver overlay --opt encrypted my-secure-net

Додає AES-GCM шифрування між Swarm-node. Корисно, коли underlay-мережа не довірена (cross-region, публічний інтернет між node). Performance-cost реальний, але зазвичай прийнятний.

Коли потрібен overlay

Docker Swarm-сервіси, що крутяться на більше ніж одному node і мають говорити один з одним.
Service-to-service трафік, що не повинен іти через публічний інтернет (overlay через VPN-зв'язані датацентри).
Будь-де, де один bridge не дістає, бо container живуть на різних host.

Коли overlay НЕ потрібен

Single Docker host: bridge простіший і швидший.
Kubernetes: використовує CNI-плагіни (Calico, Flannel, Cilium), не Docker overlay. K8s має свій еквівалент на рівні кластера.
Зовнішнє спілкування: container дістають інтернет через NAT, незалежно від типу мережі. Overlay для container-to-container, не container-to-internet.

Типові помилки

Спроба overlay без Swarm

bash

$ docker network create --driver overlay test
Error response from daemon: This node is not a swarm manager.

Overlay це Swarm-фіча. docker swarm init спочатку.

Забути --attachable

bash

# Без --attachable лише Swarm-сервіси можуть приєднатися.
# Standalone `docker run --network myoverlay` падає.
docker network create --driver overlay myoverlay

# З --attachable і сервіси, і standalone container можуть приєднатися.
docker network create --driver overlay --attachable myoverlay

Для змішаних workflow (сервіс + ad-hoc debug-container) бери --attachable.

Underlay-firewall блокує VXLAN

VXLAN використовує UDP port 4789. Swarm потребує ще TCP/UDP 7946 (gossip) і TCP 2377 (manager API). Cloud security group або on-prem firewall між node мають їх дозволяти.

Брати overlay для single-host сетапу

Жодної переваги, реальний overhead (VXLAN encap, навіть коли обидва endpoint локальні). Тримайся bridge, поки реально не підеш у multi-host.

Реальне застосування

Swarm production: кожне cross-host з'єднання сервісу. Swarm будує overlay-мережу ingress автоматично для routing mesh.
Multi-region Swarm: шифрований overlay через cloud-регіони, VXLAN-тунель через WAN. Працює, але будь чесним щодо latency.
Гібридні демо / lab-сетапи: overlay через пару лептопів на воркшопі для симуляції multi-host без K8s.

Питання для поглиблення

Q: Яка різниця між overlay і bridge?

A: Bridge single-host (усі container на одному Docker daemon). Overlay multi-host (container на різних машинах). Overlay переносить L2-абстракцію через IP-underlay; bridge це просто Linux bridge на одному host.

Q: Чи працює overlay зі звичайними docker run container, чи тільки з сервісами?

A: Обидва, якщо створюєш overlay з --attachable. Без цього флага лише Swarm-сервіси можуть використовувати.

Q: Чому б не використовувати overlay завжди, навіть на single host?

A: Performance-overhead (VXLAN-енкапсуляція). Складність (потребує запущений Swarm). Для single host bridge дає той самий container DNS без overhead.

Q: Як Docker overlay відрізняється від Kubernetes pod networking?

A: Обидва вирішують cross-host container-to-container connectivity. Docker overlay вбудовано у Swarm і використовує VXLAN. Kubernetes використовує CNI-плагіни, яких багато (деякі VXLAN-based як Flannel, інші routing-based як Calico). Різні екосистеми, схожа задача.

Q: (Senior) Що таке routing mesh у Docker Swarm і як він пов'язаний з overlay?

A: Routing mesh це спеціальний overlay під назвою ingress, що Swarm створює автоматично. Коли публікуєш service-порт (-p 80:80 на docker service create), кожен Swarm-node слухає host:80, і трафік, що прибуває, форвардиться через overlay до node, що реально крутить репліку. У комбінації з IPVS load balancing на кожному node ти отримуєш будь-який-node-може-приймати-трафік без зовнішніх load balancer. Caveat: routing-mesh DNAT може ламати видимість source IP, бери --publish mode=host, якщо потрібні реальні client IP.

Приклади

Налаштування two-node Swarm з overlay

bash

# Node 1 (менеджер)
node-1$ docker swarm init --advertise-addr 192.168.1.10
Swarm initialized: current node (xxx) is now a manager.
To add a worker: docker swarm join --token SWMTKN-... 192.168.1.10:2377

# Node 2 (worker)
node-2$ docker swarm join --token SWMTKN-... 192.168.1.10:2377

# Перевіряємо
node-1$ docker node ls
ID      HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS
xxx     node-1     Ready     Active         Leader
yyy     node-2     Ready     Active

# Створюємо overlay
node-1$ docker network create --driver overlay --attachable appnet

# Деплоїмо сервіс на обидва node
node-1$ docker service create --name api --replicas 4 --network appnet myapp

# Підтверджуємо розміщення
node-1$ docker service ps api
# 4 репліки, 2 на кожному node

Шифрований overlay через регіони

bash

# На Swarm, де node живуть у різних cloud-регіонах
$ docker network create --driver overlay \
    --opt encrypted \
    --subnet 10.5.0.0/16 \
    secure-net

$ docker service create --name api --replicas 6 --network secure-net myapp
# Трафік сервісу між us-east-1 і eu-west-1 тепер AES-зашифровано в transit.

Флаг шифрування додає IPsec ESP між host. CPU-cost: помітний для high-throughput сервісів; зазвичай нормально для звичайного RPC-трафіку.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів