尚佳友,王曉鋒,劉淵
(江南大學人工智能與計算機學院,無錫214122)
隨著硬件性能的不斷提升,資源過剩成為當前面臨的一個主要問題,云計算技術應運而生[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底層網絡架構,在保證網絡穩定性的前提下,提升網絡性能。
本節首先對Kubernetes的網絡架構進行介紹,接著針對主流的基于CNI的網絡方案進行介紹,最后針對云平臺相關組件進行介紹。
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并沒有為用戶提供與網絡資源交互的接口。
與本文研究相關的主要有以下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集群的網絡性能受限。
Neutron[14]是OpenStack[15]組件之一,其設計目標是“網絡即服務”,將網絡作為服務提供給用戶。Neutron提供網絡連接、二層交換網絡、三層路由、DHCP等網絡功能,可為云環境提供虛擬網絡。此外,Neutron遵循SDN的設計思想,為復雜網絡環境下的虛擬化網絡資源管理及配置提供了有力的支撐[16]。Neutron底層網絡結構通過Open vSwitch虛擬交換機實現流量轉發,從而保障網絡的通信功能。
Keystone[17]是OpenStack的組件之一,具有認證、鑒權等功能,為OpenStack其他組件提供統一的認證服務。Keystone可以為云環境的安全提供有力支撐。
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。
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。
本節針對N-Net的特點優勢進行詳細介紹:①創新性地提出深度定制Pod網絡的方法,通過kubenetctl實現用戶與網絡資源之間的深度交互;②提出高性能網絡架構優化策略,提高網絡性能。
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網絡的深度定制。
越來越多的云計算廠商開始探索在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集群的網絡性能。
本節通過四個實驗對N-Net進行網絡功能及網絡性能的驗證分析。
構建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。
本實驗驗證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狀態信息查詢
本實驗通過測試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.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具有較好的穩定性。
本文設計并實現了一種新型的Kubernetes網絡方案N-Net,在保證Kubernetes集群網絡功能的基礎上,為用戶提供了一種深度定制Pod網絡的實現方法,同時針對Neutron的網絡結構進行優化,實現高性能網絡架構。在本文的基礎上,后續工作將對N-Net的網絡管理功能進行完善和拓展。