3. CNI插件选型与性能特征
在Kubernetes集群中，CNI插件决定了Pod之间、Pod与Service之间、Pod与外部网络之间的数据包如何被转发。不同CNI的转发模式差异，会直接体现在吞吐量、延迟、CPU占用、连接建立速度以及可观测性上。选型时如果只看“功能列表”，很容易忽略转发路径带来的性能差异。本节从转发模式出发，对比Calico、Cilium、Flannel、Antrea四类主流CNI，并给出可操作的判断依据。
一、先理解转发模式的三个维度
CNI的性能特征主要由三个维度决定：数据面封装方式、转发规则实现、是否绕过内核协议栈。
- Overlay与Underlay：Overlay通过VXLAN、IP-in-IP、Geneve等隧道封装，把Pod网络包再包一层，跨节点通信依赖隧道解封装。Underlay则让Pod IP直接参与底层路由，通常配合BGP发布路由，没有额外封装头。Overlay部署简单、对底层网络要求低，但封装/解封装会带来额外CPU开销和约50~100字节的头部开销，MTU需要相应调小。
- iptables、IPVS与eBPF：Service转发和网络策略的实现方式。iptables规则随Service数量线性增长，大规模集群下规则匹配变慢；IPVS使用哈希表，转发性能更稳定；eBPF在套接字层或TC层直接处理，可绕过部分netfilter路径，延迟和CPU占用通常更优。
- 内核协议栈与旁路：传统CNI依赖内核netfilter和路由子系统；Cilium的eBPF可以做到同节点Pod间通信在socket层直接转发，减少协议栈穿越次数。
二、四类CNI的转发模式对比
下面这张图把四类CNI的典型转发路径并列展示，便于直观看出封装、规则引擎和旁路能力的差异。
三、转发模式如何影响性能
把上图的路径拆开看，性能损耗主要发生在四个位置：
- 封装与解封装：VXLAN/IP-in-IP 每包增加 50~100 字节头部，MTU 从 1500 降到 1450 或更低。若未正确设置 Pod MTU，会出现大包分片，吞吐下降、重传增加。Calico 的 IP-in-IP 和 Flannel 的 VXLAN 都有此问题；Calico 的 BGP 直连模式、Cilium 的 Native Routing 可避免。
- 规则匹配：iptables 的 Service 规则随 Service/Endpoint 数量增长，kube-proxy 在数千 Service 规模下同步延迟可达秒级，且每个包要顺序遍历链。IPVS 用哈希查找，O(1) 复杂度，适合大规模 Service。Cilium 的 eBPF 在 socket 层完成 DNAT，同节点访问 Service 甚至不经过网络栈。
- 协议栈穿越次数：传统路径 Pod→veth→netfilter→路由→veth→Pod，同节点通信也要走完整协议栈。Cilium 的 socket-level redirect 可让同节点 Pod 直接内存拷贝，延迟可降低约 30%~50%（具体取决于内核版本与负载特征）。
- CPU 缓存与中断：eBPF 程序在 TC 层执行，避免频繁的软中断和上下文切换；OVS 流表在用户态和内核态之间切换，开销相对较高。
四、选型判断：从场景反推模式
没有“最好”的 CNI，只有与场景匹配的转发模式。可以按以下顺序判断：
| 场景特征 | 优先考虑 | 理由 |
|---|---|---|
| 集群规模小、追求部署简单 | Flannel VXLAN | 依赖少、配置简单，性能可接受 |
| 需要 BGP 对接物理网络、无封装 | Calico BGP | Underlay 直连，吞吐和延迟接近裸机 |
| Service 数量多、延迟敏感 | Cilium eBPF | 绕过 iptables，socket 层转发 |
| 需要细粒度网络策略与流日志 | Cilium 或 Antrea | eBPF/OVS 提供策略与可观测性 |
| 已有 OVS 运维体系 | Antrea | 复用 OVS 流表与工具链 |
| Windows 节点混合集群 | Calico 或 Antrea | 对 Windows 数据面支持较成熟 |
五、实操验证：用 iperf3 与 netperf 观察差异
选型不能只靠文档，建议在测试集群用以下方式量化对比。以下命令为示例，参数需根据实际节点网卡和 MTU 调整。
# 在服务端 Pod 启动 iperf3
kubectl run iperf-server --image=networkstatic/iperf3 -- -s
# 在客户端 Pod 发起测试，观察吞吐
kubectl run iperf-client --rm -it --image=networkstatic/iperf3 \
-- -c iperf-server -t 30 -P 4
# 查看 Pod MTU，确认是否因封装导致分片
kubectl exec iperf-client -- ip link show eth0
# 观察 Service 转发路径（Cilium 可用 Hubble）
hubble observe --pod iperf-client --follow判断依据：若 TCP 吞吐明显低于网卡线速且伴随重传，优先检查 MTU 与封装；若 P99 延迟随 Service 数量增长而上升，检查 iptables 规则规模或切换到 IPVS/eBPF；若同节点 Pod 通信延迟异常高，检查是否走了隧道而非本地转发。
提示：切换 CNI 前，先用测试集群验证目标模式下的 MTU、Service 规模、网络策略和可观测性是否满足要求。生产集群更换 CNI 通常需要重建节点网络，风险较高。
注意：Overlay 模式下若 Pod MTU 未按封装开销调小，会出现“小包正常、大包超时”的典型故障。VXLAN 建议 Pod MTU 设为 1450，IP-in-IP 设为 1480，具体以底层网络 MTU 为准。
总结来看，Calico 适合需要 Underlay 和 BGP 的场景，Cilium 在延迟和可观测性上优势明显，Flannel 胜在简单，Antrea 则在 OVS 生态和策略能力之间取得平衡。选型时应先明确转发模式，再用测试数据验证，而不是仅凭功能列表做决定。