尚佳友，王曉鋒，劉淵

（江南大學人工智能與計算機學院，無錫214122）

0 引言

隨著硬件性能的不斷提升，資源過剩成為當前面臨的一個主要問題，云計算技術(shù)應運而生[1]。虛擬化技術(shù)和云平臺技術(shù)作為云計算的兩大核心技術(shù)也成為近年來的熱門技術(shù)。

容器技術(shù)作為新一代的輕量級虛擬化技術(shù)，以其資源利用率高、性能開銷小、運維成本低等優(yōu)勢，給傳統(tǒng)的全虛擬化技術(shù)帶來顛覆性的挑戰(zhàn)[2]。但容器技術(shù)并不具備跨物理主機的管理能力，企業(yè)對容器集群的編排、監(jiān)控、發(fā)布等功能需求日益提升，容器管理系統(tǒng)應運而生。其中，Kubernetes以其優(yōu)秀的架構(gòu)設(shè)計和完善的生態(tài)系統(tǒng)，從眾多容器編排引擎中脫穎而出，越來越多的企業(yè)開始使用Kubernetes構(gòu)建容器云平臺。Kubernetes實現(xiàn)了容器集群資源的集群化管理，為用戶隱藏了底層容器調(diào)度、運行等技術(shù)的實現(xiàn)細節(jié)，實現(xiàn)了容器的自動化管理[3]。

Kubernetes強大之處在于其實現(xiàn)的分布式容器管理系統(tǒng)。Kubernetes并不是直接對容器進行操作，而是通過管理Pod實現(xiàn)對容器的管理。其中，Pod是Kuber?netes中最小的資源單位和基礎(chǔ)運行單位[4]，由一個或多個共享存儲和網(wǎng)絡(luò)的容器組成。分布式系統(tǒng)內(nèi)部的網(wǎng)絡(luò)通信是不可避免的問題，但是Kubernetes并沒有實現(xiàn)Pod之間的通信，只是提供了CNI容器網(wǎng)絡(luò)接口[5]。CNI將網(wǎng)絡(luò)方案插件化，通過連接容器管理系統(tǒng)與網(wǎng)絡(luò)插件，使兩者之間進行通信，從而實現(xiàn)Pod間的網(wǎng)絡(luò)通信[6]?；贑NI出現(xiàn)了一些第三方網(wǎng)絡(luò)方案如Flannel、Kuryr，能夠為Kubernetes提供網(wǎng)絡(luò)通信服務(wù)。隨著Kubernetes的不斷發(fā)展，用戶對Kubernetes網(wǎng)絡(luò)環(huán)境的網(wǎng)絡(luò)性能、多樣化網(wǎng)絡(luò)配置等需求不斷增加，現(xiàn)有的第三方網(wǎng)絡(luò)方案存在網(wǎng)絡(luò)資源管理能力薄弱、網(wǎng)絡(luò)配置方式有限、網(wǎng)絡(luò)性能不足等問題[7]。

Neutron作為一種網(wǎng)絡(luò)服務(wù)組件，具有優(yōu)秀的虛擬網(wǎng)絡(luò)資源管理功能，能夠為云平臺提供網(wǎng)絡(luò)支撐。因此，本文采用Neutron為Kubernetes提供網(wǎng)絡(luò)服務(wù)，設(shè)計實現(xiàn)Kubernetes網(wǎng)絡(luò)插件N-Net。其主要優(yōu)勢在于：

（1）將Kubernetes與Neutron、Keystone進行有機結(jié)合，使用Neutron提供網(wǎng)絡(luò)服務(wù)，Keystone提供身份認證服務(wù)，保障Kubernetes的網(wǎng)絡(luò)通信功能。

（2）創(chuàng)新性的提出一種深度定制Pod網(wǎng)絡(luò)的方法，用戶能夠根據(jù)業(yè)務(wù)場景需求實現(xiàn)對Pod的IP地址的靜態(tài)分配。

（3）優(yōu)化Neutron底層網(wǎng)絡(luò)架構(gòu)，在保證網(wǎng)絡(luò)穩(wěn)定性的前提下，提升網(wǎng)絡(luò)性能。

1 相關(guān)工作

