从零手动搭建容器网络：Linux网桥与veth原理深度解析

为什么容器网络值得深入理解

执行 docker run 启动一个容器后，它能访问外网、与其他容器通信，甚至对外暴露端口服务——这一切看似理所当然。但在这份「魔法」背后，是 Linux 内核提供的一整套网络原语在默默支撑。

真正理解容器网络的底层机制，不仅能帮你快速排查「容器无法联网」「端口映射失效」等高频故障，更是掌握 Kubernetes 网络模型、CNI 插件乃至服务网格的必备基础。

本文以「从零手动搭建一个 Linux 网桥（Bridge）网络」为主线，逐层拆解容器网络的核心构件，带你看清 Docker 默认 bridge 模式背后的完整真相。

容器网络的三块核心积木

容器网络的隔离与连通，并非依赖某种全新技术，而是巧妙组合了 Linux 内核早已成熟的三项能力。理解这三个基础组件，是看懂整个体系的前提。

网络命名空间（Network Namespace）

网络命名空间是容器网络隔离的基石。每个命名空间拥有完全独立的网络栈——包括自己的网络接口、路由表、iptables 规则和端口空间。Docker 创建容器时，会为其分配一个独立的网络命名空间，使容器内的 eth0 与宿主机网络接口完全互不干扰。

网络命名空间是 Linux Namespace 机制七种隔离类型之一（另外六种为 Mount、UTS、IPC、PID、User、Cgroup），在 Linux 内核 3.0 之后趋于成熟。其隔离是彻底的：每个命名空间拥有独立的 /proc/net 目录、独立的 socket 表和 ARP 缓存，内核通过 /proc/<pid>/ns/net 下的文件描述符以引用计数方式管理命名空间的生命周期。这也是为什么在容器内执行 netstat 或 ss 只能看到本容器网络连接的根本原因。

延伸背景：Linux Namespace 的演进历史 Linux Namespace 机制并非一次性完成的设计，而是历经十余年逐步演进的成果。最早的 Mount Namespace 在 2002 年随内核 2.4.19 引入，而网络命名空间直到 2009 年前后的内核 2.6.24–2.6.29 系列才趋于可用，并在 3.0 之后达到生产级稳定性。这种渐进式演进反映了 Linux 社区「最小化内核改动、复用现有抽象」的一贯哲学。七种命名空间类型相互正交，可以独立组合，这赋予了容器运行时极大的灵活性——例如 Docker 默认共享 UTS 命名空间以便容器看到宿主机名，而 Kubernetes 的 hostNetwork 模式则直接复用宿主机的网络命名空间，彻底绕过虚拟网络层以获得最低延迟。

手动操作时，可用 ip netns add <name> 创建命名空间，用 ip netns exec <name> <command> 在其中执行命令。这是「从零构建」的第一步：为「容器」划出一块独立的网络疆域。

虚拟网卡对（veth pair）

有了隔离的命名空间，随之而来的问题是：如何让它与外界通信？答案是 veth pair。veth（Virtual Ethernet）设备总是成对出现，可以把它理解成一根虚拟网线的两端——数据从一端进入，必然从另一端流出。

典型做法是：将 veth 的一端放入容器的网络命名空间（作为容器内的 eth0），另一端保留在宿主机侧。容器内发出的数据包便能通过这根「虚拟网线」抵达宿主机，为接入网桥做好准备。

veth pair 在内核中通过 drivers/net/veth.c 实现为一对相互绑定的虚拟设备，数据传输完全在内核内存中完成，无需经过物理硬件。发送端调用 dev_queue_xmit() 入队后，接收端通过 NAPI 轮询机制直接从对端取包，整个过程不涉及 DMA 或硬件中断，因此延迟极低，吞吐量上限通常受 CPU 处理能力而非带宽约束。这也解释了为什么同宿主机容器间通信的网络性能远高于跨主机通信。

延伸背景：veth pair 的性能调优方向 在高吞吐场景下，veth pair 的性能瓶颈通常不在带宽，而在 CPU 的软中断处理开销。现代内核通过 Generic Segmentation Offload（GSO）和 Generic Receive Offload（GRO）对 veth 进行了专项优化，允许内核在发送大块数据时延迟分片，减少系统调用次数。此外，XDP（eXpress Data Path）技术的引入使得数据包可以在内核网络栈最早期阶段被处理，绕过大部分协议栈开销——Cilium 等新一代 CNI 插件正是利用这一特性，在保留 veth 拓扑的同时将转发路径的 CPU 开销压缩到传统 iptables 方案的数分之一。

