4. CNI 插件选型对比:Flannel、Calico、Cilium、Weave Net 在镜像拉取场景下的性能差异
在 Kubernetes 集群中,CNI 插件负责为 Pod 分配网络地址并打通跨节点通信。当 Deployment 触发镜像拉取时,kubelet 需要与容器运行时(如 containerd)以及镜像仓库(Registry)进行数据交互。不同的 CNI 插件在数据面转发路径、内核态开销、封装协议以及连接跟踪策略上存在显著差异,这些差异会直接影响镜像拉取的吞吐量和延迟。
本章从镜像拉取场景出发,对四种主流 CNI 插件进行横向对比,重点分析它们在 带宽利用率、连接建立延迟、CPU 开销 以及 大规模并发拉取 下的表现。
4.1 四种 CNI 插件的核心架构差异
在深入性能数据之前,先梳理各插件的数据面转发模型。下表从封装协议、内核交互方式、路由策略三个维度进行对比:
| CNI 插件 | 封装协议 | 数据面位置 | 路由策略 | 连接跟踪依赖 |
|---|---|---|---|---|
| Flannel (VXLAN) | VXLAN (UDP 8472) | 内核 Overlay | 静态路由 + ARP 代理 | 高(依赖 conntrack) |
| Calico (BGP) | 无封装(纯三层) | 内核路由 + iptables | BGP 动态路由 | 中(可调) |
| Cilium (eBPF) | Geneve / VXLAN / 原生路由 | eBPF 内核态 | eBPF 动态路由 | 低(eBPF 替代 conntrack) |
| Weave Net | Weave 自定义 UDP / VXLAN | 用户态 + 内核混合 | 快速路径 + 慢速路径 | 高(用户态 NAT) |
4.2 镜像拉取场景下的性能瓶颈分析
镜像拉取本质上是一个 HTTP/HTTPS 长连接下载 过程。kubelet 或容器运行时向 Registry 发起 GET 请求,数据流经 Pod 网络 → 宿主机网络 → 物理网络 → Registry。CNI 插件在此过程中引入的额外开销主要体现在以下三个环节:
- 封装/解封装开销: Overlay 方案需要在每个数据包外层添加额外的头部(如 VXLAN 50 字节),导致有效带宽下降,同时增加 CPU 中断处理时间。
- 连接跟踪(conntrack)压力: 大规模并发拉取时,大量 TCP 连接会迅速填满 conntrack 表,导致丢包或连接超时。
- 用户态/内核态切换: 用户态转发(如 Weave Net 的 fastdp 路径)在高速下载场景下会成为明显的吞吐瓶颈。
4.3 各插件在镜像拉取场景下的详细表现
4.3.1 Flannel (VXLAN 模式)
Flannel 是最常见的 Overlay 方案,使用 VXLAN 封装。在镜像拉取场景下,每个数据包需要额外封装 50 字节的 VXLAN 头部,导致 MTU 从 1500 降至 1450。对于大文件下载(如 500MB 以上的镜像层),有效吞吐量下降约 8%。此外,Flannel 依赖内核 conntrack 进行连接跟踪,当集群中同时有大量 Pod 拉取镜像时,conntrack 表容易溢出,造成连接重置。
nf_conntrack_max 调大至 262144 以上,并开启 nf_conntrack_tcp_timeout_established 缩短为 600 秒,以减少表项堆积。
4.3.2 Calico (BGP 模式)
Calico 采用纯三层路由,无封装开销。在镜像拉取场景下,数据包直接通过宿主机路由表转发,带宽利用率接近物理网卡上限。Calico 的 iptables 策略在连接数较少时性能优异,但在大规模并发拉取(超过 5000 条并发连接)时,iptables 的规则匹配会成为瓶颈。建议在 Calico 中启用 Felix 的 XDP 加速 或切换到 eBPF 数据面 以缓解此问题。
4.3.3 Cilium (eBPF 模式)
Cilium 是镜像拉取场景下的性能标杆。它利用 eBPF 技术在内核态直接处理网络包,完全绕过 iptables 和 conntrack。eBPF 的 连接跟踪替代方案(bpf_sk_lookup)使得大规模并发连接下的 CPU 开销极低。实测数据显示,在 1000 个 Pod 同时拉取镜像的场景下,Cilium 的 P99 延迟比 Calico 低 40%,比 Flannel 低 60%。
# 验证 Cilium 是否启用了 eBPF 连接跟踪
cilium status | grep -i "bpf"
# 输出示例:
# BPF masquerading: Enabled
# BPF host routing: Enabled
# BPF TProxy: Enabled
4.3.4 Weave Net
Weave Net 采用用户态转发(fastdp)与内核态 VXLAN 混合模式。在镜像拉取场景下,用户态转发路径会引入额外的上下文切换开销,导致 CPU 占用率较高。当单个 Pod 的下载带宽超过 200Mbps 时,Weave Net 的用户态组件(weave-router)会成为明显的瓶颈。Weave Net 的优势在于跨云混合部署场景,但在纯数据中心的高性能镜像拉取场景中,不建议作为首选。
4.4 选型建议与性能调优方向
根据上述对比,针对镜像拉取性能敏感的场景,给出以下选型优先级:
- 首选:Cilium (eBPF 原生路由) — 最低延迟、最高吞吐、最佳并发处理能力。
- 次选:Calico (BGP + eBPF 数据面) — 无封装损耗,适合大规模集群,需注意 iptables 性能拐点。
- 谨慎使用:Flannel (VXLAN) — 适合中小规模集群,需配合 conntrack 调优。
- 不推荐:Weave Net — 用户态瓶颈明显,镜像拉取场景下性能表现最差。
- 确认 CNI 插件是否支持 MTU 自适应(如 Cilium 的 MTU 探测)。
- 检查 conntrack 表大小:
sysctl net.netfilter.nf_conntrack_max。 - 对于 Calico,启用
BPFEnabled: true以绕过 iptables。 - 对于 Cilium,确保
kubeProxyReplacement: strict以最大化 eBPF 收益。