微服務(wù)應(yīng)用平臺(tái)的網(wǎng)絡(luò)性能研究與優(yōu)化

畢小紅,劉 淵,陳 飛

(江南大學(xué) 數(shù)字媒體學(xué)院,江蘇 無錫 214122)

0 概述

目前,伴隨著云計(jì)算服務(wù)的快速發(fā)展,百度、阿里巴巴、AWS、Google等互聯(lián)網(wǎng)公司紛紛提供了云平臺(tái)。然而,具有不易擴(kuò)展、難以維護(hù)、升級(jí)風(fēng)險(xiǎn)大等特點(diǎn)的日益龐大的單體應(yīng)用程序,其開發(fā)正變得越來越復(fù)雜,甚至在很大程度上已經(jīng)不能適應(yīng)當(dāng)前快速變化的市場(chǎng)環(huán)境。分布式微服務(wù)軟件架構(gòu)模式以其模塊化、可擴(kuò)展、高可用的應(yīng)用能力以及其促進(jìn)組織架構(gòu)融合方面的優(yōu)勢(shì),可以顯著地為企業(yè)增強(qiáng)市場(chǎng)競(jìng)爭(zhēng)力。雖然微服務(wù)架構(gòu)為應(yīng)用程序的開發(fā)帶來了諸多優(yōu)勢(shì)[1],但是其在構(gòu)建、部署、維護(hù)分布式的微服務(wù)系統(tǒng)方面并不容易。而容器所提供的輕量級(jí)、面向應(yīng)用的虛擬化運(yùn)行環(huán)境為微服務(wù)提供了理想的載體。基于容器技術(shù)的容器集群部署管理工具Kubernetes極大地簡(jiǎn)化了容器化微服務(wù)創(chuàng)建、集成、部署、運(yùn)維的整個(gè)流程,從而推動(dòng)了微服務(wù)在云端的大規(guī)模使用。微服務(wù)由于獨(dú)立進(jìn)程眾多、以容器為應(yīng)用發(fā)布的載體,其架構(gòu)下各組件的溝通、協(xié)調(diào)對(duì)網(wǎng)絡(luò)有較高的要求。目前,基于Flannel的網(wǎng)絡(luò)采用封包解包的NAT機(jī)制實(shí)現(xiàn)網(wǎng)絡(luò)通信,導(dǎo)致了一定的網(wǎng)絡(luò)性能消耗[2]。因此,需要研究更快速的Docker容器網(wǎng)絡(luò)構(gòu)建方式來滿足容器集群對(duì)高帶寬通信服務(wù)的要求。

本文將Calico網(wǎng)絡(luò)與Kubernetes集成進(jìn)行結(jié)合,建立微服務(wù)容器化應(yīng)用平臺(tái),并基于該平臺(tái)對(duì)Web微服務(wù)做進(jìn)一步測(cè)試與評(píng)估。

1 研究現(xiàn)狀

1.1 微服務(wù)與Docker

微服務(wù)架構(gòu)[3]是一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù),其以專注于單一責(zé)任與功能的小型功能區(qū)塊為基礎(chǔ),利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序,各功能區(qū)塊使用與語言無關(guān)的API集相互通信。微服務(wù)采用分布式應(yīng)用,應(yīng)用程序按照功能被分解成一組松耦合的服務(wù),這些程序可能運(yùn)行在不同的設(shè)備上,每個(gè)服務(wù)實(shí)例一般都是一個(gè)進(jìn)程。服務(wù)間的交互通過進(jìn)程間的通信來實(shí)現(xiàn),服務(wù)間的通信[4]意味著需要處理諸如網(wǎng)絡(luò)延遲、不可靠的網(wǎng)絡(luò)和應(yīng)用層中的變化負(fù)載等相關(guān)問題。因此,保證網(wǎng)絡(luò)的可靠性、合理地部署微服務(wù)是有效提高微服務(wù)性能的關(guān)鍵。

Docker[5-6]是一個(gè)基于Go語言開發(fā)、遵從Apache 2.0協(xié)議、輕量級(jí)虛擬化的容器管理引擎。Docker通過Namespace實(shí)現(xiàn)資源隔離,由于該特征,Docker容器在運(yùn)行時(shí)沒有類似于虛擬機(jī)的額外操作系統(tǒng)開銷,從而提高了資源利用率,并且提升了諸如IO等方面的性能。Docker具有細(xì)粒度、松耦合、可移植、輕量級(jí)虛擬化的特點(diǎn),與微服務(wù)的理念相輔相成,為微服務(wù)提供匹配的實(shí)現(xiàn)機(jī)制,可實(shí)質(zhì)性地改變新型應(yīng)用的開發(fā)和發(fā)布方式。

Docker利用傳統(tǒng)客戶端-服務(wù)器的架構(gòu)模式[7],用戶通過Docker客戶端與Docker服務(wù)器進(jìn)行通信,并將請(qǐng)求發(fā)送給服務(wù)器Docker守護(hù)進(jìn)程,Docker守護(hù)進(jìn)程執(zhí)行一系列的容器管理命令。Docker總架構(gòu)如圖1所示。

圖1 Docker總架構(gòu)

