Docker网络模型：Bridge、Host、Overlay网络模式与跨主机通信原理
聊到Docker的高可用和容灾，网络这块是绕不开的硬骨头。我见过不少团队，容器跑起来了，但网络配置一塌糊涂，结果一遇到故障就全盘崩溃。今天咱们就把Docker的三种核心网络模式掰开揉碎了讲清楚。
一、Bridge网络模式——最常用的“小局域网”
Bridge模式是Docker默认的网络模式。说白了，就是Docker在宿主机上创建一个虚拟网桥（docker0），然后每个容器都连到这个网桥上。
我个人习惯把Bridge模式想象成一个家庭路由器。容器就是家里的设备，docker0就是那个路由器。容器之间可以通过IP互相访问，但外界想访问容器，就得做端口映射。
核心特点：
- 每个容器有自己的网络命名空间
- 容器之间通过docker0网桥通信
- 宿主机外部访问需要端口映射（-p参数）
- 默认支持DNS解析（容器名到IP的映射）
我在项目中遇到过一个问题：两个容器都用了Bridge模式，但其中一个容器需要访问宿主机上的MySQL。很多人会去查MySQL的IP，其实直接用host.docker.internal这个特殊DNS名称就行了。嗯，这个小技巧能省不少事。
# 创建一个自定义Bridge网络
docker network create --driver bridge my-net
# 启动容器并连接到该网络
docker run -d --name web --network my-net nginx
docker run -d --name app --network my-net my-app
# 现在app容器可以直接通过"web"这个名称访问nginx
# 比如在app里执行：curl http://web:80避坑指南：我曾经在生产环境吃过亏——默认的bridge网络不支持容器名DNS解析。如果你想让容器通过名字互相访问，一定要用docker network create创建自定义Bridge网络。默认的那个docker0不行。
二、Host网络模式——性能优先的选择
Host模式就简单粗暴了。容器直接使用宿主机的网络栈，没有自己的IP地址。你想想看，这样性能损耗几乎为零，因为少了一层网络地址转换。
但代价也很明显——端口冲突。如果宿主机上已经有个服务占了8080端口，那容器就别想用这个端口了。
| 对比项 | Bridge模式 | Host模式 |
|---|---|---|
| 网络隔离性 | 强（独立网络命名空间） | 弱（共享宿主机网络） |
| 性能 | 有少量损耗 | 接近原生性能 |
| 端口管理 | 需要映射 | 直接使用宿主机端口 |
| 适用场景 | 大多数应用 | 高性能网络服务、监控代理 |
我建议在两种场景下用Host模式：一是对网络延迟极其敏感的服务（比如高频交易系统），二是需要监控宿主机网络状态的Agent容器。其他情况，老老实实用Bridge吧。
# 使用Host模式启动容器
docker run -d --name nginx-host --network host nginx
# 注意：不需要-p参数，因为容器直接用了宿主机的80端口警告：Host模式下容器拥有宿主机级别的网络权限。如果容器被攻破，攻击者可以直接操作宿主机的网络。安全审计时一定要留意这点。
三、Overlay网络模式——跨主机通信的利器
这才是高可用架构的重头戏。Overlay网络让不同宿主机上的容器能像在同一个局域网里一样通信。原理是什么呢？说白了就是在宿主机网络之上再构建一层虚拟网络。
Docker Swarm模式下，Overlay网络是标配。但即使你不用Swarm，单独用Overlay网络也能实现跨主机通信。
Overlay网络的核心组件：
- VXLAN隧道：把容器数据包封装在UDP包里传输
- 分布式KV存储：保存网络状态信息（consul、etcd等）
- 网络驱动：负责创建和管理Overlay网络
我记得有一次帮客户做异地容灾方案，两个数据中心之间需要容器互通。当时就用了Overlay网络配合VXLAN隧道，效果还不错。不过要注意，跨机房时延迟会明显增加，这个要有心理准备。
# 前提：Docker Swarm集群已初始化
# 在Swarm中创建Overlay网络
docker network create -d overlay --attachable my-overlay
# 在不同宿主机上启动容器，连接到同一个Overlay网络
# 宿主机A：
docker run -d --name app1 --network my-overlay my-app
# 宿主机B：
docker run -d --name app2 --network my-overlay my-app
# 现在app1和app2可以直接通过容器名通信四、跨主机通信原理——数据包是怎么“穿越”的
咱们来拆解一下跨主机通信的完整流程。假设容器A在宿主机1上，容器B在宿主机2上，它们都在同一个Overlay网络中。
- 容器A发出数据包：目标IP是容器B的Overlay网络IP
- 数据包到达veth设备：从容器A的eth0到宿主机1的vethxxx
- 进入Overlay网络栈：数据包被封装成VXLAN格式
- 添加外层UDP头：目标UDP端口是4789（VXLAN标准端口）
- 通过物理网络发送：数据包从宿主机1的eth0发出去
- 宿主机2接收：解封装VXLAN，还原原始数据包
- 交付给容器B：通过veth设备进入容器B的网络命名空间
你想想看，整个过程其实就是在原始数据包外面套了一层“马甲”。这个马甲上写着宿主机2的IP地址，这样物理网络才能把它送到正确的地方。
性能优化建议：我曾经在压测时发现Overlay网络的吞吐量比Bridge低了约15%。如果对性能要求极高，可以考虑用Macvlan模式，它直接给容器分配物理网络的IP地址，绕过了Overlay的封装开销。
五、生产环境选型建议
说了这么多，到底该怎么选？我根据自己的经验总结了一个简单的决策树：
- 单机部署：用Bridge模式，创建自定义网络
- 需要高性能：考虑Host模式（注意安全风险）
- 跨主机通信：Overlay网络是首选
- 需要直接使用物理网络IP：Macvlan模式
- Kubernetes环境：用CNI插件（如Calico、Flannel），它们底层也是Overlay或路由模式
容灾设计要点：在做高可用架构时，网络层面一定要考虑单点故障。比如Overlay网络依赖的KV存储，必须做集群部署。我曾经见过一个案例，consul挂了，整个Overlay网络都瘫痪了，所有跨主机通信全部中断。嗯，这个教训挺深刻的。
最后说一句，网络模式的选择没有银弹。你得根据业务场景、性能要求、安全等级来权衡。我个人习惯是先画网络拓扑图，把流量路径走一遍，再决定用哪种模式。这样能避免很多后期踩坑的情况。