本節(jié)首先對Kubernetes的網(wǎng)絡(luò)架構(gòu)進行介紹，接著針對主流的基于CNI的網(wǎng)絡(luò)方案進行介紹，最后針對云平臺相關(guān)組件進行介紹。

1.1 Kubernetes的網(wǎng)絡(luò)架構(gòu)

Kubernetes集群由Master節(jié)點和Node節(jié)點兩類節(jié)點組成。Master節(jié)點是Kubernetes的核心節(jié)點，負責Kubernetes集群的管理與調(diào)度；Node節(jié)點則為運行在其上的Pod提供服務(wù)支撐。

作為Kubernetes中最小的資源單位和基礎(chǔ)運行單位，每個Pod都會被分配唯一的IP地址。Kubernetes中的網(wǎng)絡(luò)通信是Pod級別的通信，因此，Kubernetes網(wǎng)絡(luò)方案也就是要解決Pod的網(wǎng)絡(luò)部署與網(wǎng)絡(luò)通信問題。目前，所有的網(wǎng)絡(luò)方案均作為Kubernetes的網(wǎng)絡(luò)插件實現(xiàn)。Kubernetes支持兩種類型網(wǎng)絡(luò)插件：Kubenet插件和基于CNI的插件。由于Kubenet插件實現(xiàn)功能有限且僅支持小型集群，因此Kubernetes的網(wǎng)絡(luò)方案主要采用基于CNI的網(wǎng)絡(luò)插件[8]。

Kubernetes集群使用基于CNI的網(wǎng)絡(luò)插件時，用戶能夠通過配置文件實現(xiàn)對Kubernetes網(wǎng)絡(luò)環(huán)境的基本配置，包括配置集群網(wǎng)絡(luò)的IP范圍。Pod創(chuàng)建網(wǎng)絡(luò)時，由網(wǎng)絡(luò)插件實現(xiàn)對其IP地址的分配、管理及配置[9]。用戶與網(wǎng)絡(luò)環(huán)境、網(wǎng)絡(luò)資源的交互僅限于配置文件，除此之外，Kubernetes并沒有為用戶提供與網(wǎng)絡(luò)資源交互的接口。

1.2 Kubernetes基于CNI的網(wǎng)絡(luò)方案實現(xiàn)及分析

與本文研究相關(guān)的主要有以下2種基于CNI的Kubernetes網(wǎng)絡(luò)方案：

Flannel[10]是由CoreOS設(shè)計的Kubernetes的網(wǎng)絡(luò)方案。Flannel創(chuàng)建一個大型內(nèi)部網(wǎng)絡(luò)并在該網(wǎng)絡(luò)中為Kubernetes集群中的每臺宿主機劃分子網(wǎng)，每個Pod在其宿主機的子網(wǎng)內(nèi)獲取IP地址，從而接入集群網(wǎng)絡(luò)。在網(wǎng)絡(luò)功能方面，該插件并未提供用戶與網(wǎng)絡(luò)資源交互的方案。在網(wǎng)絡(luò)性能方面，文獻[11]指出由于Flan?nel在傳輸過程中存在對數(shù)據(jù)包的封裝和拆封過程，因此Kubernetes集群的網(wǎng)絡(luò)性能受到了影響。

Kuryr[12]是由OpenStack社區(qū)開發(fā)的子項目，該方案使用Neutron為Kubernetes提供網(wǎng)絡(luò)服務(wù)。在網(wǎng)絡(luò)功能方面，Kuryr需要首先創(chuàng)建一個默認網(wǎng)絡(luò)，Pod的網(wǎng)絡(luò)劃分仍然受限于該默認網(wǎng)絡(luò)中，并不能夠根據(jù)場景需求進行多樣化Pod網(wǎng)絡(luò)的創(chuàng)建與配置。在網(wǎng)絡(luò)性能方面，文獻[13]指出，由于Kuryr使用傳統(tǒng)的Neutron網(wǎng)絡(luò)架構(gòu)且并未考慮數(shù)據(jù)處理效能，導致Kubernetes集群的網(wǎng)絡(luò)性能受限。

1.3 云平臺組件介紹