1.2 容器網(wǎng)絡(luò)發(fā)展現(xiàn)狀與分析

Docker使用Namespace作為網(wǎng)絡(luò)實(shí)現(xiàn)的基礎(chǔ)。Namespace主要提供關(guān)于網(wǎng)絡(luò)資源的隔離[8],包括網(wǎng)絡(luò)設(shè)備、IPv4和IPv6協(xié)議棧、IP路由表、防火墻等所有網(wǎng)絡(luò)資源[9]。在圖1中,Docker通過driver模塊創(chuàng)建執(zhí)行環(huán)境。Libcontainer是一個(gè)獨(dú)立的容器管理包,當(dāng)需要為容器創(chuàng)建網(wǎng)絡(luò)環(huán)境時(shí),Network driver創(chuàng)建并配置Docker容器的網(wǎng)絡(luò)環(huán)境,通過Libcontainer實(shí)現(xiàn)對(duì)容器的具體操作。目前,Docker總架構(gòu)中網(wǎng)絡(luò)部分已經(jīng)被抽離出來,稱之為L(zhǎng)ibnetwork[9]模塊,Libnetwork定義一個(gè)容器網(wǎng)絡(luò)模型,提供一個(gè)一致的編程接口和應(yīng)用程序網(wǎng)絡(luò)抽象,可以通過插件的形式給容器提供網(wǎng)絡(luò)功能,也可以與第三方網(wǎng)絡(luò)插件進(jìn)行結(jié)合以滿足開發(fā)者在各種場(chǎng)景下的需要。Libnetwork容器網(wǎng)絡(luò)模型如圖2所示。其中,網(wǎng)絡(luò)Sandbox[10]代表容器的網(wǎng)絡(luò)命名空間,包含容器的完整網(wǎng)絡(luò)棧,不同的容器間可以完全隔離。Endpoint相當(dāng)于一個(gè)容器接入網(wǎng)絡(luò)的虛擬網(wǎng)卡。Network代表一組可以直接相互通信的容器集合。宿主機(jī)上同一網(wǎng)絡(luò)的容器都通過Veth鏈接到該網(wǎng)絡(luò)命名空間上。

圖2 Libnetwork容器網(wǎng)絡(luò)模型

Docker從其1.9版本開始,就實(shí)現(xiàn)了基于Libnetwork的多主機(jī)覆蓋網(wǎng)絡(luò)模式[11],其中包括bridge、host、null、remote、overlay、macvlan 6種網(wǎng)絡(luò)驅(qū)動(dòng),bridge是Docker默認(rèn)的網(wǎng)絡(luò)驅(qū)動(dòng),Libnetwork的remote驅(qū)動(dòng)定義了基本的創(chuàng)建網(wǎng)絡(luò)、創(chuàng)建端口的接口,對(duì)應(yīng)的REST Server實(shí)現(xiàn)了這些接口,并可以提供整套Docker網(wǎng)絡(luò)。

隨著Docker的迅速發(fā)展,越來越多的云計(jì)算廠商開始探索Docker在實(shí)際生產(chǎn)環(huán)境中的應(yīng)用。由于Docker原生網(wǎng)絡(luò)功能無法滿足廣大云計(jì)算廠商的要求,因此出現(xiàn)了大批第三方SDN解決方案,以彌補(bǔ)在部署大規(guī)模Docker集群時(shí)Docker網(wǎng)絡(luò)性能低下、功能不足的缺陷。文獻(xiàn)[12]針對(duì)Kubernetes設(shè)計(jì)了一個(gè)重載網(wǎng)絡(luò)工具Flannel。文獻(xiàn)[13]開發(fā)了跨宿主機(jī)的容器網(wǎng)絡(luò)工具Weave和Calico跨主機(jī)網(wǎng)絡(luò)插件等。文獻(xiàn)[14]創(chuàng)建了一個(gè)虛擬網(wǎng)絡(luò),通過在容器中添加專用的虛擬網(wǎng)卡來搭建自己的網(wǎng)絡(luò),用以連接部署在多臺(tái)主機(jī)上的Docker容器。基于Weave網(wǎng)絡(luò)的容器如同被接入了同一個(gè)網(wǎng)絡(luò)交換機(jī),從而在不破壞Docker容器原有網(wǎng)絡(luò)的同時(shí),實(shí)現(xiàn)了跨主機(jī)通信。Weave能夠穿透防火墻并運(yùn)行在部分連接的網(wǎng)絡(luò)上,此外,Weave的通信支持加密,因此,用戶可以通過一個(gè)不受信任的網(wǎng)絡(luò)連接到主機(jī)[15]。但是,從性能和使用角度來看,Weave也有較大的缺陷:Weave自定義容器數(shù)據(jù)包封包解包方式的傳輸效率較低,性能上的損失也較大,集群配置較復(fù)雜,需要通過Weave命令行來手工構(gòu)建網(wǎng)絡(luò)拓?fù)?這在大規(guī)模集群的情況下自動(dòng)化程度較低。

