面向Kubernetes的高性能网络方案研究

尚佳友，王晓锋，刘渊

（江南大学人工智能与计算机学院，无锡214122）

0 引言

随着硬件性能的不断提升，资源过剩成为当前面临的一个主要问题，云计算技术应运而生[1]。虚拟化技术和云平台技术作为云计算的两大核心技术也成为近年来的热门技术。

容器技术作为新一代的轻量级虚拟化技术，以其资源利用率高、性能开销小、运维成本低等优势，给传统的全虚拟化技术带来颠覆性的挑战[2]。但容器技术并不具备跨物理主机的管理能力，企业对容器集群的编排、监控、发布等功能需求日益提升，容器管理系统应运而生。其中，Kubernetes以其优秀的架构设计和完善的生态系统，从众多容器编排引擎中脱颖而出，越来越多的企业开始使用Kubernetes构建容器云平台。Kubernetes实现了容器集群资源的集群化管理，为用户隐藏了底层容器调度、运行等技术的实现细节，实现了容器的自动化管理[3]。

Kubernetes强大之处在于其实现的分布式容器管理系统。Kubernetes并不是直接对容器进行操作，而是通过管理Pod实现对容器的管理。其中，Pod是Kuber⁃netes中最小的资源单位和基础运行单位[4]，由一个或多个共享存储和网络的容器组成。分布式系统内部的网络通信是不可避免的问题，但是Kubernetes并没有实现Pod之间的通信，只是提供了CNI容器网络接口[5]。CNI将网络方案插件化，通过连接容器管理系统与网络插件，使两者之间进行通信，从而实现Pod间的网络通信[6]。基于CNI出现了一些第三方网络方案如Flannel、Kuryr，能够为Kubernetes提供网络通信服务。随着Kubernetes的不断发展，用户对Kubernetes网络环境的网络性能、多样化网络配置等需求不断增加，现有的第三方网络方案存在网络资源管理能力薄弱、网络配置方式有限、网络性能不足等问题[7]。

Neutron作为一种网络服务组件，具有优秀的虚拟网络资源管理功能，能够为云平台提供网络支撑。因此，本文采用Neutron为Kubernetes提供网络服务，设计实现Kubernetes网络插件N-Net。其主要优势在于：

（1）将Kubernetes与Neutron、Keystone进行有机结合，使用Neutron提供网络服务，Keystone提供身份认证服务，保障Kubernetes的网络通信功能。

（2）创新性的提出一种深度定制Pod网络的方法，用户能够根据业务场景需求实现对Pod的IP地址的静态分配。

（3）优化Neutron底层网络架构，在保证网络稳定性的前提下，提升网络性能。

1 相关工作

本节首先对Kubernetes的网络架构进行介绍，接着针对主流的基于CNI的网络方案进行介绍，最后针对云平台相关组件进行介绍。

1.1 Kubernetes的网络架构

Kubernetes集群由Master节点和Node节点两类节点组成。Master节点是Kubernetes的核心节点，负责Kubernetes集群的管理与调度；Node节点则为运行在其上的Pod提供服务支撑。

作为Kubernetes中最小的资源单位和基础运行单位，每个Pod都会被分配唯一的IP地址。Kubernetes中的网络通信是Pod级别的通信，因此，Kubernetes网络方案也就是要解决Pod的网络部署与网络通信问题。目前，所有的网络方案均作为Kubernetes的网络插件实现。Kubernetes支持两种类型网络插件：Kubenet插件和基于CNI的插件。由于Kubenet插件实现功能有限且仅支持小型集群，因此Kubernetes的网络方案主要采用基于CNI的网络插件[8]。

Kubernetes集群使用基于CNI的网络插件时，用户能够通过配置文件实现对Kubernetes网络环境的基本配置，包括配置集群网络的IP范围。Pod创建网络时，由网络插件实现对其IP地址的分配、管理及配置[9]。用户与网络环境、网络资源的交互仅限于配置文件，除此之外，Kubernetes并没有为用户提供与网络资源交互的接口。

