K8s CNI插件性能分析与G行实践-夜雨聆风

K8s CNI插件性能分析与G行实践

1. 引言

在 K8s 集群运行中，网络是支撑服务通信、弹性扩展、网络策略与安全管控的核心基础。CNI（容器网络接口）插件负责 Pod 网络连接、跨节点通信、网络策略执行及数据包转发等关键能力，不同插件在实现机制上存在差异，直接影响网络延迟、吞吐量与资源消耗等核心性能指标。本文结合 G 行内部选型实践，对比主流 CNI 插件在多场景下的性能表现，为读者提供选型参考。

2. CNI插件介绍

在本文中，主要比较以下几个 CNI 插件：

（1）Cilium：基于 eBPF 的 CNI，数据平面大量使用 kernel 中的 eBPF 程序来做包处理、负载均衡、网络策略、可观察性等，高效、延迟低，是近年趋势。

（2）Flannel：一个非常轻量级的 overlay 网络插件，早期广泛使用。优点在于简单、配置容易，但功能相对基础。

（3）Calico：功能比较丰富，不仅支持多种模式的网络连接，还支持网络策略 (NetworkPolicy)、路由（BGP、IP-in-IP、VXLAN）、数据平面实现（iptables、eBPF ）的选择。在生产环境中使用较多。

（4）Gnic：基于G行云平台环境研发，依托G行云平台底座SDN能力实现网络的高效吞吐及统一管理，同时支持更加灵活和丰富的网络策略。

以下是这几个CNI组件测试用的底层架构：

架构	Cilium	Calico	Flannel	Gnic
核心实现	eBPF	Iptables	Overlay networking	IPVS
数据面	eBPF programs	Linux kernel routing	VXLAN/host-gw	VXLAN
控制面	etcd/K8s API	BGP speakers	etcd/K8s API	etcd/K8s API
负载均衡	eBPF kube-proxy	kube-proxy	kube-proxy	kube-proxy
Language	Go + eBPF/C	Go	Go	Go/C

可以看到几个CNI的主要区别集中在核心实现上，由于eBPF、iptables、overlay、IPVS的不同特性，导致在性能方式出现偏差。其中负载均衡方式要特意列出，主要原因是在G行实际场景中，存在较多流量经过Service转发到各个pod，所以CNI对负载均衡的带来的影响也不能忽视。

3.测试结果及分析

针对G行容器的实际实践，我们选取了以下几个指标进行对比：

通信延迟（Pod-to-Pod）	在同一个物理/虚拟节点内，或者不同节点内，两个 Pod 之间通信的往返时间（RTT），在不同负载下测定。
带宽吞吐（Throughput）	用iperf来测大流量 TCP/UDP 传输速率，包括同节点与跨节点，以及 Pod-to-服务 (Service) 的情况。
资源消耗	网络插件在节点上的 CPU 使用、内存使用、可能的网络附带开销（如封包、解包、加密等）。

为了保证数据的一致性，我们选取了行内部分的利旧服务器搭建的容器集群进行测试，测试结果仅供参考。

延迟测试

CNI	同节点延迟(µs)	跨节点延迟(µs)
Flannel	90	350
Calico	100	380
Cilium	65	280
Gnic	74	340

由测试结果可见，同节点通信时，Cilium延迟占优但差距不是巨大。其主要原因是因同节点的通信链路较短，由于Cilium使用eBPF仅需要经过内核转发，而其它几个组件有的需要从veth经过bridge，有的还需要多经过iptables的规则，而 Cilium 的 eBPF 数据平面减少了上下文切换和内核用户态开销，所以小幅度领先。

在跨节点通信方面，由于通信链路较长，各个CNI的差距更加明显，其中最为明显的是Cilium。它凭借eBPF的优势，在延迟上绝对领先。而Flannel以较小优势领先于Calico的原因是因为Flannel是一款相对轻量化的CNI，不支持nat和网络策略。反观Calico，它的转发路径需要经过iptables的链表匹配，同时支持snat和dnat的配置，自然会比轻量化的Flannel慢一些。Gnic由于使用了ipvs的方式，直接从Linux内核进行哈希匹配，所以延迟领先于上面两个CNI。

网络吞吐量测试

场景	Cilium(Gbps)	Calico(Gbps)	Flannel（Gbps）	Gnic（Gbps）
Pod-to-Pod (同节点)	38.5	38.1	35.4	37.6
Pod-to-Pod (跨节点)	9.8	9.4	8.2	10.1
Pod-to-Service	28.5	22.1	20.3	21.7

至于网络吞吐量方面，Flannel由于overlay 的开销、跳数、MTU 限制、封包拆分等因素使得 Flannel 的吞吐下降比 Cilium 和 Calico 更严重，所以数据垫底。Gnic由于云平台底座的适配，在容器虚拟机-物理机-容器虚拟机的跨节点传输链路上效率更高，吞吐量有小幅度领先。