Flannel是由CoreOS團(tuán)隊(duì)針對(duì)Kubernetes設(shè)計(jì)的一個(gè)重載網(wǎng)絡(luò)工具,其目的在于幫助每一個(gè)使用Kubernetes的CoreOS主機(jī)構(gòu)建一個(gè)完整的子網(wǎng)[16]。類似于Weave、Vxlan,Flannel提供了一個(gè)可配置的虛擬覆蓋網(wǎng)絡(luò)。Flannel以守護(hù)進(jìn)程的形式運(yùn)行,負(fù)責(zé)子網(wǎng)的分配,使用Etcd存儲(chǔ)、交換網(wǎng)絡(luò)配置、狀態(tài)等信息,其網(wǎng)絡(luò)架構(gòu)如圖3所示。

圖3 Flannel網(wǎng)絡(luò)架構(gòu)

Flannel和Overlay方案均使用覆蓋網(wǎng)絡(luò)[17],盡管覆蓋網(wǎng)絡(luò)對(duì)底層網(wǎng)絡(luò)依賴較少,配置相對(duì)簡(jiǎn)單,但是其網(wǎng)絡(luò)封裝是一種傳輸開銷,對(duì)網(wǎng)絡(luò)性能會(huì)有影響,不適用于對(duì)網(wǎng)絡(luò)性能要求較高的生產(chǎn)場(chǎng)景,且由于對(duì)底層網(wǎng)絡(luò)結(jié)構(gòu)缺乏了解,因此覆蓋網(wǎng)絡(luò)無法做到真正有效地控制流量,這也會(huì)對(duì)網(wǎng)絡(luò)性能產(chǎn)生影響[18]。

2 Calico網(wǎng)絡(luò)與Kubernetes集成

Calico[19]是一個(gè)3層的數(shù)據(jù)中心網(wǎng)絡(luò)方案,能夠支持高效可控的虛擬機(jī)、容器、裸機(jī)間的通信,其基于BPG協(xié)議和Linux本身的路由轉(zhuǎn)發(fā)機(jī)制,不依賴特殊硬件,沒有使用NAT或Tunnel等技術(shù)。Calico沒有使用重載網(wǎng)絡(luò),能夠方便地部署在物理服務(wù)器、虛擬機(jī)(如OpenStack)及容器環(huán)境下。同時(shí),其自帶的基于Iptables的訪問控制(ACL)管理組件,能夠滿足比較復(fù)雜的安全隔離需求。Calico為每個(gè)工作負(fù)載提供一個(gè)完全自動(dòng)化的虛擬防火墻,以保護(hù)工作負(fù)載,并在該工作負(fù)載受損時(shí)保護(hù)其余應(yīng)用程序。Calico能夠自動(dòng)將任何網(wǎng)絡(luò)策略概念從編排環(huán)境映射到Calico網(wǎng)絡(luò)環(huán)境[20]。

Calico使用與互聯(lián)網(wǎng)相似的原則構(gòu)建其高度可擴(kuò)展的網(wǎng)絡(luò)架構(gòu),并提供一個(gè)平面IP網(wǎng)絡(luò),可以在沒有任何封裝的情況下進(jìn)行通信。此外,其網(wǎng)絡(luò)架構(gòu)還使用無狀態(tài)IP-in-IP覆蓋,可以路由已存在的覆蓋網(wǎng)絡(luò)數(shù)據(jù)包。基于Calico的容器網(wǎng)絡(luò)實(shí)現(xiàn)3層隔離,有效避免了ARP風(fēng)暴。此外,基于Iptable/Linux內(nèi)核轉(zhuǎn)發(fā),有效提高了轉(zhuǎn)發(fā)效率,降低了性能損耗。

Kubernetes是Google開發(fā)的集群管理系統(tǒng)平臺(tái),其在Docker技術(shù)的基礎(chǔ)上被構(gòu)建出來[21],為容器化的應(yīng)用提供資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)、灰度升級(jí)及在線升級(jí)等一系列功能。同時(shí),Kubernetes還提供了完善的管理工具,可以進(jìn)行管理開發(fā)、測(cè)試、監(jiān)控的各個(gè)環(huán)節(jié)。因此,Kubernetes能夠提供一個(gè)全新的基于容器技術(shù)的分布式架構(gòu)解決方案。

Kubernetes的網(wǎng)絡(luò)基于Docker設(shè)計(jì),其模型的設(shè)計(jì)遵循以下原則:每個(gè)Pod都有一個(gè)獨(dú)立的IP地址,所有的Pod都在一個(gè)可以連通的扁平網(wǎng)絡(luò)空間中。運(yùn)行在不同的基礎(chǔ)設(shè)施節(jié)點(diǎn)上的Pod可以通過IP地址進(jìn)行互相訪問。同時(shí),在Kubernetes集群的網(wǎng)絡(luò)中,所有的容器都不用NAT的方式進(jìn)行通信,所有節(jié)點(diǎn)都可以直接通信。在Kubernetes系統(tǒng)中,同一個(gè)Pod內(nèi)的不同容器共享一個(gè)網(wǎng)絡(luò)命名空間,同一個(gè)Pod內(nèi)的容器可以通過本機(jī)連接另一容器的端口,且可以共享部分資源,通過共享資源,容器之間的相互通信可以更高效。Google公司設(shè)計(jì)的Kubernetes主要在云環(huán)境GCE中運(yùn)行,在該環(huán)境下,Kubernetes無需第三方網(wǎng)絡(luò)支持。但是,若脫離GCE環(huán)境運(yùn)行Kubernetes與Docker集成平臺(tái),就需要網(wǎng)絡(luò)插件的支持。目前,Kubernetes使用第三方支持的Flannel網(wǎng)絡(luò)插件實(shí)現(xiàn)網(wǎng)絡(luò)通信。

