容器网络模型：给容器造一张会说话的网

可视化演示

动态演示容器网络模型的核心机制，通过输入/处理/存储/输出四种模式展示关键概念与交互流程。

网络命名空间：仓库里的独立操作间

我们回到那个物流仓库。假设每个货箱（容器）都是一个独立的小操作间，里面有自己的一套“电话分机系统”——自己的电话线（网卡）、自己的电话本（路由表）、自己的分机号码（IP 地址）。操作间之间如果不接线，谁也联系不上谁。这个“操作间”在 Linux 里就叫网络命名空间（Network Namespace）。

技术上讲，网络命名空间是 Linux 内核提供的一种隔离机制。每个命名空间拥有一套独立的网络协议栈，包括网卡、回环接口、路由表、iptables 规则和套接字等。容器就是利用了这点：每个容器默认都有自己的网络命名空间，所以容器里的进程看到的是“一台只有自己的机器”，端口不会互相冲突。

在 Docker 中，启动容器时如果不特别指定，Docker 会为容器创建一个全新的网络命名空间。这样，容器 A 的 80 端口和容器 B 的 80 端口可以同时存在而不冲突——就像两家快递公司都有“1 号柜”，互不干扰。如果想省掉隔离，可以用 --network=host，容器直接共享宿主机的命名空间，这时端口就会撞车。

1. 命名空间标识：每个网络命名空间在 /proc 下有唯一的 inode 标识

2. 协议栈隔离：网卡、路由表、iptables 各自独立

如果所有容器共享宿主机的网络命名空间，就失去了隔离性——好处是性能极佳，坏处是端口必须全局唯一。所以在生产环境里，我们通常让每个容器有自己的操作间，再用传送带把它们连起来。这个传送带，就是我们下一节要讲的 veth pair。

# 查看当前进程所属的网络命名空间ls -l /proc/self/ns/net

虚拟网络设备：连接操作间的传送带

两个独立操作间怎么互通？我们不可能真的在每个操作间之间拉一根物理网线。Linux 给了我们一种虚拟的“网线”——veth pair。它总是成对出现：想象一根管子，一头在容器 A 的操作间里（叫 veth0），另一头在宿主机或网桥上（叫 veth1）。数据从 veth0 塞进去，就会原封不动地从 veth1 冒出来，反之亦然。

这就是容器与外界通信的第一座桥。但光有传送带还不够，我们需要一个“集散中心”——宿主机上的 docker0 网桥。docker0 是一个虚拟交换机，所有容器的 veth1 端都插到这台交换机上，容器之间就能通过它互相转发数据包，就像包裹在分拣台上按地址投递到不同传送带。

那外部网络怎么访问容器？比如你的 Web 服务跑在容器里，外部用户要访问宿主机的 8080 端口，Docker 会自动设置一条 iptables 规则，把宿主机 8080 端口的流量转发到容器 IP 的 80 端口——这就是 端口映射（-p 8080:80）。这套机制本质上就是数据包的“地址重写”。

1. veth 成对创建：创建 veth0 时自动生成 veth1

2. 流量进出：一端收包，另一端发包，方向相反

当你把容器接入 docker0 网桥后，容器、网桥、宿主机就构成了一个小型二层网络。这个网络默认使用 172.17.0.0/16 网段，容器从网桥动态获取 IP。有了 IP，容器之间就能像同一个小区的邻居一样互相访问——不需要任何额外配置。

# 创建一对 veth 网线ip link add veth0 type veth peer name veth1

CNM 模型：Docker 的仓库管理章程

现在仓库大了，操作间多了，传送带也多了，谁来统一管理这些资源？Docker 提出了 CNM（Container Network Model，容器网络模型）——一套管理容器网络的“章程”。它不是具体代码，而是一份抽象规范，规定了管理网络需要哪几个零件。

CNM 的核心是三个抽象概念：沙箱（Sandbox）、端点（Endpoint） 和网络（Network）。沙箱是一个容器的网络命名空间，是隔离的操作间；网络是可以互通的一组端点集合，相当于一个分拣片区；端点则是沙箱接入网络的“插头”，通常就是一个 veth pair 的容器侧网卡。三者关系是：一个沙箱可以有多个端点，接入多个网络，每个端点属于一个网络。

