Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що таке overlay network і коли вона потрібна?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Docker overlay network** дозволяє container на різних host спілкуватися, ніби на одному LAN. Він инкапсулює трафік у VXLAN-пакети і маршрутизує через underlay-мережу. Потрібен для Docker Swarm-сервісів, що охоплюють кілька node. ```bash # На Swarm-менеджері docker network create --driver overlay --attachable myoverlay docker service create --name api --network myoverlay myapp ``` **Головне:** overlay = multi-host. Якщо у тебе лише один Docker host, він не потрібен, bridge достатньо. Якщо крутиш Swarm-кластер, кожне cross-node з'єднання сервісу йде через overlay.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**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-трафіку.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.