overlay网络通过vxlan封装实现跨主机容器通信：容器发包后，宿主机将原始帧封装进udp（端口4789），以物理ip为外层头传至目标主机，再解封投递，全程透明；控制面依赖raft等键值存储同步ip与主机映射关系。
容器跨主机通信的底层路由，本质是让不同物理机上的容器像在同一个局域网里那样直接通信。这不能靠默认的 docker0 网桥实现，因为每个宿主机的 docker0 是隔离的、子网也不同（比如 node1 是 172.17.0.0/16，node2 是 172.18.0.0/16），数据包根本“出不去”本机。Docker 架构通过在网络层之上叠加一层逻辑网络，并配合控制面协同，来打通这条路。
核心依赖：网络命名空间 + veth pair + 虚拟网桥
每个容器运行在独立的 net namespace 中，拥有自己的 IP、路由表和 iptables 规则；它通过一对 veth 虚拟网卡连接到宿主机的 docker0（或自定义网桥）。这个结构决定了：容器发包时，目标不在本地子网，就会走默认网关（如 172.17.0.1）——但这个网关只管本机网桥转发，不管跨主机。
所以，单靠 bridge 模式，跨主机通信天然断开。必须引入能跨越物理边界的机制。
Overlay 网络：用 VXLAN 封装实现“逻辑二层透传”
这是 Docker 原生支持的跨主机方案（尤其在 Swarm 模式下）。它的路由逻辑不是传统三层路由，而是“封装-解封装”的隧道路由：
- 容器发出的数据包，目的 IP 是另一台主机上的容器地址（如 10.0.1.5）
- 宿主机上的 dockerd 查到该 IP 属于远程节点，就用 VXLAN 封装：把原始以太帧作为载荷，外层打上 UDP 包头（目标端口 8472），源/目的 IP 换成两台宿主机的物理 IP（如 192.168.123.88 → 192.168.123.99）
- 这个 UDP 包经物理网络正常路由送达对端宿主机
- 对端 dockerd 收到后解封装，还原原始帧，再通过本地网桥和 veth pair 投递到目标容器
整个过程对容器透明——它只觉得自己在和同网段设备通信，而真实路由由宿主机内核和 docker daemon 共同完成。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
控制面决定“往哪封”：键值存储协调网络状态
VXLAN 本身不解决“怎么知道 10.0.1.5 在哪台机器上”。这就需要控制平面：
- Docker Swarm 内置基于 raft 协议的分布式键值存储（类似 etcd）
- 每个节点上报自己管理的容器子网（如 node1: 10.0.1.0/24）、容器 IP 和宿主机物理 IP 的映射关系
- 当 node1 上的容器要访问 10.0.1.5 时，dockerd 查询本地缓存或键值库，确认该 IP 归属 node2，才触发 VXLAN 封装
没有这套同步机制，封装目标就无从得知，跨主机通信就退化为手动配置静态路由或 IP 手动分配，无法动态扩缩容。
替代方案：macvlan 或直接路由，绕过封装走物理层
如果追求极致性能或已有成熟 SDN，也可以不用 Overlay：
- macvlan：给容器分配一个独立 MAC 地址，绑定到宿主机物理网卡。容器获得与宿主机同网段的真实 IP（如都属 192.168.123.0/24），靠物理交换机做二层转发，完全不经过 docker0 和 NAT
-
直接路由：手动在每台宿主机上添加静态路由，例如在 node1 上加
ip route add 172.18.0.0/16 via 192.168.123.99，并确保宿主机开启net.ipv4.ip_forward=1、关闭反向路径过滤（rp_filter），让内核真正转发非本机 IP 的包
这两种方式跳过了隧道封装，延迟更低，但要求物理网络支持（如 macvlan 需网卡支持、直接路由需三层可达且无 ACL 拦截），管理复杂度更高。
