容器网络插件对比分析及裸金属 vs 虚拟化网络性能实测

导读

随着容器规模的扩大和业务场景的复杂化，容器网络作为支撑微服务通信、服务发现和流量管理的核心组件，其重要性愈发凸显，同时也面临诸多挑战。在此背景下，选择适合自身业务场景的CNI插件成为企业云原生落地的关键决策。本文集中探索与对比了流行的CNI插件：Flannel、Calico、Cilium，并详细分析裸金属和虚拟化环境对于容器网络性能的影响。

作者：符程

银行技术经理，负责联机分析处理类应用系统运维，以及基础软件和云原生技术的管理。

引子

云计算的世界里，计算最基础，存储最重要，网络最复杂。容器网络作为Kubernetes集群最关键的组成部分，业界已经出现了多种解决方案，即CNI（Container Network Interface）插件，CNI意为容器网络通用接口，它是一种标准的设计，为了让用户在容器创建或销毁时都能够更容易地配置容器网络。

一、背景简介

在云计算和云原生技术高速发展的今天，容器化已成为我司数字化转型的重要技术发展路径之一。从金融行业的实时交易系统到电商平台的高并发流量处理，再到物联网设备的边缘计算场景，容器技术凭借其轻量化和快速部署的优势，正在重塑各行各业的IT基础设施架构。然而，随着容器规模的扩大和业务场景的复杂化，容器网络作为支撑微服务通信、服务发现和流量管理的核心组件，其重要性愈发凸显，同时也面临诸多挑战：

（一）行业场景的多样性需求

金融行业：对网络延迟和安全性要求极高，需支持严格的网络隔离策略（如证券交易系统的毫秒级延迟需求）。

电商与互联网：需要应对瞬时高并发流量，网络插件需具备高吞吐量和低资源开销，避免成为性能瓶颈。

制造业与物联网：边缘计算场景下，跨地域节点的网络通信需兼顾灵活性和稳定性，同时适应混合云架构。

（二）技术难点与价值

性能与成本的平衡：Overlay网络（如VXLAN）虽能实现跨网段通信，但封装解封装带来的性能损耗可能影响关键业务。

安全与合规：金融、医疗等行业需通过细粒度网络策略满足合规要求。

可扩展性：企业从百节点到万节点集群的扩展过程中，网络插件的路由效率直接决定运维复杂度。

在此背景下，选择适合自身业务场景的CNI插件成为企业云原生落地的关键决策。在本文中，我们将集中探索与对比目前最流行的 CNI插件 ：Flannel、Calico、Cilium，以及分析裸金属和虚拟化环境对于容器网络性能的影响。

二、网络插件介绍

（一）Flannel

Flannel 是一个简单的 overlay 网络方案，易于理解和部署。

UDP：早期版本的Flannel使用UDP封装完成报文的跨越主机转发，其安全性及性能略有不足。

VXLAN：Linux 内核在在2012年底的v3.7.0之后加入了VXLAN协议支持，因此新版本的Flannel也有UDP转换为VXLAN，VXLAN本质上是一种tunnel（隧道）协议，用来基于3层网络实现虚拟的2层网络，目前flannel 的网络模型已经是基于VXLAN的叠加(覆盖)网络，目前推荐使用vxlan作为其网络模型。

Host-gw：也就是Host GateWay，通过在node节点上创建到达各目标容器地址的路由表而完成报文的转发，因此这种方式要求各node节点本身必须处于同一个局域网(二层网络)中，因此不适用于网络变动频繁或比较大型的网络环境，但是其性能相对较好一些。

Flannel 组件：

Cni0：网桥设备，每创建一个pod都会创建一对veth pair，其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡），Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口（网卡）上，Cni0设备获得的ip地址是该节点分配到的网段的第一个地址。

Flannel.1：overlay网络的设备，用来进行vxlan报文的处理（封包和解包），不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。

优点：

1、简单易用：适合刚接触容器网络的用户。

2、支持多种后端：如 UDP、VXLAN 和 host-gw。

3、社区支持广泛：拥有庞大的社区，方便获取解决方案和教程。

缺点：

1、功能相对较少：网络策略功能较弱。

2、性能损耗：在 overlay 模式下会带来额外的封装/解封装开销。

（二）Calico

Calico 以其强大的网络策略功能著称，采用 BGP 路由机制，适用于高性能需求场景。

Calico 的核心组件：

Felix：运行在每一台 Host 的 agent 进程，主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等。

etcd：分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性，可以与 kubernetes 共用；

BGP Client（BIRD）：Calico 为每一台 Host 部署一个 BGP Client，使用 BIRD 实现，BIRD 是一个单独的持续发展的项目，实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 Host 上由 Felix 注入的路由信息，然后通过 BGP 协议广播告诉剩余 Host 节点，从而实现网络互通。

优点：

1、强大的网络策略：支持多条件定义访问规则。

2、性能较好：非 overlay 模式下性能损耗小。

3、支持多种网络插件和集成：适应不同生态系统和部署环境。

缺点：

1、配置相对复杂：对于初学者来说学习成本高。

2、依赖额外组件：增加了系统的复杂性和维护成本。

（三）Cilium

Cilium 基于 eBPF 技术，提供高性能的网络通信和深度的可观察性。Cilium位于容器编排系统和Linux Kernel之间，向上可以通过编排平台为容器进行网络以及相应的安全配置，向下可以通过在Linux内核挂载eBPF程序，来控制容器网络的转发行为以及安全策略执行。