Pod-to-Service 的吞吐体现了负载均衡或者 CNI 插件对 Service 的处理方式的效率差异。Cilium 在这项中得分较高，主要得益于 eBPF 机制表现优秀。

资源消耗

CNI	内存（MB）	无负载CPU（核）	高负载CPU（核）
Cilium	180-250	0.1-0.2	0.5-0.8
Calico （iptables）	120-180	0.05-0.15	0.3-0.6
Flannel	50-80	0.02-0.08	0.2-0.4
Gnic	85-190	0.1-0.3	0.3-0.7

Cilium虽然性能较好，但在资源占用也明显更大，尤其是 CPU 高负载下，eBPF 程序的数量、map 大小、流量处理、策略匹配等都会带来更多的开销。

Calico的开销在中间水平，测试采用iptables模式的calico，表现较为稳定。

Flannel在资源消耗方面最低，基线开销很小，适合资源紧张或节点规格低的小场景。

Gnic组件的资源开销比较高，还有明显的提升空间。

测试结论

从上面的几个测试中，不难看出Cilium在性能测试中表现优异，虽然资源开销略大，但是瑕不掩瑜。Calico在测试中表现稳定，虽略有落后Cilium，但是它凭完善的功能，仍是不少企业的选择之一。Flannel作为轻量化的标杆，性能上相对落后，但是对于小规模集群和性能需求不高的用户，是个不错的选择。Gnic是基于G行云平台底座研发的CNI，得益于IAAS和架构优化，性能上也有不错的表现。

从 Flannel 到 Calico，再到 Cilium，清晰地展示了K8s 容器网络的三次演进：Overlay封包 → 原生路由 → 内核智能数据面。每一次演进都是一次性能的提升。

不过除了性能表现外，还应该考虑其它几个方面的问题。比如是否完全开源，社区的成熟度等方面，和对各种K8s，Linux 及docker或者contained版本的兼容性等问题。

4. G行思考与实践

G行云3.0的建设从2020年左右就开始了技术的选型和研发，在最初设计选型的时候，项目的建设初衷是选择一个稳定，符合银行业网络安全要求，成熟度相对较高，且能自主可控的CNI。不过那时候Cilium的热度刚刚兴起，成熟度还有待提高。当时的Calico已经成为了很多企业生产部署的主流CNI，但是当时版本的Calico针对ip-pool和namespace的关联功能还有待完善，fix-ip功能也刚刚发布。在银行业信息安全的大背景下，这些针对静态IP的分配及绑定功能涉及到行内诸多的网络安全策略。

在综合考虑了诸多因素以后，最终决定依托现有云平台底座的基础，定制开发了一款符合G行内部需求的CNI，这也满足了对CNI自主可控的要求。随着这几年来的版本迭代，Gnic已经完全胜任行内的诸多要求，且在关键指标中表现不俗，为G行虚拟机容器上云系统提供稳定可靠的网络服务。

在G行内除了虚拟机容器集群外，从2022年末开启了信创裸金属容器集群的选型研发工作，系统又一次面临了CNI的选型问题。由于裸金属集群完全基于物理机搭建，没有使用云平台的SDN能力，所以之前使用的Gnic的选择被排除了。

在Calico和Cilium的两者的竞争中选择了Calico。其原因主要是Calico的稳定性较高，在银行业的网络环境中，安全稳定是第一要素。其次是因为这个时期的Calico功能已经较为完善，满足银行安全管控需求，同时Calico有着开放活跃的社区环境，以及能复用BGP 3层网络和iptables现有运维经验。

5. 总结与建议

通过对主流CNI插件性能对比以及G行选型实践分享，总结K8S上CNI插件选型几点建议如下：

– 若对性能有极致要求，尤其适用于大规模微服务、实时通信等高并发场景，Cilium为最优解。其基于eBPF驱动，可实现低延迟、高吞吐的同节点与跨节点通信，但需确保底层网络设备及操作系统具备良好兼容性。

– 若追求性能、稳定性与功能完整性的平衡，Calico是理想之选。近期已支持eBPF数据平面，性能接近Cilium，是大规模企业级场景的主流选择。

– 若场景简单、资源受限，或仅用于测试环境，对延迟、带宽无严苛要求，Flannel部署便捷、资源占用低，为最佳选择。

总之，各企业CNI插件选型需结合自身网络环境、节点硬件配置、运维能力，综合考量延迟、带宽、资源消耗及网络策略复杂度等核心需求。最后需要特别提醒的是生产环境CNI插件替换成本很高，前期充分评估适配性至关重要，毕竟CNI插件就好比是K8S集群的“底盘与传动系统”，生产环境在线替换存在巨大风险。