1. CNI 概述：容器网络接口的定义、设计目标与核心价值
1.1 什么是 CNI？
CNI（Container Network Interface，容器网络接口） 是由 CoreOS 发起、现由 CNCF 托管的容器网络标准规范。它定义了一组接口契约，让容器运行时（如 containerd、CRI-O）能够通过统一的插件机制为容器分配网络资源，而无需关心底层网络实现细节。
CNI 的核心思想是 “插件化”：网络功能由独立的二进制插件提供，容器运行时仅负责调用插件，插件负责创建/删除网络接口、分配 IP 地址、配置路由规则等。
关键定义： CNI 不是网络实现，而是网络实现的调用标准。它规定了“容器运行时 → 网络插件”之间的交互协议。
1.2 设计目标
CNI 的设计遵循以下五个核心目标，确保其在多云、多运行时环境下的通用性与可扩展性：
| 目标 | 说明 | 设计体现 |
|---|---|---|
| 简单性 | 接口定义极简，仅包含 ADD/DEL/CHECK 三个操作 | 插件为独立二进制，无守护进程依赖 |
| 可移植性 | 不绑定任何特定容器运行时或编排系统 | 通过 JSON 配置和 stdin/stdout 通信 |
| 可组合性 | 支持链式调用多个插件完成复杂网络策略 | 插件链（Plugin Chaining）机制 |
| 最小权限 | 插件只负责网络连接，不管理 IPAM 之外的资源 | IPAM 作为独立插件分离 |
| 版本兼容 | 规范版本化，保证不同版本插件与运行时的互操作性 | CNI_VERSION 字段协商 |
1.3 在 Kubernetes 中的角色
Kubernetes 本身不实现容器网络，而是通过 kubelet 调用 CNI 插件来完成 Pod 网络生命周期管理。其角色可概括为以下三个层面：
- 网络就绪保障： 在 Pod 创建时，kubelet 调用 CNI 插件为 Pod 创建网络命名空间、配置 veth pair、分配 IP 并设置路由。
- IP 地址管理： 通过 IPAM 插件（如 host-local、dhcp）为 Pod 分配集群内唯一 IP，确保 Pod 间可直接通信。
- 网络策略执行： 部分 CNI 插件（如 Calico、Cilium）同时实现 Kubernetes NetworkPolicy，提供微隔离能力。
实践要点： Kubernetes 集群中，CNI 插件必须在集群初始化时安装，且一旦选定，后续更换需要重建所有节点。常见的生产级 CNI 插件包括 Calico（策略丰富）、Flannel（简单覆盖网络）、Cilium（eBPF 加速）、Weave Net（多跳路由）。
1.4 核心价值
CNI 为容器生态带来的核心价值体现在以下四个维度：
- 解耦运行时与网络： 容器运行时无需内置网络逻辑，网络实现可独立演进和替换。
- 标准化生态： 所有 CNI 插件遵循同一接口，用户可自由选择最适合业务场景的网络方案。
- 性能可优化： 插件可针对特定硬件（如 DPDK、RDMA）或内核特性（如 eBPF、XDP）进行深度优化，而不影响上层编排。
- 故障隔离： 插件以独立进程运行，单个插件的崩溃不会影响容器运行时或其他插件。
1.5 CNI 插件调用流程（SVG 架构图）
下图展示了 Kubernetes 中 kubelet 通过 CNI 接口调用插件链为 Pod 配置网络的完整流程：
1.6 CNI 与容器网络方案对比
下表对比了主流 CNI 插件在关键维度上的差异，帮助理解不同场景下的选型依据：
| 插件 | 网络模型 | 数据面 | NetworkPolicy | 性能特征 | 适用场景 |
|---|---|---|---|---|---|
| Flannel | Overlay（VXLAN/Host-GW） | 内核隧道 | 不支持 | 中等，封装开销约 5-10% | 小规模、快速部署 |
| Calico | 纯路由（BGP）或 Overlay（IPIP） | iptables / eBPF | 支持（丰富） | 高，无封装时接近原生 | 生产级、大规模、需策略 |
| Cilium | Overlay（VXLAN）或原生路由 | eBPF | 支持（L3-L7） | 极高，eBPF 绕过 iptables | 高性能、可观测性、安全 |
| Weave Net | Overlay（VXLAN + 快速路径） | 用户态封装 | 支持（基础） | 中等，多跳场景有延迟 | 多云、混合部署 |
选型提醒： CNI 插件的选择直接影响集群的网络延迟、吞吐量、故障恢复速度以及运维复杂度。建议在测试环境中使用真实业务流量进行基准测试，重点关注 P99 延迟和每秒新建连接数（CPS）两个指标。