Neutron[14]是OpenStack[15]組件之一，其設(shè)計目標是“網(wǎng)絡(luò)即服務(wù)”，將網(wǎng)絡(luò)作為服務(wù)提供給用戶。Neutron提供網(wǎng)絡(luò)連接、二層交換網(wǎng)絡(luò)、三層路由、DHCP等網(wǎng)絡(luò)功能，可為云環(huán)境提供虛擬網(wǎng)絡(luò)。此外，Neutron遵循SDN的設(shè)計思想，為復雜網(wǎng)絡(luò)環(huán)境下的虛擬化網(wǎng)絡(luò)資源管理及配置提供了有力的支撐[16]。Neutron底層網(wǎng)絡(luò)結(jié)構(gòu)通過Open vSwitch虛擬交換機實現(xiàn)流量轉(zhuǎn)發(fā)，從而保障網(wǎng)絡(luò)的通信功能。

Keystone[17]是OpenStack的組件之一，具有認證、鑒權(quán)等功能，為OpenStack其他組件提供統(tǒng)一的認證服務(wù)。Keystone可以為云環(huán)境的安全提供有力支撐。

2 N-Net體系架構(gòu)

2.1 邏輯架構(gòu)

N-Net作為可插拔的網(wǎng)絡(luò)插件，由網(wǎng)絡(luò)模塊和交互模塊組成。網(wǎng)絡(luò)模塊為Kubernetes提供網(wǎng)絡(luò)資源支撐與身份認證服務(wù)；交互模塊為用戶提供與Kubernetes集群的網(wǎng)絡(luò)資源交互服務(wù)。N-Net的邏輯架構(gòu)如圖1所示。

圖1 N-Net邏輯架構(gòu)

N-Net北向通過CNI接口與Kubernetes連接，南向通過Restful API接口與Neutron和Keystone連接?；赗estful API的接口設(shè)計使得N-Net不需要考慮Kubernetes與Neutron、Keystones組件之間底層代碼的調(diào)用過程，從而兼容多版本Neutron、Keystone、Kuber?netes。

2.2 N-Net模塊設(shè)計

N-Net的交互模塊包含兩個子模塊：命令行子模塊和解析子模塊；N-Net的網(wǎng)絡(luò)模塊包含四個子模塊：信息存儲子模塊，網(wǎng)絡(luò)部署子模塊，身份認證子模塊，網(wǎng)絡(luò)資源子模塊。

相較于Flannel和Kuryr中只針對網(wǎng)絡(luò)通信進行模塊設(shè)計，N-Net考慮到用戶與網(wǎng)絡(luò)資源交互的問題，設(shè)計實現(xiàn)交互模塊為用戶提供與網(wǎng)絡(luò)資源交互管理接口，從而實現(xiàn)用戶與網(wǎng)絡(luò)資源的深層次交互。同時，NNet考慮到插件運行過程中的數(shù)據(jù)維護問題，設(shè)計信息存儲子模塊將Kubernetes的網(wǎng)絡(luò)信息存放在的獨立數(shù)據(jù)庫中，從而實現(xiàn)N-Net與Kubernetes進一步解耦，增強了N-Net的獨立性。此外，N-Net通過網(wǎng)絡(luò)資源子模塊和網(wǎng)絡(luò)部署子模塊實現(xiàn)高性能網(wǎng)絡(luò)架構(gòu)的部署。

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

（1）命令行子模塊。命令行子模塊設(shè)計并實現(xiàn)了一種新型Kubernetes命令行kubenetctl，在兼容kubectl的原生命令基礎(chǔ)上，新增網(wǎng)絡(luò)命令，能夠完成對Kuber?netes網(wǎng)絡(luò)資源的靈活管理以及對Pod網(wǎng)絡(luò)的多樣化配置，從而實現(xiàn)用戶與Kubernetes網(wǎng)絡(luò)資源的深度交互。

（2）解析子模塊。解析子模塊完成對參數(shù)命令的解析過程，將參數(shù)命令解析并分類為原生命令與網(wǎng)絡(luò)命令，并根據(jù)命令內(nèi)容進行相關(guān)操作。

（3）信息存儲子模塊。信息存儲子模塊通過實時維護N-Net數(shù)據(jù)庫，為N-Net中的其他子模塊提供信息存儲保障，實現(xiàn)網(wǎng)絡(luò)資源信息與Kubernetes資源信息的解耦，便于網(wǎng)絡(luò)插件的維護。信息存儲模塊主要對Kubernetes網(wǎng)絡(luò)資源信息，Pod網(wǎng)絡(luò)配置信息以及Kubernetes集群的認證信息提供持久化實時維護。