1.2 Kubernetes基于CNI的网络方案实现及分析

与本文研究相关的主要有以下2种基于CNI的Kubernetes网络方案：

Flannel[10]是由CoreOS设计的Kubernetes的网络方案。Flannel创建一个大型内部网络并在该网络中为Kubernetes集群中的每台宿主机划分子网，每个Pod在其宿主机的子网内获取IP地址，从而接入集群网络。在网络功能方面，该插件并未提供用户与网络资源交互的方案。在网络性能方面，文献[11]指出由于Flan⁃nel在传输过程中存在对数据包的封装和拆封过程，因此Kubernetes集群的网络性能受到了影响。

Kuryr[12]是由OpenStack社区开发的子项目，该方案使用Neutron为Kubernetes提供网络服务。在网络功能方面，Kuryr需要首先创建一个默认网络，Pod的网络划分仍然受限于该默认网络中，并不能够根据场景需求进行多样化Pod网络的创建与配置。在网络性能方面，文献[13]指出，由于Kuryr使用传统的Neutron网络架构且并未考虑数据处理效能，导致Kubernetes集群的网络性能受限。

1.3 云平台组件介绍

Neutron[14]是OpenStack[15]组件之一，其设计目标是“网络即服务”，将网络作为服务提供给用户。Neutron提供网络连接、二层交换网络、三层路由、DHCP等网络功能，可为云环境提供虚拟网络。此外，Neutron遵循SDN的设计思想，为复杂网络环境下的虚拟化网络资源管理及配置提供了有力的支撑[16]。Neutron底层网络结构通过Open vSwitch虚拟交换机实现流量转发，从而保障网络的通信功能。

Keystone[17]是OpenStack的组件之一，具有认证、鉴权等功能，为OpenStack其他组件提供统一的认证服务。Keystone可以为云环境的安全提供有力支撑。

2 N-Net体系架构

2.1 逻辑架构

N-Net作为可插拔的网络插件，由网络模块和交互模块组成。网络模块为Kubernetes提供网络资源支撑与身份认证服务；交互模块为用户提供与Kubernetes集群的网络资源交互服务。N-Net的逻辑架构如图1所示。

图1 N-Net逻辑架构

N-Net北向通过CNI接口与Kubernetes连接，南向通过Restful API接口与Neutron和Keystone连接。基于Restful API的接口设计使得N-Net不需要考虑Kubernetes与Neutron、Keystones组件之间底层代码的调用过程，从而兼容多版本Neutron、Keystone、Kuber⁃netes。

2.2 N-Net模块设计

N-Net的交互模块包含两个子模块：命令行子模块和解析子模块；N-Net的网络模块包含四个子模块：信息存储子模块，网络部署子模块，身份认证子模块，网络资源子模块。

相较于Flannel和Kuryr中只针对网络通信进行模块设计，N-Net考虑到用户与网络资源交互的问题，设计实现交互模块为用户提供与网络资源交互管理接口，从而实现用户与网络资源的深层次交互。同时，NNet考虑到插件运行过程中的数据维护问题，设计信息存储子模块将Kubernetes的网络信息存放在的独立数据库中，从而实现N-Net与Kubernetes进一步解耦，增强了N-Net的独立性。此外，N-Net通过网络资源子模块和网络部署子模块实现高性能网络架构的部署。

N-Net各子模块功能如下：

（1）命令行子模块。命令行子模块设计并实现了一种新型Kubernetes命令行kubenetctl，在兼容kubectl的原生命令基础上，新增网络命令，能够完成对Kuber⁃netes网络资源的灵活管理以及对Pod网络的多样化配置，从而实现用户与Kubernetes网络资源的深度交互。

（2）解析子模块。解析子模块完成对参数命令的解析过程，将参数命令解析并分类为原生命令与网络命令，并根据命令内容进行相关操作。