2.1 Calico網(wǎng)絡(luò)架構(gòu)

Calico網(wǎng)絡(luò)架構(gòu)及其核心組件如圖4所示。Calico架構(gòu)主要由Felix、Etcd、BGP 客戶端、BIRD(路由反射器)4個(gè)核心組件構(gòu)成。Felix運(yùn)行在每臺(tái)需要運(yùn)行容器的節(jié)點(diǎn)上,負(fù)責(zé)配置路由及ACLs等信息來確保各終端的連通狀態(tài);Etcd是分布式鍵值存儲(chǔ),負(fù)責(zé)網(wǎng)絡(luò)元數(shù)據(jù)的一致性,確保Calico網(wǎng)絡(luò)狀態(tài)的準(zhǔn)確性;BGP客戶端負(fù)責(zé)把Felix寫入內(nèi)核的路由信息并分發(fā)到當(dāng)前Calico網(wǎng)絡(luò),確保節(jié)點(diǎn)間通信的有效性;BIRD(路由反射器)是在大規(guī)模部署時(shí)使用,其摒棄所有節(jié)點(diǎn)互聯(lián)的網(wǎng)格模式,通過一個(gè)或多個(gè)BIRD(路由反射器)來完成集中式的路由分發(fā)。

圖4 Calico網(wǎng)絡(luò)架構(gòu)

Calico網(wǎng)絡(luò)在每一個(gè)節(jié)點(diǎn)利用Linux內(nèi)核實(shí)現(xiàn)一個(gè)虛擬路由,以此負(fù)責(zé)數(shù)據(jù)的轉(zhuǎn)發(fā),每個(gè)虛擬路由通過BGP協(xié)議將自身運(yùn)行的路由信息向整個(gè)Calico網(wǎng)絡(luò)內(nèi)傳播,較小規(guī)模的應(yīng)用部署可以直接互聯(lián),大規(guī)模應(yīng)用下,可通過指定的BIRD(路由反射器)來完成通信。在Calico中,數(shù)據(jù)包有可能跨多個(gè)節(jié)點(diǎn)傳輸,但是無需對(duì)其中間節(jié)點(diǎn)進(jìn)行配置。對(duì)于一個(gè)被送到容器的數(shù)據(jù)包,最后的一跳是從該容器的宿主到容器自身。此外,Calico基于Iptables還提供豐富而靈活的網(wǎng)絡(luò)策略,通過各個(gè)節(jié)點(diǎn)上的訪問控制(ACLs)來提供工作節(jié)點(diǎn)的多租戶隔離、安全組以及其他可達(dá)性限制等功能。

2.2 基于Calico與Kubernetes集成的網(wǎng)絡(luò)通信

本文設(shè)計(jì)的基于Calico網(wǎng)絡(luò)與Kubernetes集成的網(wǎng)絡(luò)通信架構(gòu)模型如圖5所示。其中,API是整個(gè)集群的核心,負(fù)責(zé)各個(gè)模塊之間的通信。集群內(nèi)部的功能模塊通過API將信息存入Etcd,控制器、調(diào)度器通過API讀取這些信息,從而實(shí)現(xiàn)各模塊之間的信息交換。

圖5 基于Calico與Kubernetes的網(wǎng)絡(luò)通信架構(gòu)

控制器作為集群內(nèi)部的管理控制中心,主要負(fù)責(zé)管理Node、Pod副本、服務(wù)端點(diǎn)、命名空間、服務(wù)賬號(hào)、資源定額等處于預(yù)期的工作狀態(tài)。調(diào)度器的作用是實(shí)時(shí)監(jiān)測(cè)集群中已調(diào)度的Pod及待調(diào)度的Pod,按照特定的調(diào)度算法和調(diào)度策略將其綁定到集群中的一個(gè)Node節(jié)點(diǎn)上,并將信息寫入Etcd中。Kube-proxy通過Etcd客戶端監(jiān)測(cè)服務(wù)器和終端的變化,當(dāng)新增服務(wù)時(shí),服務(wù)處于監(jiān)聽狀態(tài),此時(shí)初始化Iptable規(guī)則。當(dāng)新增終端endpoint時(shí),注冊(cè)endpoint以便負(fù)載均衡器選擇。Node節(jié)點(diǎn)上的Kubelet周期性地向API報(bào)告自身的狀態(tài),API接受后將信息保存到Etcd中,并監(jiān)測(cè)來自File、Etcd、Http的Pod配置信息,當(dāng)配置發(fā)生變化時(shí),Kubernetes把期望狀態(tài)和當(dāng)前運(yùn)行狀態(tài)進(jìn)行同步。在Kubernetes集群中,每個(gè)工作節(jié)點(diǎn)上都會(huì)運(yùn)行Kubelet以守護(hù)進(jìn)程,Kubelet處理Master發(fā)布給本節(jié)點(diǎn)的任務(wù)。并用Pause容器為每個(gè)Pod創(chuàng)建容器。