（4）身份認證子模塊。身份認證子模塊負責為Ku?bernetes集群提供身份認證服務(wù)。該模塊將Keystone與Kubernetes進行結(jié)合，進而保障Kubernetes集群的安全性。

（5）網(wǎng)絡(luò)資源子模塊。網(wǎng)絡(luò)資源子模塊實現(xiàn)N-Net的網(wǎng)絡(luò)資源調(diào)度和回收。該模塊解析信息存儲子模塊實時維護的Pod網(wǎng)絡(luò)配置信息，向Neutron申請或回收相應的網(wǎng)絡(luò)資源，包括網(wǎng)絡(luò)、子網(wǎng)和端口，并實時更新信息存儲子模塊的網(wǎng)絡(luò)資源數(shù)據(jù)和Pod的網(wǎng)絡(luò)配置數(shù)據(jù)。

（6）網(wǎng)絡(luò)部署子模塊。網(wǎng)絡(luò)部署子模塊實現(xiàn)Pod網(wǎng)絡(luò)部署，將網(wǎng)絡(luò)資源子模塊申請的網(wǎng)絡(luò)、子網(wǎng)、端口分配給相應的Pod。

3 關(guān)鍵技術(shù)

本節(jié)針對N-Net的特點優(yōu)勢進行詳細介紹：①創(chuàng)新性地提出深度定制Pod網(wǎng)絡(luò)的方法，通過kubenetctl實現(xiàn)用戶與網(wǎng)絡(luò)資源之間的深度交互；②提出高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略，提高網(wǎng)絡(luò)性能。

3.1 深度定制Pod網(wǎng)絡(luò)方法

Kubernetes作為容器編排系統(tǒng)，在其上部署的容器應用類型繁多。在一些大規(guī)模的復雜場景中，包括日志、監(jiān)控、訪問策略控制等基礎(chǔ)業(yè)務(wù)都是以Pod的IP地址作為唯一標識，因此實際業(yè)務(wù)的部署對Pod的IP地址的定制和管理提出了需求。當前用戶僅能夠通過配置文件為Kubernetes集群網(wǎng)絡(luò)設(shè)置一個網(wǎng)段并將該網(wǎng)段作為Kubernetes網(wǎng)絡(luò)環(huán)境的網(wǎng)絡(luò)池，用戶僅能夠在該網(wǎng)絡(luò)池中為Pod劃分子網(wǎng)段，網(wǎng)絡(luò)地址劃分能力受限。同時，Kubernetes沒有提供對Pod進行IP地址層面配置的方案。這是由于Kubernetes的原生命令行kubectl與第三方網(wǎng)絡(luò)插件的交互停留在較淺層面，導致用戶僅能通過kubectl進行有限的網(wǎng)絡(luò)配置和管理，無法實現(xiàn)對Pod網(wǎng)絡(luò)的細粒度配置。

N-Net創(chuàng)新性的提出一種深度定制Pod網(wǎng)絡(luò)的方法，通過交互模塊與網(wǎng)絡(luò)模塊的相互協(xié)作實現(xiàn)定制Pod的IP地址，能夠為Pod指定靜態(tài)IP地址。圖2顯示了用戶深度定制Pod網(wǎng)絡(luò)時的流程及模塊間的協(xié)作過程。

圖2 深度定制網(wǎng)絡(luò)過程

具體步驟如下：

（1）用戶通過kubenetctl輸入Pod創(chuàng)建參數(shù)，其中包括Pod的網(wǎng)絡(luò)配置參數(shù)。解析子模塊將用戶輸入的命令解析為原生命令和網(wǎng)絡(luò)命令。原生命令傳遞Pod的部署信息；網(wǎng)絡(luò)命令傳遞Pod的網(wǎng)絡(luò)配置信息，包括定制的Pod的網(wǎng)段、IP地址。

（2）Kubernetes根據(jù)Pod的部署信息調(diào)度資源創(chuàng)建Pod；同時，網(wǎng)絡(luò)模塊根據(jù)Pod的網(wǎng)絡(luò)配置信息調(diào)用信息存儲子模塊更新N-Net數(shù)據(jù)庫。