Docker 发布了若干内置驱动来实现 CNM：bridge 驱动创建 docker0 网桥，让同主机的容器互通；overlay 驱动则用于跨主机的容器通信，它会在所有宿主机之上建立一个大二层网络，让不同机器的容器像在同一个局域网内。还有 host、macvlan 等驱动，分别对应不同的网络诉求。

1. 沙箱（Sandbox）：容器网络栈的载体，即网络命名空间

2. 端点（Endpoint）：连接沙箱与网络的桥梁

3. 网络（Network）：端点的集合，定义了互通边界

CNM 这套章程只服务于 Docker 生态。但随着 Kubernetes 崛起，容器编排需要更开放、更标准的接口——于是 CNI 粉墨登场。CNM 更像是 Docker 的内部管理制度，而 CNI 则是行业的统一语言。

# 查看 Docker 当前的网络docker network ls

CNI 规范：K8s 的插件式插座

如果说 CNM 是 Docker 自己定的“公司章程”，那么 CNI（Container Network Interface，容器网络接口）就是整个容器行业公认的“统一插座标准”。它由 CoreOS 发起，是一个标准化的接口协议。任何网络插件（Flannel、Calico、Weave 等）只要实现了 CNI 规定的接口，就能被 Kubernetes 直接使用。

CNI 规范极其简洁，只定义了两个核心操作：ADD（把容器加入网络）和 DEL（把容器从网络移除）。Kubelet 在启动 Pod 时，会调用 CNI 插件的 ADD 接口，传入容器 ID、网络命名空间等参数，插件负责创建 veth、分配 IP、配置路由，然后返回结果。删除 Pod 时，则调用 DEL 接口做清理。

这种插件化的好处是什么？想象你的仓库需要更换传送带供应商，只要新供应商的接口尺寸符合国家统一标准，你不需要改造整个仓库——拔下旧插头，插上新插头即可。Kubernetes 因此可以灵活选择 Flannel、Calico、Cilium 等任意网络方案，而无需修改核心代码。

1. ADD 操作：插件接收容器 ID 与命名空间，完成网络接入

2. DEL 操作：移除容器网络资源

CNI 的接口设计非常克制，它只关心“连通性”，不关心“网络策略”（那是 NetworkPolicy 的事）。这种克制让它迅速成为行业标准。K8s 的每个 Pod 默认共享一个网络命名空间（pause 容器），CNI 插件只需为 Pod 创建一个 veth，并把另一端接入宿主机网桥即可。

# 查看节点上已安装的 CNI 插件ls /opt/cni/bin/

iptables 规则：仓库的安检与分拣系统

容器网络里，真正做“地址重写”和“流量控制”的，是 Linux 内核里的 iptables。它好比仓库的安检分拣系统：每个进出仓库的包裹都要经过若干检查点（规则链），每个检查点按规则表决定放行、丢弃还是改写地址。

iptables 中最常用的表是 NAT 表，它有两个关键链：PREROUTING（包裹进仓库时先检查）和 POSTROUTING（包裹出仓库时再检查）。Docker 做端口映射，就是在 PREROUTING 链上加了一条 DNAT 规则：把目标地址为宿主机 8080 端口的包，改写为容器 IP 的 80 端口。而容器访问外网时，POSTROUTING 链上的 MASQUERADE 规则会把包的源地址改写成宿主机的 IP，让外部以为请求来自宿主机。

我们用数据包的走向来理解：外部请求到达宿主机 → PREROUTING 链做 DNAT（目标地址改写为容器 IP）→ 数据包经 docker0 网桥转发 → 进入容器。响应包则走反向：容器发出 → POSTROUTING 链做 SNAT（源地址改写为宿主机 IP）→ 返回外部。整个过程中，容器完全不知道自己被“代理”了。

1. DNAT 改写：修改数据包的目标地址

2. SNAT 改写：修改数据包的源地址

iptables 的规则是顺序匹配的：数据包从第一条规则开始逐条比对，命中的先执行，没命中的继续往下走。这也是排查网络问题时最常见的坑——规则顺序错了，包就走了不该走的路。理解了 iptables，你就理解了“端口映射”和“容器上网”的真正幕后黑手。

