腾讯云

文章/答案/技术大牛

发布

社区首页 >专栏 >浅谈容器网络

浅谈容器网络

原创

rxg456

发布于 2025-03-31 16:46:35

8301

代码可运行

文章被收录于专栏：想法独特的Dev+Ops想法独特的Dev+Ops

运行总次数：1

代码可运行

容器技术通过轻量化的资源隔离机制，极大地简化了应用部署的复杂性。而容器网络作为容器生态的核心组件，直接影响着容器间通信、服务发现及跨主机协同的能力。本文将从容器网络的基础组件出发，逐步剖析其工作原理及关键实现。

一、容器网络栈：隔离的基石

所谓网络栈，就包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。

使用宿主机的网络栈（–net=host），即：不开启 Network Namespace，比如：

docker run -d --net=host --name nginx-host nginx:demo

二、容器的网络隔离：命名空间的魔法

每个容器启动时都会创建独立的网络命名空间（Network Namespace），形成完全隔离的网络栈，包含以下核心组件：

虚拟网卡（veth pair） 容器通过一对虚拟网卡（veth）与宿主机通信。例如，容器内的eth0 网卡通过 veth 对连接到宿主机的虚拟网桥（如 docker0）。这种设计使得容器流量能够通过宿主机网络栈转发。
回环设备（lo） 容器内部的 lo 设备用于本机进程间通信（如访问 localhost 服务），与宿主机回环设备完全隔离。
路由表 容器的路由表决定了流量的转发路径。例如，默认路由指向 eth0，将出站流量导向宿主机的网桥；特定服务的路由规则可实现精细的流量控制。
iptables 规则 iptables 负责网络地址转换（NAT）和流量过滤。例如，Docker 默认通过 MASQUERADE 规则将容器出站流量伪装为宿主机 IP，实现外网访问；FORWARD 链规则控制容器间的通信权限。

网络命名空间机制实现不同容器的隔离

独立网络设备：每个容器拥有自己的 eth0、lo 等设备，与其他容器不可见。
隔离的路由与防火墙：容器内修改路由表或 iptables 规则不会影响宿主机或其他容器。
端口冲突规避：不同容器可绑定相同端口（如 80），通过宿主机端口映射（如 -p 8080:80）暴露服务。

三、容器间的网络通信

容器间的网络通信本质上是通过虚拟化技术模拟多机通信场景实现的。我们可以将容器视为独立主机，通过虚拟交换机（网桥）和虚拟网线（Veth Pair）构建通信链路。以下通过一个具体场景解析其完整流程：

3.1 架构示例

宿主机上运行两个容器 ContainerA 和 ContainerB，二者通过 docker0 网桥互联

+-------------------------------------------------+
|                   宿主机                         |
|  +------------+              +------------+     |
|  | ContainerA |              | ContainerB |     |
|  | eth0@vethA |              | eth0@vethB |     |
|  +-----↑------+              +-----↑------+     |
|        ↓                           ↓            |
|  +-----↓---------------------------↓------+     |
|  |           docker0网桥 (172.17.0.1)      |     |
|  +----------------------------------------+     |
+-------------------------------------------------+

3.2 核心组件协同工作原理

（1）Veth Pair：跨命名空间的"网线"

创建过程

当容器启动时，Docker 会创建一对 Veth Pair（如 vethA 和 vethA-peer）

# 宿主机查看Veth Pair（vethA-peer在容器内被重命名为eth0）
# ip link show | grep -n2 veth
12: veth6f43f82@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 3e:30:83:c4:92:54 brd ff:ff:ff:ff:ff:ff link-netnsid 0
13: veth2cb4daf@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 36:e5:74:e0:27:80 brd ff:ff:ff:ff:ff:ff link-netnsid 1

vethA-peer 被放入容器的 Network Namespace，重命名为 eth0
vethA 保留在宿主机，连接到 docker0 网桥

数据流动

当 ContainerA 向 ContainerB 发送数据包：

容器内 eth0（即 vethA-peer）发出数据包
通过 Veth Pair 直接传递到宿主机的 vethA
docker0 网桥接收并转发数据包到 vethB

（2）网桥：基于 MAC 地址的二层转发

MAC 学习机制 网桥维护 MAC 地址表（可通过 brctl showmacs docker0 查看），记录端口与 MAC 的映射关系：

MAC地址	端口
3e:30:83:c4:92:54	vethA
36:e5:74:e0:27:80	vethB

  # brctl showmacs docker0
  port no mac addr                is local?       ageing timer
    2     26:12:cf:e4:da:80       no               297.59
    2     36:e5:74:e0:27:80       yes                0.00
    2     36:e5:74:e0:27:80       yes                0.00
    1     3e:30:83:c4:92:54       yes                0.00
    1     3e:30:83:c4:92:54       yes                0.00
    
  字段说明
  port no:  网桥端口编号，对应连接到网桥的接口
  mac addr: 学习到的 MAC 地址
  is local?:
  	yes:  表示该 MAC 地址属于宿主机本地接口（如网桥自身或直接连接的 Veth 宿主机端）
  	no:   表示该 MAC 地址是外部学习到的（如容器内部的 Veth 设备）
  ageing timer: 条目剩余存活时间（秒），归零后删除。0.00 表示该条目被标记为永久或刚被更新