（3）創(chuàng)建Pod時，Kubernetes通過CNI調(diào)用N-Net進行網(wǎng)絡(luò)創(chuàng)建，N-Net收到請求后，網(wǎng)絡(luò)模塊調(diào)用身份認證子模塊對Kubernetes集群進行身份驗證。

（4）身份驗證成功后，網(wǎng)絡(luò)模塊首先讀取信息存儲子模塊中的Pod網(wǎng)絡(luò)配置信息，接著，根據(jù)網(wǎng)絡(luò)配置信息調(diào)用網(wǎng)絡(luò)資源子模塊申請網(wǎng)絡(luò)資源，包括網(wǎng)絡(luò)、子網(wǎng)和端口資源，并實時維護信息存儲子模塊。

（5）網(wǎng)絡(luò)模塊調(diào)用網(wǎng)絡(luò)部署子模塊對Pod進行網(wǎng)絡(luò)環(huán)境加載，包括為Pod加載符合定制信息的網(wǎng)絡(luò)和網(wǎng)卡。

通過上述流程，最終實現(xiàn)對Pod網(wǎng)絡(luò)的深度定制。

3.2 高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略

越來越多的云計算廠商開始探索在Kubernetes環(huán)境中的應用實踐，同時對網(wǎng)絡(luò)性能的要求也不斷提高。針對Kubernetes集群網(wǎng)絡(luò)性能需求的不斷提升，N-Net提出一種高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略，優(yōu)化Neutron底層網(wǎng)絡(luò)架構(gòu)，設(shè)計實現(xiàn)高性能網(wǎng)絡(luò)架構(gòu)，如圖3所示。

圖3 傳統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)與高性能網(wǎng)絡(luò)結(jié)構(gòu)

基于Open vSwitch的Neutron傳統(tǒng)底層網(wǎng)絡(luò)架構(gòu)如圖3（a）所示，Pod使用一對veth設(shè)備連接到Linux?Bridge進而連接到Br-int虛擬交換機，Br-int虛擬交換機通過patch port接口連接到Br-tun虛擬交換機，Brtun與物理網(wǎng)卡相連。Br-int與Br-tun均為Open?vSwirch虛擬交換機，負責流量的轉(zhuǎn)發(fā)。LinuxBridge處于Pod和Br-int之間，用于實現(xiàn)安全組功能，為Pod提供安全保障。目前OpenStack社區(qū)已經(jīng)開發(fā)出了基于Open vSwitch的防火墻驅(qū)動，可由Open vSwitch實現(xiàn)安全組功能。因此，LinuxBridge成為非必須的網(wǎng)絡(luò)結(jié)構(gòu)。

隨著Pod的個數(shù)的增加，與Pod直接相連的LinuxBridge的個數(shù)也隨之增加。由于多出一層網(wǎng)橋結(jié)構(gòu)，流量從Pod到物理網(wǎng)卡轉(zhuǎn)發(fā)次數(shù)增多，需要進行內(nèi)核切換的次數(shù)增加，資源消耗增加，網(wǎng)絡(luò)性能受到影響。

相對于Neutron傳統(tǒng)的底層網(wǎng)絡(luò)架構(gòu)，N-Net對Neutron底層網(wǎng)絡(luò)架構(gòu)進行了優(yōu)化，實現(xiàn)高性能網(wǎng)絡(luò)架構(gòu)，如圖3（b）所示。與圖3（a）網(wǎng)絡(luò)架構(gòu)中的Pod通過LinuxBridge與Br-int進行連接不同，高性能網(wǎng)絡(luò)架構(gòu)使用internal類型的虛擬網(wǎng)卡，N-Net網(wǎng)絡(luò)部署子模塊將該虛擬網(wǎng)卡加載至Pod網(wǎng)絡(luò)命名空間中，實現(xiàn)Pod與Br-int的互聯(lián)。Pod與虛擬交換機共享同一個虛擬網(wǎng)卡，減少LinuxBridge的創(chuàng)建，從而減少宿主機需要維護的虛擬網(wǎng)絡(luò)設(shè)備，性能開銷得到大幅度降低。Pod和Br-int之間通信僅需要進行一次數(shù)據(jù)轉(zhuǎn)發(fā)，數(shù)據(jù)轉(zhuǎn)發(fā)的性能損耗降低，可以大幅度提高Pod之間的通信性能，進而提高Kubernetes集群的網(wǎng)絡(luò)性能。