（3）信息存储子模块。信息存储子模块通过实时维护N-Net数据库，为N-Net中的其他子模块提供信息存储保障，实现网络资源信息与Kubernetes资源信息的解耦，便于网络插件的维护。信息存储模块主要对Kubernetes网络资源信息，Pod网络配置信息以及Kubernetes集群的认证信息提供持久化实时维护。

（4）身份认证子模块。身份认证子模块负责为Ku⁃bernetes集群提供身份认证服务。该模块将Keystone与Kubernetes进行结合，进而保障Kubernetes集群的安全性。

（5）网络资源子模块。网络资源子模块实现N-Net的网络资源调度和回收。该模块解析信息存储子模块实时维护的Pod网络配置信息，向Neutron申请或回收相应的网络资源，包括网络、子网和端口，并实时更新信息存储子模块的网络资源数据和Pod的网络配置数据。

（6）网络部署子模块。网络部署子模块实现Pod网络部署，将网络资源子模块申请的网络、子网、端口分配给相应的Pod。

3 关键技术

本节针对N-Net的特点优势进行详细介绍：①创新性地提出深度定制Pod网络的方法，通过kubenetctl实现用户与网络资源之间的深度交互；②提出高性能网络架构优化策略，提高网络性能。

3.1 深度定制Pod网络方法

Kubernetes作为容器编排系统，在其上部署的容器应用类型繁多。在一些大规模的复杂场景中，包括日志、监控、访问策略控制等基础业务都是以Pod的IP地址作为唯一标识，因此实际业务的部署对Pod的IP地址的定制和管理提出了需求。当前用户仅能够通过配置文件为Kubernetes集群网络设置一个网段并将该网段作为Kubernetes网络环境的网络池，用户仅能够在该网络池中为Pod划分子网段，网络地址划分能力受限。同时，Kubernetes没有提供对Pod进行IP地址层面配置的方案。这是由于Kubernetes的原生命令行kubectl与第三方网络插件的交互停留在较浅层面，导致用户仅能通过kubectl进行有限的网络配置和管理，无法实现对Pod网络的细粒度配置。

N-Net创新性的提出一种深度定制Pod网络的方法，通过交互模块与网络模块的相互协作实现定制Pod的IP地址，能够为Pod指定静态IP地址。图2显示了用户深度定制Pod网络时的流程及模块间的协作过程。

图2 深度定制网络过程

具体步骤如下：

（1）用户通过kubenetctl输入Pod创建参数，其中包括Pod的网络配置参数。解析子模块将用户输入的命令解析为原生命令和网络命令。原生命令传递Pod的部署信息；网络命令传递Pod的网络配置信息，包括定制的Pod的网段、IP地址。

（2）Kubernetes根据Pod的部署信息调度资源创建Pod；同时，网络模块根据Pod的网络配置信息调用信息存储子模块更新N-Net数据库。

（3）创建Pod时，Kubernetes通过CNI调用N-Net进行网络创建，N-Net收到请求后，网络模块调用身份认证子模块对Kubernetes集群进行身份验证。

（4）身份验证成功后，网络模块首先读取信息存储子模块中的Pod网络配置信息，接着，根据网络配置信息调用网络资源子模块申请网络资源，包括网络、子网和端口资源，并实时维护信息存储子模块。

（5）网络模块调用网络部署子模块对Pod进行网络环境加载，包括为Pod加载符合定制信息的网络和网卡。

通过上述流程，最终实现对Pod网络的深度定制。

3.2 高性能网络架构优化策略

越来越多的云计算厂商开始探索在Kubernetes环境中的应用实践，同时对网络性能的要求也不断提高。针对Kubernetes集群网络性能需求的不断提升，N-Net提出一种高性能网络架构优化策略，优化Neutron底层网络架构，设计实现高性能网络架构，如图3所示。

图3 传统网络结构与高性能网络结构