在Cilium的架构中，除了Key-Value数据存储之外，主要组件包括Cilium Agent和Cilium Operator，还有一个客户端的命令行工具Cilium CLI。

Cilium Agent作为整个架构中最核心的组件，通过DaemonSet的方式，以特权容器的模式，运行在集群的每个主机上。Cilium Agent作为用户空间守护程序，通过插件与容器运行时和容器编排系统进行交互，进而为本机上的容器进行网络以及安全的相关配置。同时提供了开放的API，供其他组件进行调用。

Cilium Agent在进行网络和安全的相关配置时，采用eBPF程序进行实现。Cilium Agent结合容器标识和相关的策略，生成eBPF程序，并将eBPF程序编译为字节码，将它们传递到Linux内核。

优点：

1、基于 eBPF 的高性能：提供低延迟和高吞吐量。

2、深度的可观察性：帮助理解容器网络行为。

3、灵活的网络策略：实现细粒度的安全策略。

缺点：

1、技术门槛较高：要求对内核编程和 eBPF 有了解。

2、兼容性问题：可能遇到不同内核版本或操作系统环境下的兼容性挑战。

Calico的性能要优于flannel且应用广泛，Cilium性能最高但目前应用案例较少，我司目前广泛使用的网络插件方案为Calico。

三、Calico网络模式对比

Calico不会有任何网桥，Calico会为每一个容器创建一个Veth pair设备，一端在容器内，一端设置到宿主机上。数据的转发，靠Calico维护的路由规则。

（一）模式对比

对比Calico各个模式的技术特点如下表所示：

（点击图片可放大）

其中vxlan模式和ipip模式都可以设置crosssubnet，即在跨网段的k8s节点的pod间通信时才使用vxlan或ipip进行封包，同一网段的k8s节点的pod间通信则直接使用bgp模式。使用同网段内的k8s节点作为BGP Speaker全互联交换各自的pod子网路由实现互通，避免封包。

（二）对比测试

1、虚拟机带宽测试

集群情况：

Server端：10.1.2.14

Client端：10.1.2.15

测试结果：

2、bgp模式下pod之间带宽测试

Server端：10.1.2.14 节点上的pod

Client端：10.1.2.15节点上的pod

测试结果：

3、ipip模式下pod之间带宽测试

Server端：10.1.2.14 节点上的pod

Client端：10.1.2.15节点上的pod

测试结果：

4、vxlan模式下pod之间带宽测试

Server端：10.1.2.14 节点上的pod

Client端：10.1.2.15节点上的pod

测试结果：

5、静态ip模式（即macvlan）下pod之间带宽测试

Server端：pod的IP地址为10.2.10.1

Client端：pod的IP地址为10.2.10.2

测试结果：

（三）测试结论

通过以上对比测试，可以得出如下结果：

（四）适用场景

四、裸金属vs虚拟化

以目前生产环境使用的calico插件为例，测试裸金属环境与虚拟化环境之间的性能差异。

（一）测试环境

裸金属：10.29.111.38，10.29.111.39。

虚拟机：10.29.12.212，10.29.12.222

（二）测试方式

通过netperf 分别在两台主机创建的pod直接进行测试。

物理环境的pod分布如下图：

（三）测试工具：netperf

1、工具模式介绍：

TCP_STREAM：基于TCP的批量发送模式

UDP_STREAM：基于UDP的批量发送模式

TCP_RR和TCP_CRR：基于TCP的请求应答模式，TCP_RR 在同一个连接中进行多次request和response请求，TCP_CRR 每次请求新建一个连接

UDP_RR：基于UDP的请求应答模式

2、常用参数：

-H host：指定远端运行netserver的server IP地址

-l testlen：测试的时间长度(秒)

-t testname：netperf工作模式，包括TCP_STREAM、UDP_STREAM、TCP_CRR、TCP_RR、UDP_RR

-s size：本地系统的socket发送与接收缓冲大小

-S size：远端系统的socket发送与接收缓冲大小

-m size：传输时设置传输数据包大小

-M size：远端系统接收测试分组的大小

-p port：连接Server端的端口

-r req,resp：请求应答模式测试时发送数据包大小和接收数据包大小

-O string：自定义输出结果，可在其中添加时延、90值、99值、吞吐量、CPU使用率等信息

-c：结果计算显示客户端CPU使用率

-C：结果计算显示服务端CPU使用率

参考: https://www.netperf.org/

（四）测试用例说明

1、物理节点-物理节点

分别在俩台物理机节点，一台运行netperf服务端，另一台以netperf客户端进行不同具体模式的测试。

2、虚拟节点-虚拟节点

分别在俩台虚拟机节点，一台运行netperf服务端，另一台以netperf客户端进行不同具体模式的测试。

3、容器-跨节点容器 calico

在俩台物理机节点分别运行一个calico模式的pod，其中一个pod运行netperf服务端，在另外一个pod中以netperf客户端进行具体模式的测试。

（五）测试结果汇总

（六）测试结果对比

（七）测试结果总结

虚拟机对比物理节点上的calico模式的pod，吞吐量平均损耗在47%，延迟平均多83%。

（八）测试记录

1、虚拟节点-虚拟节点

（1）TCP_STREAM(默认) 消息体512

（2）TCP_STREAM(默认) 消息体1024

（3）TCP_STREAM(默认) 消息体10K

（4）TCP_RR 消息体512

（5）TCP_RR 消息体1024

（6）TCP_CRR 消息体512

（7）TCP_CRR 消息体1024