docker overlay网络必须依赖swarm模式，因其核心依赖swarm提供的分布式状态同步与服务发现：vxlan封装实现跨主机数据传输（udp 4789端口、vni隔离），而swarm通过gossip或kv存储同步容器位置、维护fdb和dns，缺一不可。
要真正理解 Docker Overlay 网络的跨主机通信底层架构，关键不是记住命令，而是看清数据包从一个容器出发、穿越物理网络、最终抵达另一台主机上容器的完整路径——它是一套由协议、内核机制和分布式协调共同支撑的协同系统。
VXLAN 封装是通信的物理基础
VXLAN（Virtual Extensible LAN）是 Overlay 网络实际承载流量的底层技术。它把容器发出的原始二层以太网帧，封装进一个标准 UDP 报文里，再通过宿主机的物理网卡发出：
- 原始帧（含源/目标容器 MAC 和 IP）被加上 VXLAN 头部，其中 VNI（VXLAN Network Identifier） 标识该流量属于哪个 Overlay 网络（如 4096），保证多网络隔离
- 外层 UDP 包目的端口固定为 4789（RFC 标准），源端口由内核动态分配；整个封装过程在 Linux 内核态完成，无需用户态干预，性能可控
- 封装后的 UDP 包走宿主机默认路由，经物理交换机或云平台网络转发到目标主机——对底层网络无特殊要求，只要 IP 层可达、UDP 4789 端口互通即可
Swarm Mode 是状态同步与服务发现的控制平面
Overlay 网络本身不提供自动发现能力。Docker 将其设计为必须运行在 Swarm 模式下，是因为只有 Swarm 才能解决“谁在哪台机器上”这个核心问题：
- Manager 节点通过 Gossip 协议（或可选集成 etcd/Consul）在集群内广播并同步各节点上的网络配置、容器位置、服务端点等元数据
- 每个节点上的 dockerd 根据同步来的信息，在本地创建对应的 VXLAN 设备（如
docker_gwbridge+vxlan-4096）、FDB（Forwarding Database）条目，以及容器 veth 对的路由规则 - 当容器内执行
ping alpine2时，请求先发给内置 DNS（tasks.alpine2或alpine2），DNS 查 Swarm 内置服务注册表返回目标容器的虚拟 IP，再经本地 FDB 查到该 IP 对应的目标主机 IP 和 VXLAN VNI，触发封装
网络命名空间与虚拟设备构成数据平面
真正收发封装/解封数据的，是嵌套在 Linux 内核中的多个轻量级组件：
- 每个容器运行在独立的 network namespace 中，拥有自己的 lo、eth0（连接到 veth pair 一端）等虚拟接口
- 宿主机上存在一对 veth 设备：一端在容器命名空间，另一端挂在名为
br0（或类似）的 Linux 网桥上；该网桥又连接到 VXLAN 设备（如vxlan-4096） - VXLAN 设备监听 UDP 4789，收到报文后根据 VNI 查找对应网络，并将内层原始帧注入网桥，最终送达目标容器的 eth0 接口
- 所有这些设备、规则、fdb 条目均由 dockerd 自动管理，无需手动配置 iproute2 或 ovs-vsctl
为什么不能脱离 Swarm 单独用 overlay？
Docker 的 overlay 驱动不是纯协议栈实现，而是一个强依赖集群协调的“半托管”网络：
- 没有 Swarm，
docker network create -d overlay命令会失败或创建出仅限单机 scope 的 fake overlay（实际退化为 bridge） - 即使绕过限制手动创建，也无法自动同步容器位置、无法更新远端 FDB、DNS 无法解析服务名——导致“网络创建成功，但 ping 不通”
- 第三方方案（如 Flannel、Weave）之所以能脱离 Swarm 工作，是因为它们自己实现了 KV 存储、健康探测、FDB 同步等全套控制面逻辑