4 實驗結(jié)果與分析

本節(jié)通過四個實驗對N-Net進行網(wǎng)絡(luò)功能及網(wǎng)絡(luò)性能的驗證分析。

4.1 實驗環(huán)境

構(gòu)建1套Kubernetes集群環(huán)境，記為環(huán)境1。環(huán)境1中Kubernetes集群包含1個Master節(jié)點：k8smaster，2個Node節(jié)點：k8snode1和k8snode2。Master節(jié)點的物理服務(wù)器配置為CPU Intel Xeon E5-2620 v3@2.40GHz，內(nèi)存32GB；Node節(jié)點的物理服務(wù)器配置為CPU Intel Xeon E5-2620 v4@2.10GHz，內(nèi)存32GB。Master節(jié)點和Node節(jié)點的物理服務(wù)器操作系統(tǒng)為CentOS 7.5，Kubernetes版本為1.18.3，Neutron、Keystone版本為Queue。

4.2 深度定制Pod網(wǎng)絡(luò)驗證

本實驗驗證N-Net的深度定制Pod網(wǎng)絡(luò)特性。

環(huán)境1中Kubernetes部署N-Net作為網(wǎng)絡(luò)插件，通過kubenetctl創(chuàng)建一個Pod，將其命名為pod1，指定pod1的網(wǎng)段為1.2.0.0/16，IP地址為1.2.0.100。

完成Pod創(chuàng)建后通過kubectl查看pod1的狀態(tài)信息，如圖4所示。由圖4可知pod1的運行狀態(tài)為Run?ning，且圖中紅框標出的Pod的IP地址為1.2.0.100，與上述通過kubenetctl創(chuàng)建pod1時定制的IP地址一致，證明了kubenetctl網(wǎng)絡(luò)命令的有效性，即N-Net支持對Pod網(wǎng)絡(luò)的深度定制。

圖4 Pod狀態(tài)信息查詢

4.3 網(wǎng)絡(luò)連通性驗證

本實驗通過測試Kubernetes集群中Pod間的連通性，驗證N-Net的網(wǎng)絡(luò)功能。

環(huán)境1中Kubernetes部署N-Net作為網(wǎng)絡(luò)插件，使用kubenetctl創(chuàng)建四個Pod并為其配置網(wǎng)絡(luò)信息如表1所示。其中，網(wǎng)段1.2.0.0/16與網(wǎng)段192.168.10.0/24設(shè)置為連通。

表1 Pod網(wǎng)絡(luò)配置

其中，p1向p2發(fā)送ICMP數(shù)據(jù)包，用于驗證同宿主機同網(wǎng)段Pod之間的連通性；p4向p3發(fā)送ICMP數(shù)據(jù)包，用于驗證同宿主機跨網(wǎng)段Pod之間的連通性；p1向p4發(fā)送ICMP數(shù)據(jù)包，用于驗證跨宿主機同網(wǎng)段Pod之間的連通性；p1向p3發(fā)送ICMP數(shù)據(jù)包，用于驗證跨宿主機跨網(wǎng)段Pod之間的連通性，發(fā)包實驗結(jié)果如表2所示。驗證了同宿主機同網(wǎng)段、同宿主機跨網(wǎng)段、跨宿主機同網(wǎng)段、跨宿主機跨網(wǎng)段之間的Pod的連通性。綜上，證明N-Net能夠作為Kubernetes的網(wǎng)絡(luò)支撐，為Kubernetes提供網(wǎng)絡(luò)功能。

表2 測試結(jié)果

4.4 網(wǎng)絡(luò)性能驗證

4.4.1 吞吐量測試

本實驗將TCP流量的吞吐量作為評判標準，通過比較Kubernetes集群中Pod間的TCP流量的吞吐量，驗證N-Net的高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略的有效性。

在環(huán)境1中，Kubernetes分別部署三種網(wǎng)絡(luò)插件N-Net、Kuryr、Flannel，使用Iperf3測試使用不同網(wǎng)絡(luò)插件的Pod之間TCP流量的吞吐量，實驗結(jié)果如圖5所示，圖5（a）為同宿主機的Pod之間的TCP吞吐量對比圖，圖5（b）為跨宿主機的Pod之間的TCP吞吐量對比圖。

