继昨天初步搭建 Docker Swarm 集群后，今天的学习重点聚焦在Overlay 网络—— 这个支撑 Swarm 跨节点通信的核心组件。如果说 Swarm 是集群的 “骨架”，那么 Overlay 网络就是连接各个节点的 “血管”，理解它的工作原理对构建稳定的分布式应用至关重要。
Overlay 网络的底层逻辑
Overlay 网络通过在宿主机网络之上构建虚拟网络平面，实现跨节点容器的直接通信。与单机桥接网络不同，它需要满足两个核心需求：服务发现和数据包封装。通过docker network create -d overlay my-overlay创建网络时，Swarm 会自动在所有节点同步网络配置，容器加入后即可通过服务名相互访问。
实验中用 tcpdump 抓包发现，跨节点容器通信的数据包会被封装在 VXLAN 协议中，外层使用宿主机 IP 地址，内层保留容器原始 IP。这种封装机制让容器感觉处于同一局域网，同时隔离了不同 Overlay 网络的流量。
网络模式与安全配置
Overlay 网络有两种工作模式：
- 默认模式：仅允许同一网络内的容器通信，适合简单场景
- attachable 模式：通过--attachable参数创建，允许非 Swarm 管理的容器加入，便于混合部署
安全性方面，可通过--opt encrypted启用网络加密，此时容器间的通信会经过 AES-256 加密。测试显示，加密会增加约 5% 的性能开销，但对于敏感业务是必要的权衡。此外，结合 Swarm 的访问控制列表（ACL），能实现更细粒度的网络隔离。
实战中的网络问题排查
今天部署一个跨节点的 Web+DB 架构时，遇到 Web 容器无法连接数据库的问题。排查步骤如下：
- 用docker network inspect my-overlay确认两个容器都已加入网络
- 在 Web 容器内执行nslookup db-service，发现 DNS 解析正常
- 测试端口连通性时telnet db-service 3306失败，检查发现数据库容器未正确暴露端口
- 重建数据库服务时添加--publish 3306:3306，问题解决
另一个典型问题是节点加入集群后无法同步 Overlay 网络配置，此时需检查节点的/etc/docker/daemon.json是否配置了"cluster-store"参数，确保与集群管理节点的存储后端一致。
性能优化建议
- 避免在 Overlay 网络中传输大文件，此类场景建议使用主机网络（--network host）
- 通过--opt com.docker.network.overlay.vxlan_port=4789固定 VXLAN 端口，便于防火墙规则配置
- 对高频通信的服务，可通过docker service update --constraint-add node.labels.group=web将其调度到同一节点，减少跨节点通信开销
掌握 Overlay 网络后，Swarm 集群的通信黑箱被彻底揭开。明天计划学习 Swarm 的服务发现机制和负载均衡原理，进一步完善集群知识体系。Overlay 网络作为分布式应用的通信基石，其稳定性直接决定了整个系统的可靠性，值得投入更多精力深入研究。
：深入解析交互操作)