Calico作為Kubernetes依賴的底層網(wǎng)絡(luò),在每個(gè)Node節(jié)點(diǎn)上構(gòu)建虛擬路由,通過Calico虛擬路由可將本節(jié)點(diǎn)上在同一網(wǎng)段中的網(wǎng)絡(luò)報(bào)文以原始的狀態(tài)傳遞到目標(biāo)容器中。該過程的實(shí)現(xiàn)無需如Flannel網(wǎng)絡(luò)的疊加網(wǎng)絡(luò)傳遞過程,從而可以大大降低網(wǎng)絡(luò)性能損耗。

3 實(shí)驗(yàn)測(cè)試與結(jié)果分析

3.1 實(shí)驗(yàn)配置環(huán)境

本文實(shí)驗(yàn)的3個(gè)操作系統(tǒng)為Centos 7.0虛擬機(jī),內(nèi)存1 GB,CPU 1核,主頻為2.6 GHz,IP地址分別為192.168.159.128(Kube-Master節(jié)點(diǎn)),192.168.159.129(Node節(jié)點(diǎn)),192.168.159.130(Node節(jié)點(diǎn)),其中,Master節(jié)點(diǎn)作為Kubernetes集群中的管理節(jié)點(diǎn),2個(gè)Node節(jié)點(diǎn)作為Kubernetes集群中的工作節(jié)點(diǎn)。實(shí)驗(yàn)采用一個(gè)可訪問的Etcd集群(192.168.159.128:2379),Calico使用其進(jìn)行數(shù)據(jù)的存放和服務(wù)發(fā)現(xiàn)。此外,將3個(gè)節(jié)點(diǎn)上的Iptables INPUT策略設(shè)為ACCEPT,同時(shí)安裝Docker,并設(shè)置Docker守護(hù)進(jìn)程的啟動(dòng),參數(shù)cluster-store為Etcd集群(192.168.159.128:2379)。分布式安裝并配置Kubernetes容器編排系統(tǒng),設(shè)置192.168.159.128主機(jī)為Kube-Master節(jié)點(diǎn),其余2個(gè)主機(jī)為Kube-Node節(jié)點(diǎn)。在Node節(jié)點(diǎn)上安裝Calico-cni插件,當(dāng)Pod創(chuàng)建后,將該P(yáng)od添加到Calico網(wǎng)絡(luò)。使用Calico進(jìn)行網(wǎng)絡(luò)的連接和IPAM的配置。代碼如下所示。

{

“name”:“my_name”,

“type”:“Calico”,

“Kubernetes”:{

“k8s_api_root”:“http://192.168.159.128:8080”

}

“IPAM”:{

“type”:“Calico-IPAM”

}

}

Calico網(wǎng)絡(luò)控制器運(yùn)行在Kubernetes的Pod里,實(shí)現(xiàn)了多種網(wǎng)絡(luò)策略的自定義。網(wǎng)絡(luò)策略管理網(wǎng)絡(luò)的連通性。網(wǎng)絡(luò)策略通過Label標(biāo)簽篩選作用到每個(gè)Pod和服務(wù)上,同時(shí)需要網(wǎng)絡(luò)插件配合實(shí)現(xiàn)網(wǎng)絡(luò)策略。

Calico節(jié)點(diǎn)啟動(dòng)后會(huì)查詢Etcd,其他Calico節(jié)點(diǎn)使用BGP協(xié)議建立連接。容器啟動(dòng)時(shí),劫持相關(guān)Docker API并進(jìn)行網(wǎng)絡(luò)初始化。查詢Etcd自動(dòng)分配一個(gè)可用IP,創(chuàng)建一對(duì)Veth接口用于容器和主機(jī)間的通信,并在主機(jī)路由表添加指向該接口的路由。

3.2 Calico網(wǎng)絡(luò)測(cè)試與結(jié)果分析

通過上述對(duì)Calico網(wǎng)絡(luò)和其他各種網(wǎng)絡(luò)的通信原理之間的比較,以及對(duì)Kubernetes網(wǎng)絡(luò)原理進(jìn)行的分析,理論上可以得出,基于Calico的Docker網(wǎng)絡(luò)具有良好的網(wǎng)絡(luò)性能,Calico網(wǎng)絡(luò)與Kubernetes的集成設(shè)計(jì)具有可行性。本文在相同的測(cè)試環(huán)境下進(jìn)一步對(duì)Docker容器在跨主機(jī)通信中不同的網(wǎng)絡(luò)模式進(jìn)行實(shí)驗(yàn)測(cè)試,通過實(shí)驗(yàn)分析Calico的網(wǎng)絡(luò)性能。

Iperf3是一種開源的網(wǎng)絡(luò)性能測(cè)試工具,可以測(cè)量最大TCP帶寬,此外,其具有多種參數(shù)和UDP特性,可以報(bào)告帶寬、延遲抖動(dòng)和數(shù)據(jù)包丟失等數(shù)據(jù)。本文采用Iperf3測(cè)試容器帶寬以得出平均網(wǎng)絡(luò)傳輸速率。