Linux 网桥（Bridge）

如果说 veth pair 解决了「点对点」连接问题，那么网桥则负责「多点互联」。Linux Bridge 本质上是一个工作在二层的虚拟交换机，可以将多个网络接口挂载到同一个广播域，让接入设备彼此通信。

Linux Bridge 在内核中由 bridge 模块实现，其工作机制与物理交换机高度相似：维护一张 MAC 地址学习表（FDB，Forwarding Database），通过泛洪（flooding）学习未知目标 MAC 的位置，再按表转发已知目标。在 Docker 环境中，由于网络拓扑简单且无环路风险，STP（生成树协议）通常被禁用（可通过 brctl showstp br0 确认），以避免 STP 收敛延迟导致容器启动后短暂无法通信的问题。此外，网桥本身也可以配置 IP 地址，此时它同时充当二层交换与三层路由的角色，这正是它作为容器默认网关的技术基础。

Docker 默认的 docker0 就是这样一个网桥。每启动一个容器，Docker 创建一对 veth，将宿主机侧的一端挂到 docker0 上。这正是同一宿主机上、同一网络下的多个容器能够互相 ping 通的根本原因。

动手实验：一步步手动复现容器网络

理论之后，最好的学习方式是亲手复现。以下步骤精确还原了 Docker 在幕后自动完成的全部网络配置工作。

第一步：创建网桥与网络命名空间

在宿主机上创建 Linux 网桥并启用：

ip link add br0 type bridge
ip link set br0 up

创建一个模拟容器的网络命名空间：

ip netns add container1

此时 container1 拥有完全隔离的网络环境，但还是一座「孤岛」，无法与任何外界通信。

第二步：用 veth pair 连接命名空间与网桥

创建一对 veth，将一端放入命名空间，另一端接入网桥：

ip link add veth-host type veth peer name veth-c1
ip link set veth-c1 netns container1
ip link set veth-host master br0
ip link set veth-host up

进入命名空间，为内部接口配置 IP 并启用：

ip netns exec container1 ip addr add 172.18.0.2/24 dev veth-c1
ip netns exec container1 ip link set veth-c1 up
ip netns exec container1 ip link set lo up

完成这一步后，「容器」便通过 veth 接入了网桥，与其他挂载在同一网桥上的命名空间实现了二层互通。

第三步：打通外网访问（网关 + NAT）

容器访问外网还需两个关键配置。首先为网桥分配 IP 并设置为容器默认网关：

ip addr add 172.18.0.1/24 dev br0
ip netns exec container1 ip route add default via 172.18.0.1

接着配置 iptables MASQUERADE 规则，让容器发出的私有网段数据包在离开宿主机时被自动转换成宿主机 IP：

iptables -t nat -A POSTROUTING -s 172.18.0.0/24 ! -o br0 -j MASQUERADE

MASQUERADE 是 SNAT（Source NAT）的一种特殊形式，两者均位于 iptables nat 表的 POSTROUTING 链中。与需要显式指定固定源 IP 的 SNAT 不同，MASQUERADE 会动态获取出口网卡的当前 IP 作为转换源地址，适合宿主机 IP 可能变化的场景。其代价是每次新建连接时需查询出口接口 IP，在极高并发场景下可考虑改用 SNAT 以获得微小的性能提升。

延伸背景：conntrack 连接跟踪与 NAT 的工作原理 iptables 的 NAT 功能离不开 netfilter 的连接跟踪模块（conntrack）。当第一个数据包触发 MASQUERADE 规则时，conntrack 会在内核中建立一条五元组记录（源IP、源端口、目的IP、目的端口、协议），后续属于同一连接的数据包直接查表转换，无需再次遍历规则链。这是容器网络能够维持有状态 TCP 连接的关键机制。然而在大规模集群场景下，conntrack 表的容量限制（由 nf_conntrack_max 参数控制，默认通常为 65536）和哈希表锁竞争会成为显著的性能瓶颈——这也是 Kubernetes 社区推动从 iptables 向 eBPF/nftables 迁移的核心动机之一。排查 NAT 异常时，可通过 conntrack -L 命令查看当前跟踪表状态，conntrack -S 查看统计信息中的 insert_failed 计数以判断是否存在表满丢包。