转发决策

若目标 MAC 存在于表中，数据包直接转发到对应端口
若未知 MAC，进行泛洪（Flood）广播到所有端口（除来源端口）

（3）IP 通信的完整流程

以 ContainerA(172.17.0.2) 访问 ContainerB(172.17.0.3) 为例：

ARP 请求（二层发现） ContainerA 通过广播查询 172.17.0.3 的 MAC 地址。
网桥泛洪广播 网桥将 ARP 请求广播到所有连接的容器，ContainerB 响应其 MAC。
建立 TCP 连接（四层通信） MAC 地址已知后，通过 IP 和端口进行应用层通信。

3.3 实验验证

手动模拟容器通信：

# 创建两个Network Namespace
ip netns add ns1
ip netns add ns2

# 创建Veth Pair并分配到Namespace
ip link add veth1 type veth peer name veth1-peer
ip link set veth1-peer netns ns1
ip netns exec ns1 ip link set veth1-peer name eth0

ip link add veth2 type veth peer name veth2-peer
ip link set veth2-peer netns ns2
ip netns exec ns2 ip link set veth2-peer name eth0

# 创建网桥并连接Veth
brctl addbr mybridge
brctl addif mybridge veth1
brctl addif mybridge veth2

# 启动设备
ip link set mybridge up
ip link set veth1 up
ip link set veth2 up

# 配置容器IP
ip netns exec ns1 ip addr add 10.0.0.1/24 dev eth0
ip netns exec ns1 ip link set eth0 up
ip netns exec ns2 ip addr add 10.0.0.2/24 dev eth0
ip netns exec ns2 ip link set eth0 up

# 测试连通性
ip netns exec ns1 ping 10.0.0.2

观察Docker实际环境：

# 查看docker0网桥信息
# brctl show docker0
bridge name     bridge id               STP enabled     interfaces
docker0         8000.7a2a35e08d9f       no              veth2cb4daf
                                                        veth6f43f82

定位Veth Pair对应的容器：

1.获取Veth接口索引号
# ip link show veth2cb4daf
13: veth2cb4daf@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 36:e5:74:e0:27:80 brd ff:ff:ff:ff:ff:ff link-netnsid 1
说明：
13:：宿主机上 veth2cb4daf 接口的索引号为 13
@if2 表示其对端接口在另一个网络命名空间的索引为2
link-netnsid 1 表示该Veth对端所在的网络命名空间ID（需结合其他命令解析）


2.列出所有容器的网络命名空间
# ls -l /var/run/docker/netns/
total 0
-r--r--r-- 1 root root 0 Mar 31 23:32 426133a3ab9c
-r--r--r-- 1 root root 0 Mar 31 22:45 default
-r--r--r-- 1 root root 0 Mar 31 23:32 e1f62106d430

3.进入容器网络命名空间验证
# nsenter --net=/var/run/docker/netns/426133a3ab9c ip link show eth0
2: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 26:12:cf:e4:da:80 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    
@if13 对应宿主机的 veth2cb4daf 接口索引号13，确认Veth Pair关系。

四、容器无法互通的排查指南

基础环境确认

# 确认两个容器在同一子网
docker inspect <容器ID> | grep IPAddress

# 确认docker0网桥的子网
ip addr show docker0

检查容器路由表

# 进入容器Network Namespace检查路由
nsenter --net=/var/run/docker/netns/<容器netns> ip route

异常处理：
- 若缺少默认路由：重建容器或检查Docker守护进程配置
- 若目标IP路由错误：检查容器启动时的 --network 参数

验证ARP表

# 容器A中查询容器B的ARP记录
nsenter --net=/var/run/docker/netns/<容器A-netns> arp -n | grep 172.17.x.x

# 容器B中查询容器A的ARP记录
nsenter --net=/var/run/docker/netns/<容器B-netns> arp -n | grep 172.17.x.x

正常现象：应显示对方IP对应的MAC地址
ARP未学习：
- 检查网桥是否禁用学习功能（brctl setageing docker0 0 会关闭学习）

检查网桥MAC学习表

brctl showmacs docker0 | grep -E '3e:30:83:c4:92:54|26:12:cf:e4:da:80' # 示例MAC

正常现象：两个容器的MAC地址应出现在不同端口的 is local?=no 条目。
异常处理：
- 若MAC未学习：重启网桥 ip link set docker0 down && ip link set docker0 up
- 若MAC冲突：重启冲突容器

跨命名空间抓包分析

# 宿主机抓取veth接口流量（容器A的宿主机端Veth）
tcpdump -i veth123456 -nn -e icmp

# 容器内抓包（进入容器Network Namespace）
nsenter --net=/var/run/docker/netns/<容器B-netns> tcpdump -i eth0 -nn -e icmp

正常现象：
- 容器A发出的ICMP请求应出现在宿主机veth接口和容器B的eth0
- 容器B的响应应出现在反向路径
常见异常：
- 单向流量：检查iptables规则是否丢弃数据包
- 无任何流量：检查veth接口状态（ip link show veth123456）