3.2.1 網(wǎng)絡(luò)測(cè)試方案

第2節(jié)詳細(xì)敘述了Calico網(wǎng)絡(luò)與Kubernetes集成的實(shí)現(xiàn),本節(jié)在此基礎(chǔ)上對(duì)該網(wǎng)絡(luò)的性能進(jìn)行針對(duì)性的測(cè)試,同時(shí)在相同環(huán)境下將其與其他多主機(jī)容器網(wǎng)絡(luò)性能進(jìn)行比較,構(gòu)建Docker容器并測(cè)試不同容器間的通信質(zhì)量。本文實(shí)驗(yàn)采用帶寬性能指標(biāo)來體現(xiàn)網(wǎng)絡(luò)的傳輸速率與性能,實(shí)驗(yàn)測(cè)試方案如表1所示。

表1 網(wǎng)絡(luò)測(cè)試方案

方案的設(shè)計(jì)主要針對(duì)微服務(wù)之間的通信模式,測(cè)試其網(wǎng)絡(luò)速率。方案1針對(duì)單宿主機(jī),在基于bridge、Weave、Flannel、Calico網(wǎng)絡(luò)模式下,容器C1作為Iperf3服務(wù)器,容器C2作為Iperf3客戶端,測(cè)試Docker容器的通信速率并進(jìn)行比較。方案2測(cè)試容器跨主機(jī)通信的模式,當(dāng)容器底層為overlay、Weave、Flannel、Calico與物理主機(jī)網(wǎng)絡(luò)時(shí),將通信速率進(jìn)行比較。通過上述測(cè)試反映出容器網(wǎng)絡(luò)在通信過程中的損耗。

上述方案對(duì)容器節(jié)點(diǎn)對(duì)進(jìn)行了網(wǎng)絡(luò)性能比較,本文進(jìn)一步從微服務(wù)應(yīng)用的角度考慮,增加Node節(jié)點(diǎn),并在多容器節(jié)點(diǎn)的環(huán)境下測(cè)試Calico網(wǎng)絡(luò)性能的變化。在待新增Node上部署好軟件環(huán)境,并修改Kubernetes的配置文件,指定主節(jié)點(diǎn)IP地址和端口號(hào),再啟動(dòng)該Node上的Kubelete和Kube-proxy服務(wù),實(shí)現(xiàn)軟件環(huán)境Node節(jié)點(diǎn)的擴(kuò)展。最后,分別在容器節(jié)點(diǎn)數(shù)量為2、10、20、30、40、50、60、70、80、90、100時(shí),測(cè)試網(wǎng)絡(luò)速率的變化情況。

3.2.2 測(cè)試結(jié)果分析

針對(duì)表1中的2種方案進(jìn)行TCP測(cè)試,多次測(cè)量容器在60 s內(nèi)傳輸?shù)臄?shù)據(jù)信息量和帶寬數(shù)據(jù),結(jié)果如圖6、圖7所示。

圖6 單宿主機(jī)不同網(wǎng)絡(luò)模式下的帶寬比較

圖7 跨宿主機(jī)不同網(wǎng)絡(luò)模式下的帶寬比較

在多節(jié)點(diǎn)環(huán)境下,Calico的網(wǎng)絡(luò)性能測(cè)試結(jié)果如圖8所示。

圖8 多節(jié)點(diǎn)下Calico網(wǎng)絡(luò)性能

本文實(shí)驗(yàn)是在同一軟、硬件環(huán)境配置的基礎(chǔ)上進(jìn)行的,由圖6可以看出,單節(jié)點(diǎn)情況下各種網(wǎng)絡(luò)的通信速率相差甚微,說明容器在同一宿主機(jī)中的網(wǎng)絡(luò)傳輸損耗相對(duì)較少。因此,在微服務(wù)應(yīng)用的部署方式上,可以考慮盡可能地將耦合度比較高的容器應(yīng)用部署在同一臺(tái)宿主機(jī)上,這樣會(huì)大大提高微服務(wù)應(yīng)用的效率。由圖7可以看出,在進(jìn)行跨主機(jī)通信時(shí),基于Calico網(wǎng)絡(luò)容器的傳輸速率非常接近于宿主機(jī)的傳輸速率,基于Weave、Flannel、overlay網(wǎng)絡(luò)的容器在數(shù)據(jù)轉(zhuǎn)發(fā)速率上,相對(duì)于物理網(wǎng)絡(luò)損耗了約50%,其中Flannel網(wǎng)絡(luò)帶寬只占物理網(wǎng)絡(luò)的10%左右。由圖8可以看出,隨著容器節(jié)點(diǎn)數(shù)的增加,網(wǎng)絡(luò)性能有所下降,但是相對(duì)于單節(jié)點(diǎn)對(duì)下Flannel網(wǎng)絡(luò)的性能,多節(jié)點(diǎn)下的Calico網(wǎng)絡(luò)仍然具有很大的性能優(yōu)勢(shì)。因此,在大規(guī)模的微服務(wù)應(yīng)用部署和調(diào)度上,基于Calico網(wǎng)絡(luò)的容器在性能上具有明顯的優(yōu)勢(shì)。