# 查看 NAT 表规则iptables -t nat -L

网络插件剖析：Flannel 的隧道与 Calico 的路由

最后，我们把目光投向生产环境。Kubernetes 集群通常有几十台机器，Pod 散布在各机器上。Pod 之间要互通，就需要跨主机的容器网络。业界两大主流方案是 Flannel 和 Calico，它们实现 CNI 规范的方式截然不同。

Flannel 的核心思路是“隧道封包”。它给每台宿主机分配一个子网段，比如主机 A 是 10.244.1.0/24，主机 B 是 10.244.2.0/24。当主机 A 上的 Pod 要访问主机 B 上的 Pod 时，Flannel 会把原始数据包整个封装进一个新的 UDP 包（VXLAN 隧道），新包的目标地址是主机 B 的物理 IP。到达主机 B 后，再解封装还原原始包。这就像把一件小包裹塞进一个大集装箱，走铁路（物理网络）运过去，到了再拆箱。

Calico 则完全不同，它走的是“纯路由”路线。Calico 不使用隧道封包，而是把每个宿主机当作一台路由器，通过 BGP（边界网关协议） 在集群内广播路由信息。每台机器都知道“哪个 Pod IP 在哪台机器上”，数据包直接按路由表一跳一跳地送过去，没有额外的封装开销。Calico 还天然支持 NetworkPolicy，可以做细粒度的网络访问控制。

1. VXLAN 封装：原始数据包外套一个新数据包

2. BGP 路由：各节点通过 BGP 交换 Pod 网段路由

选型时怎么取舍？如果集群规模小（<50 节点）、对性能要求不高，Flannel 简单易用、够用就好；如果集群规模大、追求低延迟高吞吐，Calico 的纯路由模式性能更优，但要求底层网络支持 BGP（通常是物理路由器）。理解这两种路线的差异，你在面试和架构设计中就能言之有物。

# 查看 Flannel 分配的 Pod CIDRkubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'

AI 应用场景

Python 演示

"""解析 /proc 文件系统，展示容器网络命名空间与 veth 关系."""import osimport subprocess  def read_link(path):    """读取符号链接指向并返回名称."""    try:        return os.path.basename(os.readlink(path))    except OSError:        return None  def list_network_namespaces():    """列出当前进程可见的网络命名空间."""    hosts = {}    for item in os.listdir('/proc'):        if not item.isdigit():            continue        ns_path = f'/proc/{item}/ns/net'        if not os.path.exists(ns_path):            continue        ident = read_link(ns_path)        hosts.setdefault(ident, []).append(item)    for ident, pids in hosts.items():        print(f'网络命名空间 inode={ident}: PID {pids[:3]}')  def list_veth_interfaces():    """通过 ip 命令列出 veth 网卡."""    out = subprocess.run(        ['ip', '-o', 'link', 'show'],        capture_output=True, text=True    ).stdout    for line in out.splitlines():        if 'veth' in line:            print(line.strip())  def main():    print('=== 当前进程网络命名空间 ===')    print('ns/net ->', read_link('/proc/self/ns/net'))    print()    print('=== 系统中其他命名空间概览 ===')    list_network_namespaces()    print()    print('=== 主机的 veth 网卡 ===')    list_veth_interfaces()  if __name__ == '__main__':    main()

1. os.readlink(os.path.join('/proc', item, 'ns', 'net'))读取进程网络命名空间的符号链接，得到 inode 标识，这就是“操作间编号”
2. hosts.setdefault(ident, []).append(item)把共享同一命名空间的 PID 归组，直观看到哪些进程住在同一间操作间
3. read_link('/proc/self/ns/net')当前 Python 进程自己的命名空间标识
4. subprocess.run(['ip', '-o', 'link', 'show'], capture_output=True, text=True)调用 ip 命令获取所有网卡信息，过滤出 veth 字样
5. line.strip()美化输出，每行显示一个网卡设备
6. if __name__ == '__main__': main()程序入口，保证模块可复用

常见误区

面试题