Network Mode

Docker的网络模式决定了容器如何与宿主机、其他容器以及外部网络进行通信。

Docker主要提供了以下五种网络模式，默认创建的是 bridge 模式。

1. Bridge 模式

这是 默认 的网络模式。当你创建一个容器而不指定网络时，它就会连接到这个默认的 bridge 网络（名为 bridge）。

• 工作原理：Docker守护进程会创建一个名为 docker0 的虚拟网桥，它相当于一个虚拟交换机。所有使用该模式的容器都会通过一个虚拟网卡（veth pair）连接到这个网桥上。Docker会为每个容器分配一个IP地址，并配置其网关为 docker0 的地址。
• 通信方式：
  • 容器间通信：在同一个自定义桥接网络下的容器，可以通过容器名（Container Name）直接通信（Docker内嵌了DNS）。但在默认的 bridge 网络下，容器只能通过IP地址通信。
  • 访问外部网络：容器数据包通过 docker0 网桥，再经过宿主机的IPtables进行NAT转换，使用宿主机的IP访问外网。
  • 从外部访问容器：需要做端口映射，例如 -p 8080:80，将宿主机的8080端口映射到容器的80端口。

优劣分析

• 优点：
  • 隔离性：容器拥有独立的网络命名空间，与宿主机和其他网络隔离，安全性较好。
  • 端口管理灵活：通过端口映射，可以灵活地管理哪些宿主机端口暴露给外部。
  • 通用性：是最常用、最通用的模式，适合大多数应用场景。
• 缺点：
  • 性能开销：相比 host 模式，多了一层网络桥接和NAT，性能有轻微损失。
  • 复杂度：在默认桥接网络中，容器间通信需要使用IP，不如自定义网络方便。

使用场景：绝大多数需要网络隔离的独立应用，例如Web后端服务、数据库等。

命令示例：

# 使用默认bridge网络（不推荐用于多容器应用）
docker run -d --name my-app -p 8080:80 nginx

# 创建自定义bridge网络（推荐）
docker network create my-network
docker run -d --name app1 --network my-network my-app
docker run -d --name app2 --network my-network another-app
# 现在 app1 和 app2 可以通过容器名直接互相访问

2. Host 模式

在这种模式下，容器不会虚拟出自己的网卡，也不会分配独立的IP，而是直接使用宿主机的IP和端口。

• 工作原理：容器与宿主机共享同一个Network Namespace。

优劣分析

• 优点：
  • 高性能：由于没有NAT和网桥开销，网络性能最高，几乎与宿主机原生网络一致。
  • 简单：无需进行复杂的端口映射，容器内使用的端口就是宿主机上的端口。
• 缺点：
  • 安全性差：容器没有网络隔离，可以直接操作宿主机的网络。
  • 端口冲突：容器使用的端口如果与宿主机服务冲突，会导致容器无法启动。
  • 灵活性差：无法在同一台宿主机上运行多个使用相同端口的容器。

使用场景：对网络性能要求极高的场景，例如负载均衡器、高频交易系统等。在生产环境中需谨慎使用。

命令示例：

docker run -d --name my-app --network host nginx
# 此时，直接访问 http://<宿主机IP>:80 即可访问容器中的Nginx

3. None 模式

在这种模式下，容器拥有自己独立的网络命名空间，但不进行任何网络配置。容器内部只有回环地址 127.0.0.1。

• 工作原理：容器完全与世隔绝。

优劣分析

• 优点：
  • 绝对隔离：安全性最高，容器完全无法进行任何网络通信。
• 缺点：
  • 无法联网：容器无法与宿主机、其他容器或外部网络通信。

使用场景：

1. 需要完全离线处理的批处理任务。
2. 用户打算使用自定义网络驱动（或手动配置）来完全自定义容器的网络栈。

命令示例：

docker run -d --name my-app --network none alpine
# 进入容器后，使用 `ip addr` 查看，只能看到 lo 网卡

4. Container 模式

这种模式下，新创建的容器不会创建自己的网卡和IP，而是与一个已经存在的容器共享一个Network Namespace。通俗讲，就是两个容器在同一个网络环境下，看到的IP和端口是一样的。

• 工作原理：新容器复用指定容器的网络栈。

优劣分析

• 优点：
  • 高效通信：容器间通信直接通过本地回环地址 127.0.0.1，效率极高。
  • 共享网络视图：可以方便地为一个主容器（如Web服务器）搭配一个辅助容器（如日志收集器），它们看到的网络环境完全一致。
• 缺点：
  • 紧密耦合：两个容器的生命周期和网络配置紧密绑定，缺乏灵活性。
  • 隔离性差：共享网络命名空间，存在一定的安全风险。

使用场景：Kubernetes中的"边车"模式，例如一个Pod内的主容器和日志代理容器。

命令示例：

docker run -d --name main-container nginx
docker run -d --name helper-container --network container:main-container busybox
# 此时，helper-container 中访问 127.0.0.1:80 就是在访问 main-container 的Nginx服务

5. Overlay 模式

这是为了实现 跨主机的容器通信 而设计的，是Docker Swarm和Kubernetes等容器编排系统的核心网络方案。

• 工作原理：它会在多个Docker宿主机之间创建一个虚拟的分布式网络（Overlay Network），通过VXLAN等隧道技术，让不同宿主机上的容器感觉像是在同一个大的局域网内。

优劣分析

• 优点：
  • 跨节点通信：解决了集群环境下容器间通信的根本问题。
  • 安全：支持网络加密。
• 缺点：
  • 配置复杂：需要额外的Key-Value存储（如Consul、Etcd）来同步网络状态（Docker Swarm模式内置了此功能）。
  • 性能开销：数据包需要封装和解封装，有一定性能损耗，但现代硬件上通常可以接受。

使用场景：Docker Swarm集群、Kubernetes集群等分布式应用环境。

命令示例（在Swarm模式下）：

# 初始化Swarm
docker swarm init

# 创建Overlay网络
docker network create -d overlay my-overlay-net

# 在Overlay网络中创建服务
docker service create --name web --network my-overlay-net -p 80:80 nginx

总结对比

最佳实践建议

1. 单机应用：优先使用 自定义的Bridge网络，它比默认Bridge网络提供了更好的DNS服务发现功能，方便容器间通过名称通信。
2. 集群应用：必须使用 Overlay网络。
3. 性能极致追求：在确认端口安全和无冲突的前提下，可考虑 Host模式。
4. 安全隔离：对于无需网络的容器，使用 None模式。
5. 避免在生产环境大量使用默认的bridge网络和container模式，因为它们分别在DNS发现和容器耦合度上存在不足。