4 微服務(wù)應(yīng)用的設(shè)計(jì)與實(shí)現(xiàn)

4.1 Web微服務(wù)應(yīng)用設(shè)計(jì)

通過Docker容器的Calico網(wǎng)絡(luò)與Kubernetes集成構(gòu)建微服務(wù)應(yīng)用的PaaS平臺(tái),本文通過設(shè)計(jì)Web微服務(wù)應(yīng)用案例,進(jìn)一步驗(yàn)證該平臺(tái)的高可用性及強(qiáng)大的擴(kuò)展能力。Web應(yīng)用系統(tǒng)架構(gòu)如圖9所示。

圖9 Web微服務(wù)應(yīng)用系統(tǒng)架構(gòu)

Web微服務(wù)應(yīng)用系統(tǒng)是基于PHP+Redis 2層分布式架構(gòu)的Web應(yīng)用,通過Web讀寫分離的高可用集群進(jìn)行部署。其中共有3個(gè)service和16個(gè)Pod節(jié)點(diǎn),每個(gè)Pod中運(yùn)行一個(gè)容器。主數(shù)據(jù)庫(kù)Redis Pod運(yùn)行Master-Redis數(shù)據(jù)庫(kù)容器,用于Web應(yīng)用進(jìn)行“寫”的操作,將“寫”的內(nèi)容保存在Redis-Master中;從數(shù)據(jù)庫(kù)Redis Pod運(yùn)行Redis-slave容器,同時(shí)采用5個(gè)Pod構(gòu)建,用于前端Web讀取數(shù)據(jù),并與Master-Redis中數(shù)據(jù)保持同步。Frontend-Pod運(yùn)行PHP Web服務(wù),在網(wǎng)頁上輸入和輸出內(nèi)容,同時(shí)啟動(dòng)10個(gè)實(shí)例組成集群,實(shí)現(xiàn)客戶端對(duì)網(wǎng)站訪問的負(fù)載均衡。通過Kubectl客戶端命令(Kubectl scale rc-replicas=x)改變r(jià)eplicas參數(shù)的值來增加Pod數(shù)量,通過命令Kubectl rolling-update -f xx.yaml來升級(jí)Pod中容器,實(shí)現(xiàn)應(yīng)用容器的可擴(kuò)展,最后,創(chuàng)建Redis-Master服務(wù)、Redis-slave服務(wù)和php-Frontend服務(wù)。

4.2 系統(tǒng)實(shí)現(xiàn)

系統(tǒng)實(shí)現(xiàn)硬件環(huán)境:采用VMware Workstation 10虛擬網(wǎng)卡,3臺(tái)64位的Centos 7虛擬機(jī),內(nèi)存1 GB,Intel CPU 1核,主頻為2.6 GHz。軟件環(huán)境:操作系統(tǒng) Liunx/amd 64,底層網(wǎng)絡(luò)采用Calico v 1.0.2,高可用存儲(chǔ)軟件Etcd v 3.0.5,容器編排軟件Kubernetes v 1.4,Docker容器v 1.12。

通過Makefile構(gòu)建所需要的Redis容器和Web頁面容器,上傳至鏡像倉(cāng)庫(kù),配置服務(wù)及副本控制器的yaml文件,利用Kubernetes創(chuàng)建并啟動(dòng)容器。服務(wù)器通過Labels標(biāo)簽選擇Pod對(duì)象實(shí)現(xiàn)負(fù)載均衡功能。設(shè)置NodePod參數(shù)映射物理機(jī)端口,提供服務(wù)器的對(duì)外訪問。服務(wù)器之間通過Kubernetes系統(tǒng)中的DNS進(jìn)行注冊(cè)與發(fā)現(xiàn),進(jìn)而實(shí)現(xiàn)微服務(wù)之間的通信。系統(tǒng)搭建完成后,用戶通過訪問服務(wù)器地址以訪問Web系統(tǒng),其中系統(tǒng)內(nèi)部Pod之間的相互通信通過查詢服務(wù)器IP地址和端口號(hào)實(shí)現(xiàn),客戶端獲得服務(wù)列表如表2所示。

表2 服務(wù)列表

利用Web壓力測(cè)試工具測(cè)試整個(gè)場(chǎng)景中所有請(qǐng)求的響應(yīng)情況。在場(chǎng)景中每個(gè)請(qǐng)求都有一個(gè)響應(yīng)時(shí)間,其中50%的用戶響應(yīng)時(shí)間小于1 043 ms,60%的用戶響應(yīng)時(shí)間小于1 147 ms,最大的響應(yīng)時(shí)間小于8 785 ms。Web服務(wù)器每秒處理的請(qǐng)求數(shù)為87,相對(duì)基于Flannel網(wǎng)絡(luò)的處理請(qǐng)求數(shù)目(63)提高了38%。實(shí)驗(yàn)結(jié)果表明,Web服務(wù)器處理并發(fā)請(qǐng)求時(shí)對(duì)網(wǎng)絡(luò)的性能具有依賴性,本文對(duì)應(yīng)用部署平臺(tái)網(wǎng)絡(luò)性能進(jìn)行了優(yōu)化,提高了微服務(wù)的應(yīng)用能力,同時(shí)也驗(yàn)證了Kubernetes的高可用性與高效性。

