overlay 网络解决了什么问题
单机 Docker bridge 可以让同一台主机上的容器互通，但跨主机后会出现三个问题：容器 IP 只在本机可见，主机间没有自动路由；应用扩缩容后实例位置变化，通信关系需要重新识别；如果依赖人工维护路由，规模稍大就难以维护。Docker overlay 网络通过统一的虚拟网段和隧道转发，把这些主机连接成一个逻辑网络。
它适合多主机 Docker Swarm、轻量级容器平台和需要快速验证跨主机通信的环境。若你正在补容器基础，可以结合 Docker 与容器基础 和 容器技术专题 一起理解。
核心原理：封装、转发与解封装
overlay 常见实现基于 VXLAN。源容器发出的原始报文会先进入本机虚拟网络设备，驱动根据目标容器所在节点进行封装，把原始二层帧包进 UDP 报文，再通过底层三层网络发送到目标宿主机。目标宿主机收到后解封装，并把报文投递给目标容器。
这一过程可以拆成四个层次：容器网段负责让业务看到稳定地址；虚拟网络设备负责本机转发；主机间隧道负责跨节点传输；控制面负责维护哪些节点和容器属于同一网络。也就是说，overlay 不是魔法，而是“控制面分发成员关系，数据面完成封装转发”。
使用时要关注哪些边界
overlay 网络带来灵活性，也带来额外开销。VXLAN 封装会增加报文头部，如果底层 MTU 没有留出空间，就可能出现大包丢弃、偶发超时或只在部分路径失败的现象。大量小包、高频服务调用、底层网络抖动，也会放大封装与解封装成本。
生产排障时不要只看应用日志。建议先确认节点间基础连通性，再检查 overlay 网络状态和容器网段，随后对比 MTU、路由和名称解析。常用命令包括：
docker network ls
docker network inspect <network-name>
ip addr
ip route
和 Kubernetes 网络有什么关系
Docker overlay 与 Kubernetes CNI 都在解决容器联网问题，但抽象层不同。overlay 更偏 Docker 生态里的虚拟网络实现；Kubernetes 网络强调每个 Pod 一个 IP、Pod 之间可直接通信、网络插件可替换。理解 overlay 后，再看 Service、Ingress、NetworkPolicy 会更容易分辨：哪些是底层转发，哪些是服务入口与访问控制。
如果平台正在从 Docker 多主机走向 Kubernetes，建议把 overlay 当作理解容器网络的基础，再进入 容器网络专题 和 Kubernetes 实践 中更完整的 CNI、入口和隔离模型。
小结
Docker overlay 网络本质上是在物理网络之上构建一张虚拟容器网络，用封装和隧道让跨主机容器像在同一网络中通信。它适合多主机部署、动态迁移和轻量隔离，但必须关注 MTU、封装开销、控制面一致性和底层链路质量。掌握这些边界，才能把“容器能通”提升为“容器网络可维护”。
常见问题
Docker overlay 网络和 bridge 网络有什么区别？
bridge 主要解决单机容器通信，overlay 用于跨主机容器通信，会在多台宿主机之间建立覆盖网络。overlay 更适合 Swarm 或需要跨主机互通的场景，但排障也会涉及隧道、端口、防火墙和底层网络连通性。
overlay 网络一定适合 Kubernetes 吗？
Kubernetes 通常通过 CNI 插件实现跨节点 Pod 网络，不直接依赖 Docker overlay。理解 overlay 有助于理解覆盖网络思想，但 Kubernetes 中应以具体 CNI 的网络模型、封装方式和路由策略为准。
跨主机容器通信失败先查什么？
先确认节点之间三层网络可达，再检查 overlay 所需端口、防火墙、安全组、MTU 和网络驱动状态。不要只看容器内部，因为跨主机问题经常发生在宿主机网络和封装链路上。
转载请注明出处：https://www.cloudnative-tech.com/p/7371/