圖5 TCP吞吐量對比

其中，Pod位于同宿主機的情況下，N-Net的TCP吞吐量平均為36.2Gbit/s，F(xiàn)lannel的TCP吞吐量平均為25.1Gbit/s，Kuryr的TCP吞吐量平均為21.4Gbit/s，N-Net與Flannel相比提升了1.44倍，與Kuryr相比提升了1.69倍；Pod位于跨宿主機的情況下，N-Net的TCP吞吐量平均為2.65Gbit/s，F(xiàn)lannel的TCP吞吐量平均為1.85Gbit/s，Kuryr的TCP吞吐量平均為1.63Gbit/s，N-Net與Flannel相比提升了1.43倍，與Kuryr相比提升了1.63倍。

Flannel由于轉(zhuǎn)發(fā)策略，流量需要經(jīng)過多層網(wǎng)橋轉(zhuǎn)發(fā)打包，導致其吞吐量性能有所損耗。Kuryr使用傳統(tǒng)Neutron的底層網(wǎng)絡(luò)結(jié)構(gòu)，Pod通過veth設(shè)備連接LinuxBridge網(wǎng)橋進而連接到Br-int虛擬交換機，流量需要多次進出網(wǎng)絡(luò)命名空間，造成性能損耗。N-Net使用優(yōu)化的高性能網(wǎng)絡(luò)架構(gòu)，Pod直連至Br-int虛擬交換機，減少流量的轉(zhuǎn)發(fā)次數(shù)，進而提升吞吐量性能。

此外，跨宿主機的Pod之間的TCP吞吐量遠低于同宿主機的Pod之間的TCP吞吐量。這是由于物理交換機的性能限制，吞吐量性能受到影響，但N-Net的吞吐量仍然高于其他兩種網(wǎng)絡(luò)插件。

綜上，N-Net與Flannel、Kuryr相比，吞吐量獲得較大提升，驗證了高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略的有效性。

4.4.2 RTT測試

本實驗將RTT作為網(wǎng)絡(luò)延時及網(wǎng)絡(luò)穩(wěn)定性的評判標準，通過比較Kubernetes集群中Pod間RTT值，驗證N-Net的高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略有效性及N-Net的穩(wěn)定性。

在環(huán)境1中，Kubernetes分別部署三種網(wǎng)絡(luò)插件N-Net、Flannel、Kuryr，統(tǒng)計發(fā)送不同數(shù)量數(shù)據(jù)包情況下，同宿主機的Pod之間和跨宿主機的Pod之間的RTT值，實驗結(jié)果如圖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由于高性能網(wǎng)絡(luò)架構(gòu)，流量轉(zhuǎn)發(fā)次數(shù)減少，網(wǎng)絡(luò)性能較高，RTT值與Kuryr和Flannel相比較小。

通過圖6（a）、（b）對比可以發(fā)現(xiàn)，跨宿主機Pod之間的RTT值要高于同宿主機的Pod之間的RTT值，這是由于物理交換機性能限制。

此外由圖6還可以看到，在發(fā)送五種不同數(shù)量的數(shù)據(jù)包時，三種網(wǎng)絡(luò)插件的RTT值變化不大，表明了N-Net與Flannel和Kuryr一樣具有較好的網(wǎng)絡(luò)穩(wěn)定性。

該實驗進一步證明了N-Net高性能網(wǎng)絡(luò)架構(gòu)優(yōu)化策略有效性，同時證明了N-Net具有較好的穩(wěn)定性。

5 結(jié)語

本文設(shè)計并實現(xiàn)了一種新型的Kubernetes網(wǎng)絡(luò)方案N-Net，在保證Kubernetes集群網(wǎng)絡(luò)功能的基礎(chǔ)上，為用戶提供了一種深度定制Pod網(wǎng)絡(luò)的實現(xiàn)方法，同時針對Neutron的網(wǎng)絡(luò)結(jié)構(gòu)進行優(yōu)化，實現(xiàn)高性能網(wǎng)絡(luò)架構(gòu)。在本文的基礎(chǔ)上，后續(xù)工作將對N-Net的網(wǎng)絡(luò)管理功能進行完善和拓展。