基于Open vSwitch的Neutron传统底层网络架构如图3（a）所示，Pod使用一对veth设备连接到Linux⁃Bridge进而连接到Br-int虚拟交换机，Br-int虚拟交换机通过patch port接口连接到Br-tun虚拟交换机，Brtun与物理网卡相连。Br-int与Br-tun均为Open⁃vSwirch虚拟交换机，负责流量的转发。LinuxBridge处于Pod和Br-int之间，用于实现安全组功能，为Pod提供安全保障。目前OpenStack社区已经开发出了基于Open vSwitch的防火墙驱动，可由Open vSwitch实现安全组功能。因此，LinuxBridge成为非必须的网络结构。

随着Pod的个数的增加，与Pod直接相连的LinuxBridge的个数也随之增加。由于多出一层网桥结构，流量从Pod到物理网卡转发次数增多，需要进行内核切换的次数增加，资源消耗增加，网络性能受到影响。

相对于Neutron传统的底层网络架构，N-Net对Neutron底层网络架构进行了优化，实现高性能网络架构，如图3（b）所示。与图3（a）网络架构中的Pod通过LinuxBridge与Br-int进行连接不同，高性能网络架构使用internal类型的虚拟网卡，N-Net网络部署子模块将该虚拟网卡加载至Pod网络命名空间中，实现Pod与Br-int的互联。Pod与虚拟交换机共享同一个虚拟网卡，减少LinuxBridge的创建，从而减少宿主机需要维护的虚拟网络设备，性能开销得到大幅度降低。Pod和Br-int之间通信仅需要进行一次数据转发，数据转发的性能损耗降低，可以大幅度提高Pod之间的通信性能，进而提高Kubernetes集群的网络性能。

4 实验结果与分析

本节通过四个实验对N-Net进行网络功能及网络性能的验证分析。

4.1 实验环境

构建1套Kubernetes集群环境，记为环境1。环境1中Kubernetes集群包含1个Master节点：k8smaster，2个Node节点：k8snode1和k8snode2。Master节点的物理服务器配置为CPU Intel Xeon E5-2620 v3@2.40GHz，内存32GB；Node节点的物理服务器配置为CPU Intel Xeon E5-2620 v4@2.10GHz，内存32GB。Master节点和Node节点的物理服务器操作系统为CentOS 7.5，Kubernetes版本为1.18.3，Neutron、Keystone版本为Queue。

4.2 深度定制Pod网络验证

本实验验证N-Net的深度定制Pod网络特性。

环境1中Kubernetes部署N-Net作为网络插件，通过kubenetctl创建一个Pod，将其命名为pod1，指定pod1的网段为1.2.0.0/16，IP地址为1.2.0.100。

完成Pod创建后通过kubectl查看pod1的状态信息，如图4所示。由图4可知pod1的运行状态为Run⁃ning，且图中红框标出的Pod的IP地址为1.2.0.100，与上述通过kubenetctl创建pod1时定制的IP地址一致，证明了kubenetctl网络命令的有效性，即N-Net支持对Pod网络的深度定制。

图4 Pod状态信息查询

4.3 网络连通性验证

本实验通过测试Kubernetes集群中Pod间的连通性，验证N-Net的网络功能。

环境1中Kubernetes部署N-Net作为网络插件，使用kubenetctl创建四个Pod并为其配置网络信息如表1所示。其中，网段1.2.0.0/16与网段192.168.10.0/24设置为连通。

表1 Pod网络配置

其中，p1向p2发送ICMP数据包，用于验证同宿主机同网段Pod之间的连通性；p4向p3发送ICMP数据包，用于验证同宿主机跨网段Pod之间的连通性；p1向p4发送ICMP数据包，用于验证跨宿主机同网段Pod之间的连通性；p1向p3发送ICMP数据包，用于验证跨宿主机跨网段Pod之间的连通性，发包实验结果如表2所示。验证了同宿主机同网段、同宿主机跨网段、跨宿主机同网段、跨宿主机跨网段之间的Pod的连通性。综上，证明N-Net能够作为Kubernetes的网络支撑，为Kubernetes提供网络功能。

表2 测试结果

4.4 网络性能验证

4.4.1 吞吐量测试

