3. CNI 网络基础回顾：CNI 插件架构、Pod 网络模型、网络命名空间与 veth pair

在深入集群升级场景下的镜像拉取优化之前，必须重新夯实 CNI 网络的核心基础。本章将聚焦三个关键层次：CNI 插件架构（控制面与数据面的解耦）、Pod 网络模型（每个 Pod 拥有独立 IP 的扁平网络）、以及网络命名空间与 veth pair（实现容器与宿主机网络互通的基本单元）。理解这些基础，才能准确诊断升级过程中因 CNI 插件重启、路由表刷新或 veth 重建引发的镜像拉取延迟。

3.1 CNI 插件架构：从 kubelet 到网络配置的标准化接口

CNI（Container Network Interface）是 Kubernetes 与网络插件之间的契约接口。它定义了 kubelet 如何调用插件为 Pod 配置网络，以及插件应返回哪些信息。其核心架构遵循“调用-配置-返回”的线性模型，不涉及守护进程或长期运行的 agent（部分插件如 Calico 的 Felix 除外，但 CNI 接口本身是无状态的）。

下图展示了 kubelet 通过 CNI 接口调用插件为 Pod 配置网络的标准流程：

3.2 Pod 网络模型：每个 Pod 一个 IP 的扁平网络

Kubernetes 的 Pod 网络模型遵循以下核心原则：

• 每个 Pod 拥有一个独立的 IP 地址，该 IP 在集群内全局可达（无需 NAT）。
• Pod 内的所有容器共享同一个网络命名空间，包括 IP、端口、路由表。
• Pod 之间可以直接通信，无论它们位于同一节点还是不同节点。
• Pod 与宿主机之间也可以直接通信（通过宿主机 IP 或 Pod IP）。

下表对比了不同 CNI 插件实现 Pod 网络模型的方式：

3.3 网络命名空间与 veth pair：容器网络的基石

每个 Pod 拥有独立的网络命名空间（netns），其中包含自己的网络栈（lo 接口、路由表、iptables 规则等）。Pod 内的容器共享这个 netns，而 Pod 与宿主机之间通过 veth pair（虚拟以太网对）连接。

veth pair 是一对虚拟网卡，数据包从一端进入会直接从另一端出来，类似于一根虚拟网线。一端放在 Pod 的 netns 中（通常命名为 eth0），另一端放在宿主机的根网络命名空间中（通常命名为 vethXXXXX），并连接到 CNI 创建的网桥（如 cni0）或直接配置路由。

下图展示了 Pod 网络命名空间与宿主机通过 veth pair 连接的详细结构：

3.4 网络命名空间操作与调试命令

在集群升级前后，运维人员需要频繁检查 Pod 的网络命名空间状态。以下命令是必备技能：

# 查看 Pod 的网络命名空间（在 Pod 所在节点执行）
# 方法1：通过 crictl 获取 Pod 的 netns 路径
crictl inspectp <POD_ID> | grep -i netns

# 方法2：通过 /proc 文件系统直接查看
PID=$(crictl inspectp <POD_ID> | grep -i pid | awk '{print $2}' | tr -d ',')
ls -l /proc/$PID/ns/net

# 进入 Pod 的网络命名空间执行命令
nsenter -t $PID -n ip addr
nsenter -t $PID -n ip route
nsenter -t $PID -n iptables -t nat -L -n

# 查看宿主机上的 veth pair 对应关系
ip link show type veth
ethtool -S vethXXXXX  # 查看 veth 接口统计信息（丢包、错误等）

3.5 本章小结