2. CNI基础回顾：CNI规范、常见CNI插件工作原理、Pod网络模型
2.1 CNI规范核心要点
容器网络接口（Container Network Interface, CNI）是 Kubernetes 与容器运行时之间的网络配置协议。其核心设计原则是“最小接口、最大灵活性”——仅定义容器创建/删除时的网络配置操作，不关心底层网络实现。
| 规范要素 | 说明 |
|---|---|
| ADD 操作 | 容器运行时调用 CNI 插件为容器添加网络接口，返回 IP、路由、DNS 等信息 |
| DEL 操作 | 容器销毁时清理网络资源，释放 IP 和接口 |
| CHECK 操作 | （可选）验证容器网络状态是否与预期一致 |
| VERSION 操作 | 返回插件支持的 CNI 规范版本号 |
| 网络配置 | JSON 格式，包含 name、type、ipam、dns 等字段 |
| IPAM 模块 | 独立子插件，负责 IP 地址分配与管理（host-local、dhcp） |
关键设计哲学： CNI 不绑定任何网络后端，插件只需实现 ADD/DEL 两个核心接口即可接入 Kubernetes 网络体系。这种“插件化”架构使得 Calico、Flannel、Cilium 等不同技术栈可以共存于同一集群。
2.2 常见CNI插件工作原理对比
2.2.1 Flannel — 覆盖网络（Overlay）
Flannel 是最早的 Kubernetes 网络方案之一，核心思路是在主机间建立 VXLAN 隧道，将 Pod IP 封装在宿主机网络之上传输。
- 数据路径： Pod → veth pair → cni0 网桥 → flannel.1 VXLAN 设备 → 宿主机 eth0 → 对端宿主机 → 目标 Pod
- IPAM： host-local，每个节点分配一个 /24 子网
- 优点： 部署简单、零依赖、适合中小规模集群
- 缺点： 隧道封装带来额外开销（约 5-10% 吞吐损失），不支持 NetworkPolicy
2.2.2 Calico — 纯三层路由（BGP）
Calico 采用无隧道、纯三层路由模型，每个节点作为 BGP 路由器，将 Pod 路由信息直接广播到网络基础设施中。
- 数据路径： Pod → veth pair → caliX 接口 → 宿主机路由表 → 对端宿主机 → 目标 Pod
- IPAM： 支持 host-local 或 Calico IPAM（更灵活的 IP 池管理）
- 网络策略： 原生支持 Kubernetes NetworkPolicy，通过 iptables/ebpf 实现
- 优点： 接近线速转发、原生 NetworkPolicy、支持大规模集群（1000+ 节点）
- 缺点： 需要 BGP 基础设施支持，对网络设备有要求
2.2.3 Cilium — eBPF 驱动
Cilium 基于 Linux 内核 eBPF 技术，将网络、安全和可观测性下沉到内核层面，绕过传统 iptables 和隧道封装。
- 数据路径： Pod → veth pair → eBPF 程序（TC/XDP）→ 宿主机 eth0 → 对端宿主机 → 目标 Pod
- IPAM： 支持 CRD-backed IPAM、AWS ENI、Azure 等云原生 IPAM
- 网络策略： L3/L4/L7 全栈策略，基于身份的安全组模型
- 优点： 极低延迟、高吞吐、原生可观测性（Hubble）、支持 Service Mesh
- 缺点： 内核版本要求高（≥5.10 推荐）、调试复杂度较高
选型建议： 若追求极致性能且内核版本满足条件，优先选择 Cilium；若已有 BGP 网络基础设施且需要 NetworkPolicy，Calico 是成熟选择；Flannel 适合快速搭建开发/测试环境。
2.3 Pod网络模型详解
Kubernetes Pod 网络模型遵循三个基本原则：
- 每个 Pod 拥有独立 IP 地址，容器间通过 localhost 通信
- Pod 之间可以直接通信，无需 NAT 转换
- Node 与 Pod 之间可以直接通信，无需端口映射
下图展示了 Pod 网络的核心组件与数据流：
2.4 CNI插件架构对比总结
| 维度 | Flannel | Calico | Cilium |
|---|---|---|---|
| 转发模型 | VXLAN 覆盖网络 | 纯三层 BGP 路由 | eBPF 直接转发 |
| 封装开销 | 高（50字节头部） | 无 | 无 |
| NetworkPolicy | 不支持 | 原生支持（iptables） | 原生支持（eBPF） |
| IPAM 模式 | host-local | host-local / Calico IPAM | CRD / AWS ENI / Azure |
| 内核依赖 | 低（VXLAN 支持即可） | 中（BGP 路由） | 高（eBPF ≥ 5.10） |
| 大规模集群 | 一般（≤500 节点） | 优秀（1000+ 节点） | 优秀（1000+ 节点） |
| 可观测性 | 基础 | 中等（Felix 监控） | 原生（Hubble） |
CNI 缓存命中率的关键前提： 不同 CNI 插件的数据路径长度和内核交互方式直接影响 Envoy 连接缓存的有效性。例如，Flannel 的 VXLAN 封装会增加数据包处理路径，导致连接复用率下降；而 Cilium 的 eBPF 直通路径可减少上下文切换，提升缓存命中率。后续章节将深入分析这些差异对 Envoy 数据面的具体影响。