最后开启内核 IP 转发，允许数据包在不同网络接口间流转：

echo 1 > /proc/sys/net/ipv4/ip_forward

至此，一个功能完整、能够访问外网的「容器网络」便手工搭建完成——而这正是 Docker 默认 bridge 模式在幕后所做的全部工作。

对照 Docker：手动步骤与自动化的映射关系

回头对照手动步骤，可以清晰看到 Docker 的自动化逻辑：它在容器启动时自动创建 docker0 网桥、为每个容器分配独立的网络命名空间与 veth pair、通过 IPAM 管理 IP 地址分配，并自动写入相应的 iptables NAT 规则。端口映射（-p 8080:80）的本质，则是一条 iptables DNAT 规则，将宿主机指定端口的入站流量转发到容器内部端口。

理解了这层映射关系，许多常见问题便迎刃而解：

• 容器能访问外网，外网却无法主动访问容器？ MASQUERADE 只处理出向流量，入向访问必须配置显式的端口映射（DNAT 规则）才能生效。
• 同宿主机的容器为何默认互通？ 因为它们挂载在同一个 docker0 网桥上，处于同一广播域，二层直接可达。
• 端口映射失效如何排查？ 优先检查 iptables NAT 表中的 DNAT 规则是否存在，以及 IP 转发（ip_forward）是否开启，通常能快速定位问题根源。

打好地基，后续学习事半功倍

容器网络看似复杂，实则是网络命名空间、veth pair、Linux 网桥与 iptables 这几块「积木」的精巧组合。当你能够徒手复现 Docker 默认网络时，便意味着真正掌握了容器网络的第一性原理。

这份底层认知的价值，会随着技术栈的深入而持续放大。CNI（Container Network Interface）是 CNCF 定义的容器网络标准接口规范，规定网络插件需实现 ADD、DEL、CHECK 三个操作。Flannel 的 host-gw 模式本质上是在每个节点操作路由表，将跨节点 Pod 网段指向对应宿主机 IP，底层仍依赖 veth pair 和网桥；其 VXLAN 模式则在此基础上通过 VTEP 设备在 UDP 包中封装二层帧，实现跨二层域的 overlay 网络。Calico 则完全放弃网桥，通过 BGP 协议分发路由并直接以 veth 宿主机端作为路由下一跳，在保持纯三层路由的同时获得更高转发性能。

延伸背景：CNI 插件的技术分野与选型逻辑 CNI 规范本身极为精简，其设计刻意回避了对底层实现的约束，仅规定插件需以可执行文件形式存在、通过标准输入接收 JSON 配置、通过环境变量获取容器命名空间路径。这种「接口最小化」的设计使得 CNI 生态呈现出显著的技术分野：以 Flannel 为代表的 overlay 方案优先考虑网络拓扑兼容性，牺牲部分性能换取跨异构网络的部署能力；以 Calico 为代表的 underlay/BGP 方案则在网络基础设施可控的前提下追求最高转发效率；而 Cilium 代表的 eBPF 方案则试图从根本上替换 netfilter 路径，在保持灵活策略能力的同时将转发延迟压缩至接近内核旁路水平。选择 CNI 插件本质上是在运维复杂度、网络性能与基础设施约束三个维度之间做权衡决策，而无论哪种方案，其实现思路都建立在你刚刚手动搭建的那套网络原语之上。

无论哪种 CNI 插件，其实现思路都是在网络命名空间、veth pair 和路由/iptables 这些基础原语之上的进一步抽象与扩展。地基打牢，进阶学习自然水到渠成。

核心要点

• 网络命名空间提供彻底的网络栈隔离，是容器化的根基；七种 Linux Namespace 类型相互正交，可灵活组合。
• veth pair 是连通命名空间与外部网络的「虚拟网线」，传输发生在内核内存中，延迟极低。
• Linux Bridge 充当二层虚拟交换机，维护 FDB 表实现多容器互联，同时可作为三层网关。
• iptables MASQUERADE + conntrack 是容器访问外网的关键，conntrack 表容量是大规模场景下的潜在瓶颈。
• Docker 的自动化本质上是上述手动步骤的程序化封装，端口映射即 DNAT 规则；理解手动步骤是排障的最短路径。
• CNI 插件无论如何演进，均建立在这套基础原语之上；掌握底层，选型与排障将更加游刃有余。