本实验将TCP流量的吞吐量作为评判标准，通过比较Kubernetes集群中Pod间的TCP流量的吞吐量，验证N-Net的高性能网络架构优化策略的有效性。

在环境1中，Kubernetes分别部署三种网络插件N-Net、Kuryr、Flannel，使用Iperf3测试使用不同网络插件的Pod之间TCP流量的吞吐量，实验结果如图5所示，图5（a）为同宿主机的Pod之间的TCP吞吐量对比图，图5（b）为跨宿主机的Pod之间的TCP吞吐量对比图。

图5 TCP吞吐量对比

其中，Pod位于同宿主机的情况下，N-Net的TCP吞吐量平均为36.2Gbit/s，Flannel的TCP吞吐量平均为25.1Gbit/s，Kuryr的TCP吞吐量平均为21.4Gbit/s，N-Net与Flannel相比提升了1.44倍，与Kuryr相比提升了1.69倍；Pod位于跨宿主机的情况下，N-Net的TCP吞吐量平均为2.65Gbit/s，Flannel的TCP吞吐量平均为1.85Gbit/s，Kuryr的TCP吞吐量平均为1.63Gbit/s，N-Net与Flannel相比提升了1.43倍，与Kuryr相比提升了1.63倍。

Flannel由于转发策略，流量需要经过多层网桥转发打包，导致其吞吐量性能有所损耗。Kuryr使用传统Neutron的底层网络结构，Pod通过veth设备连接LinuxBridge网桥进而连接到Br-int虚拟交换机，流量需要多次进出网络命名空间，造成性能损耗。N-Net使用优化的高性能网络架构，Pod直连至Br-int虚拟交换机，减少流量的转发次数，进而提升吞吐量性能。

此外，跨宿主机的Pod之间的TCP吞吐量远低于同宿主机的Pod之间的TCP吞吐量。这是由于物理交换机的性能限制，吞吐量性能受到影响，但N-Net的吞吐量仍然高于其他两种网络插件。

综上，N-Net与Flannel、Kuryr相比，吞吐量获得较大提升，验证了高性能网络架构优化策略的有效性。

4.4.2 RTT测试

本实验将RTT作为网络延时及网络稳定性的评判标准，通过比较Kubernetes集群中Pod间RTT值，验证N-Net的高性能网络架构优化策略有效性及N-Net的稳定性。

在环境1中，Kubernetes分别部署三种网络插件N-Net、Flannel、Kuryr，统计发送不同数量数据包情况下，同宿主机的Pod之间和跨宿主机的Pod之间的RTT值，实验结果如图6所示。图6（a）是同宿主机的Pod之间的RTT对比图，图6（b）是跨宿主机的Pod之间的RTT对比图。

图6 RTT对比

其中，Pod位于同宿主机情况下，N-Net的RTT值与Flannel相比平均下降了23%，与Kuryr相比平均下降了29%；Pod位于跨宿主机情况下，N-Net的RTT值与Flannel相比平均下降了22%，与Kuryr相比平均下降了28%。N-Net由于高性能网络架构，流量转发次数减少，网络性能较高，RTT值与Kuryr和Flannel相比较小。

通过图6（a）、（b）对比可以发现，跨宿主机Pod之间的RTT值要高于同宿主机的Pod之间的RTT值，这是由于物理交换机性能限制。

此外由图6还可以看到，在发送五种不同数量的数据包时，三种网络插件的RTT值变化不大，表明了N-Net与Flannel和Kuryr一样具有较好的网络稳定性。

该实验进一步证明了N-Net高性能网络架构优化策略有效性，同时证明了N-Net具有较好的稳定性。

5 结语

本文设计并实现了一种新型的Kubernetes网络方案N-Net，在保证Kubernetes集群网络功能的基础上，为用户提供了一种深度定制Pod网络的实现方法，同时针对Neutron的网络结构进行优化，实现高性能网络架构。在本文的基础上，后续工作将对N-Net的网络管理功能进行完善和拓展。