5 結(jié)束語

本文研究基于Calico網(wǎng)絡(luò)的容器化應(yīng)用平臺(tái),提出實(shí)現(xiàn)微服務(wù)容器化應(yīng)用的方案,實(shí)驗(yàn)結(jié)果表明,該方案能有效提高容器跨主機(jī)網(wǎng)絡(luò)通信的性能,為Docker容器提供了豐富、靈活和安全的網(wǎng)絡(luò)策略。此外,因?yàn)镃alico網(wǎng)絡(luò)易于部署,可擴(kuò)展至數(shù)以萬計(jì)的服務(wù)器和數(shù)以百萬的工作負(fù)載,所以本文方案也為大規(guī)模分布式部署微服務(wù)應(yīng)用提供了理想的網(wǎng)絡(luò)解決途徑。下一步將針對(duì)網(wǎng)絡(luò)的規(guī)模和穩(wěn)定性做深入探究。

[1] 郝庭毅,吳 恒,吳國(guó)全,等.面向微服務(wù)架構(gòu)的容器級(jí)彈性資源供給方法[J].計(jì)算機(jī)研究與發(fā)展,2017,54(3):597-608.

[2] RAMALHO F,NETO A.Virtualization at the network edge:a performance comparison[C]//Proceedings of 2016 IEEE International Symposium on a World of Wireless,Mobile and Multimedia Networks.Washington D.C.,USA:IEEE Press,2016:1-6.

[3] YOUSIF M.Microservices[J].IEEE Cloud Computing,2016,3(5):4-5.

[4] BALALAIE A,HEYDARNOORI A,JAMSHIDI P.Microservices architecture enables DevOps:migration to a cloud-native architecture[J].IEEE Software,2016,33(3):42-52.

[5] 王 鵑,胡 威,張雨菡,等.基于Docker的可信容器[J].武漢大學(xué)學(xué)報(bào)(理學(xué)版),2017,63(2):15-25.

[6] BERNSTEIN D.Containers and cloud:from LXC to docker to Kubernetes[J].IEEE Cloud Computing,2014,1(3):81-84.

[7] 楊 鵬,馬志程,彭 博,等.集成Docker容器的OpenStack云平臺(tái)性能研究[J].計(jì)算機(jī)工程,2017,43(8):26-31.

[8] 齊 勇.基于docker的網(wǎng)絡(luò)服務(wù)質(zhì)量控制器的設(shè)計(jì)與實(shí)現(xiàn)[D].濟(jì)南:山東大學(xué),2015.

[9] Docker container networking[EB/OL].[2017-05-10].https://docs.docker.com/ engine/userguide/networking/.

[10] EDELMAN J.Docker networking[EB/OL].[2017-04-25].http://www.dasblinkenlichten.com/docker-networking-101-hostmode/.

[11] XIE Bin,SUN Guanyi,GUO Ma.Docker based overlay network performance evaluation in large scale streaming system[C]//Proceedings of 2016 IEEE Conference on Advanced Information Management,Communicates,Electronic and Automation Control.Washington D.C.,USA:IEEE Press,2016:366-369.

[12] 龔 正,吳治輝,葉伙榮,等.Kubernetes權(quán)威指南[M].北京:電子工業(yè)出版社,2016.

[13] Google.Calico documentation[EB/OL].[2017-05-10].http://docs.projectcalico.org/v2.0/introduction/.

[14] 馮明振.基于macvlan的Docker容器網(wǎng)絡(luò)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].杭州:浙江大學(xué),2016.

[15] 王亞玲,李春陽,崔 蔚,等.基于Docker的PaaS平臺(tái)建設(shè)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2016,25(3):72-77.

[16] DUSIA A,YANG Y,TAUFER M.Network quality of service in Docker containers[C]//Proceedings of 2015 IEEE International Conference on Cluster Computing.Washington D.C.,USA:IEEE Press,2015:527-528.

[17] 何震葦,嚴(yán)麗云,李慧云.基于開源PaaS技術(shù)的互聯(lián)網(wǎng)業(yè)務(wù)平臺(tái)自動(dòng)部署方案[J].電信科學(xué),2015,31(10):172-179.

[18] JARAMILLO D,NGUYEN D V,SMART R.Leveraging microservices architecture by using Docker technology[J].IEEE SoutheastCon,2016,16(5):1-5.

[19] CALINCIUC A,SPOIALA C C,TURCU C O,et al.OpenStack and Docker:building a high-performance IaaS platform for interactive social media applications[C]//Proceedings of 2016 International Conference on Develop-ment and Application Systems.Washington D.C.,USA:IEEE Press,2016:287-290.

[20] Google.Network policies[EB/OL].[2017-05-10].http://Kubernetes.kansea.com/docs/user-guide/networkpolicies.

[21] MEDEL V,RANA O,BAARESJ,et al.Adaptive appli-cation scheduling under interference in Kubernetes[C]//Proceedings of the 9th IEEE/ACM International Conference on Utility and Cloud Computing.Washington D.C.,USA:IEEE Press,2016:426-427.