2. CNI 插件架构：CNI 标准接口、容器运行时与网络插件的交互流程

容器网络接口（CNI, Container Network Interface）是 Kubernetes 生态中事实上的网络标准。理解 CNI 的架构设计，是排查网络缓存命中故障、分析 Calico 策略生效路径的前提。本节从接口规范、组件角色、交互流程三个维度展开。

2.1 CNI 标准接口规范

CNI 定义了一组 容器运行时 与 网络插件 之间的契约。该契约以 JSON 格式的配置文件、标准输入（stdin）参数和环境变量为载体，规定了插件必须实现的四个操作：

2.2 核心组件角色与职责

一次完整的容器网络接入涉及三个角色：

• 容器运行时（Container Runtime）：如 containerd、CRI-O。负责调用 CNI 插件，传递网络命名空间路径、容器 ID、网络配置等参数。
• CNI 配置管理（Config Manager）：通常由 kubelet 内置的 cniConfig 模块承担。读取 /etc/cni/net.d/ 目录下的配置文件，决定调用哪个插件及调用顺序。
• CNI 插件（Plugin）：分为三类：
  • Main 插件：负责创建网络设备（如 bridge、veth、ipvlan）。
  • IPAM 插件：负责 IP 地址分配（如 host-local、calico-ipam）。
  • Meta 插件：负责组合多个插件（如 flannel、calico 的 CNI 入口）。

2.3 交互流程：从 Pod 创建到网络就绪

下图展示了 kubelet 收到 Pod 创建请求后，容器运行时与 CNI 插件之间的完整交互路径：

2.4 链式调用与插件组合

Kubernetes 支持 CNI 链式调用（Chaining），即一个网络配置可以指定多个插件顺序执行。前一个插件的输出作为后一个插件的输入。以 Calico 为例，典型的链式配置如下：

{
  "cniVersion": "0.3.1",
  "name": "k8s-pod-network",
  "plugins": [
    {
      "type": "calico",
      "datastore_type": "kubernetes",
      "etcd_endpoints": "",
      "log_level": "info",
      "ipam": { "type": "calico-ipam" }
    },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true },
      "snat": true
    },
    {
      "type": "bandwidth",
      "capabilities": { "bandwidth": true }
    }
  ]
}

2.5 交互流程中的关键数据结构

CNI 插件通过 标准输入（stdin） 接收网络配置，通过 环境变量 接收运行时上下文。以下是最核心的输入参数：

2.6 缓存故障在交互流程中的典型表现

结合 CNI 交互流程，容器网络缓存命中故障通常出现在以下环节：

1. IPAM 缓存未刷新：Calico-ipam 在内存中缓存已分配的 IP 列表。当 Pod 快速创建/删除时，缓存可能未及时同步到 etcd，导致新 Pod 分配到已被占用的 IP。
2. 端点缓存（Endpoint Cache）过期：Calico Felix 维护 WorkloadEndpoint 缓存。若缓存未随 Pod 生命周期更新，ADD 操作可能引用已删除的端点信息，造成路由错误。
3. CNI 配置缓存：kubelet 会缓存 /etc/cni/net.d/ 目录的解析结果。修改配置后若不重启 kubelet，新配置不会生效，导致插件调用链与预期不符。