干貨 | 博云基于OVS自研容器網(wǎng)絡(luò)插件在金融企業(yè)的落地實踐

本文根據(jù)博云在dockerone社區(qū)微信群分享內(nèi)容整理

過去幾年博云在企業(yè)中落地容器云平臺遇到了很多痛點，其中一個比較典型的痛點來自網(wǎng)絡(luò)方面，今天很高興跟大家聊聊這個話題并介紹下我們基于OVS自研的CNI插件——內(nèi)部稱之為fabric項目。

01

容器平臺落地時網(wǎng)絡(luò)方面的需求

從2013年左右Docker技術(shù)在開發(fā)者中流行起來，到如今kubernetes已經(jīng)成為事實上的容器編排引擎，容器、微服務(wù)、DevOps互相支持互相促進，容器云平臺的實際落地案例開始越來越多。特別是2018年以來，越來越多的企業(yè)開始思考如何利用容器云平臺支持其生產(chǎn)場景最終提高生產(chǎn)效率。

不同于開發(fā)測試場景，生產(chǎn)場景上線一套平臺或系統(tǒng)要求會嚴格很多。安全、監(jiān)控、流程、現(xiàn)有系統(tǒng)集成、業(yè)務(wù)暴露等等的建設(shè)要求都要匹配上，否則不可能上線。在這個過程中，特別是在傳統(tǒng)的金融類企業(yè)對監(jiān)管要求嚴格的情況下，容器云平臺落地時會碰到很多問題，這其中，最典型的一個需求就是容器云平臺的網(wǎng)絡(luò)建設(shè)，必須同時滿足業(yè)務(wù)方，運維人員，安全人員，網(wǎng)絡(luò)人員的訴求。

現(xiàn)在容器云平臺大部分都是基于Kubernetes構(gòu)建，市面上的CNI插件也非常多，各個企業(yè)現(xiàn)網(wǎng)的需求也有很大的不同，所以幾乎不可能出現(xiàn)一種網(wǎng)絡(luò)模型適配所有客戶場景的情況?，F(xiàn)在主流的比較成熟穩(wěn)定的CNI比如calico在擴展性、穩(wěn)定性等方面表現(xiàn)優(yōu)秀，但在傳統(tǒng)金融類企業(yè)落地時非常困難，經(jīng)常需要對不同的需求做出妥協(xié)。

我們和多家客戶進行了深入溝通，雖然需求有所差異，但總結(jié)下來主要的訴求包括：

• 在主流的二層組網(wǎng)的數(shù)據(jù)中心中，受限于硬件能力或管理復(fù)雜度，大部分客戶不希望引入BGP等三層路由概念。

• 企業(yè)業(yè)務(wù)系統(tǒng)往往會在容器云平臺內(nèi)外同時同時部署，希望平臺內(nèi)外網(wǎng)絡(luò)能夠直接打通。

• IP地址是業(yè)務(wù)的身份識別，希望能夠具備固定IP的能力，而且是可管理、可審計的IP地址。

• 管理網(wǎng)絡(luò)和數(shù)據(jù)網(wǎng)絡(luò)分離。

• 具備網(wǎng)絡(luò)隔離能力，硬件隔離的強安全性和軟件隔離的靈活性都需要。

• 網(wǎng)絡(luò)模型應(yīng)該盡量簡單，易于掌控，易于調(diào)試。

• 高性能，低抖動的網(wǎng)絡(luò)吞吐能力。

• 其他的高級特性，如雙向限速、DPDK、overlay等。

我們對市面上主流的CNI插件進行了廣泛的調(diào)研后，發(fā)現(xiàn)主流的CNI對以上“國產(chǎn)化”的需求的支持并不理想，主要的不滿足點包括：

• 網(wǎng)絡(luò)模型差異（三層VS二層，當(dāng)然L2的方案也很多，OVS有流表等等高級功能，非常適合當(dāng)今云化的環(huán)境），要適配現(xiàn)網(wǎng)環(huán)境、安全策略等。

  
  

• 云原生理念。主流的CNI較好的滿足了云原生的概念，但客戶的實際需求中其實是有些“anti-cloudnative”的，如何在cloudnative和anti-cloudnative之間做到平衡其實普遍缺少實踐經(jīng)驗。

  
  

• 簡單穩(wěn)定可靠。這其實是非常重要的要考慮的點，廠商、企業(yè)都要有相應(yīng)的人員能夠掌控網(wǎng)絡(luò)模型，畢竟網(wǎng)絡(luò)作為云平臺的底層，出現(xiàn)問題后影響太大。

我們針對網(wǎng)絡(luò)建設(shè)的核心需求及社區(qū)現(xiàn)狀綜合分析之后，決定啟動beyondFabric項目，目前該項目已經(jīng)作為博云容器云平臺重點支持的兩個網(wǎng)絡(luò)模型（calico/beyondFabric）之一，支撐了多家企業(yè)的生產(chǎn)系統(tǒng)的穩(wěn)定運行。

02

BeyondFabric

BeyondFabric是我們自研的kubernetes CNI插件，利用etcd作為其數(shù)據(jù)存儲單元，內(nèi)置完善的IPAM能力，能夠很好的滿足前面提到的客戶的核心訴求。因為BeyondFabric是基于二層網(wǎng)絡(luò)設(shè)計的，同時針對特定需求做了很多優(yōu)化，所以其在一部分場景下（特別是國內(nèi)高度重視安全的金融類企業(yè)數(shù)據(jù)中心中）表現(xiàn)良好；但同時也決定了BeyondFabric不能適合于所有的場景，具體選擇哪種CNI還是要根據(jù)自身情況作出評估。（實際上沒有任何一種CNI能滿足所有的場景需求。）

fabric經(jīng)典模式示意圖

從fabric的概念圖中可以一目了然的看清楚云平臺的網(wǎng)絡(luò)拓撲，每個計算節(jié)點上安裝一個OVS，并且作為一個單純的虛擬交換機使用，容器通過veth pair連接到OVS的端口上從而自然的獲得物理環(huán)境下的網(wǎng)絡(luò)身份；在網(wǎng)絡(luò)的層面上，容器、虛擬機、物理機是完全對等的。不論是網(wǎng)絡(luò)管理人員還是業(yè)務(wù)人員都可以簡單清晰的了解到網(wǎng)絡(luò)的拓撲情況。而且在這種簡化的部署模型中（同時也是使用度最廣的模型）不包括控制器等復(fù)雜邏輯，提供了簡單、高效、穩(wěn)定的網(wǎng)絡(luò)環(huán)境。

fabric的組件圖

1. fabric是基于OVS的CNI插件，其具體職能為為POD組建網(wǎng)絡(luò)并設(shè)置IP地址。
   

2. fabric-ctl負責(zé)網(wǎng)絡(luò)及IP地址管理，通過RESTFUL API提供網(wǎng)絡(luò)/IP的管理能力，如創(chuàng)建網(wǎng)絡(luò)， 編輯網(wǎng)絡(luò)，查找IP等。fabric-ctl本身是無狀態(tài)的，所有狀態(tài)信息存儲到etcd中。

3. fabric-admin的主要使用人員為平臺管理員或BOC運維人員，方便使用人員查看和管理網(wǎng)絡(luò)及IPAM等。fabric-admin的命令行格式參考Kubectl。

在經(jīng)典組網(wǎng)模式下，將ovs作為一個基本的虛擬交換機使用即可，非常簡單。如果使用networkpolicy等隔離策略，需要在每個節(jié)點上引入一個分布式控制器。

網(wǎng)絡(luò)管理能力

fabric項目除了CNI協(xié)議規(guī)定的組建容器網(wǎng)絡(luò)的功能之外，還以restful API、annotation等方式額外提供了對網(wǎng)絡(luò)的管理能力。通過界面集成后可以方便管理人員使用，如下圖中的增加網(wǎng)絡(luò)，查看網(wǎng)絡(luò)，查看IP地址使用，固定IP等。

增加網(wǎng)絡(luò)

查看網(wǎng)絡(luò)

查看IP地址使用

固定IP地址

成熟度

接下來看一下fabric項目的成熟度，一個項目的成熟度是由很多方面決定的，除了fabric設(shè)計之初的簡單網(wǎng)絡(luò)模型，成熟的組件（無額外復(fù)雜組件，即使在做策略控制/overlay等場景下，也只是在每個節(jié)點上引入一個分布式控制器）之外，我們還做了以下幾個方面的工作。

fabric-admin

考慮到軟硬件層面的異常情況，例如kubelet或fabric的bug，環(huán)境（硬件損壞）等均可能對系統(tǒng)的正常運行造成不同程度的影響，所以提供了一個fabric-admin的工具，位于/opt/cni/bin目錄下，其作用類似于文件系統(tǒng)的FSCK能力，為運行時管理提供保障。同時其命令行格式完全匹配kubectl，對熟悉kubernetes的用戶非常友好。

例如可以查看pod的IP占用情況（示例輸出已被截斷） ：

同時，fabric-admin還提供了多種運行時管理能力支持，運行--help后可以提示：?

如同F(xiàn)SCK是文件系統(tǒng)成熟的重要標(biāo)志，fabric-admin是beyondFabric項目成熟的有力保障?。╢abric-admin雖然功能強大，但客戶現(xiàn)網(wǎng)環(huán)境中還從來沒有被使用過，也從側(cè)面說明了fabric項目的成熟度）

• kubernetes社區(qū)CNI測試套件

因為fabric項目完全滿足CNI協(xié)議規(guī)范，因此可以使用任意的CNI測試工具進行測試。我們的測試團隊結(jié)合社區(qū)提供的CNI測試工具及k8s job對象等對beyondFabric進行了長時間的嚴格測試，測試結(jié)果證明fabric項目具備生產(chǎn)可用能力。

• 多種平臺支持

私有云建設(shè)中，容器云平臺一般運行在物理環(huán)境或vmware/openstack等虛擬化環(huán)境中。fabric對于這幾種部署環(huán)境均能完善支持。對于網(wǎng)絡(luò)環(huán)境復(fù)雜不易變更的場景下，fabric基于overlay可以顯著減少環(huán)境依賴。

• 多個落地案例

博云容器云平臺基于fabric已經(jīng)有多個的落地案例，在可管理性、穩(wěn)定性、性能等多個方面運行良好。

BeyondFabric性能

接下來看一下fabric的性能表現(xiàn)。由于fabric采用了穩(wěn)定可靠的OVS作為其基本單元，所以從原理上講其性能損耗應(yīng)該是非常小的，我們在物理環(huán)境中基于萬兆網(wǎng)絡(luò)的性能測試也驗證了這一點。圖中可以看出pod-pod/pod-node的損耗較node-node約在5%左右。

博云容器云平臺網(wǎng)絡(luò)模型選型建議

然后我們來看一下選型建議。在客戶落地容器云平臺的過程中，我們會和客戶進行大量溝通，其中一個很重要的溝通就是涉及業(yè)務(wù)方、安全人員、網(wǎng)絡(luò)人員、運維人員的網(wǎng)絡(luò)模型溝通。具體的選型建議如下表所示，最終的選型結(jié)果由所有涉及人員共同決定。

fabric項目的小結(jié)

OK，簡單總結(jié)一下fabric項目。fabric項目解決了企業(yè)落地容器云平臺的一些主要的痛點，通過經(jīng)典網(wǎng)絡(luò)模式可以很好的滿足各個職能部門的訴求。但畢竟沒有任何一種網(wǎng)絡(luò)方案能滿足所有的網(wǎng)絡(luò)訴求，fabric也有其天生的缺點，例如經(jīng)典網(wǎng)絡(luò)模式下需要客戶真實的IP網(wǎng)絡(luò)，這些網(wǎng)絡(luò)資源在容器化的環(huán)境下消耗速度很快，需要根據(jù)業(yè)務(wù)需要提前創(chuàng)建好網(wǎng)絡(luò)資源，然而有些客戶的IPV4資源會比較緊張。當(dāng)然這一點隨著VXLAN的支持和IPV6的普及，將會得到很大的改善。fabric核心是二層的解決方案，二層就必然面臨擴展性的問題，我們目前的解決方案是通過分區(qū)的概念去映射真實的網(wǎng)絡(luò)分區(qū)，然后通過擴展分區(qū)的方式擴展Kubernetes集群。

Q：IPAM的固定IP是怎么實現(xiàn)的？IP與Pod UID關(guān)聯(lián)嗎？

A：管理員錄入網(wǎng)絡(luò)信息后，F(xiàn)abric會將所有IP地址存儲到etcd中統(tǒng)一管理。目前固定IP是通過給deployment等workload對象增加Annotation實現(xiàn)的。IP不與Pod UID關(guān)聯(lián)。

Q：這里面提到的三層網(wǎng)絡(luò)和二層網(wǎng)絡(luò)是指七層協(xié)議的三層二層嗎？

A：是的，比如交換機工作在2層，路由器工作在三層。

Q：服務(wù)負載均衡怎么實現(xiàn)的呢？

A：外部流量導(dǎo)入集群的負載均衡是通過另外一個組件，ingress controller實現(xiàn)的，沒有實現(xiàn)在CNI里面。Kubernetes svc的負載均衡是通過iptables實現(xiàn)的，F(xiàn)abric項目也會往iptables里面加入一些規(guī)則，主要是跨節(jié)點SNAT。

Q：支持流量限流么？

A：支持Ingress/Egress限速，通過給容器加Annotation即可以實現(xiàn)容器的限速。

Q：有和Contiv做過對比嗎？

A：選型階段做過，比較早了，那時候貌似Contiv還不太成熟，所以沒深入研究。

Q：這些網(wǎng)絡(luò)方案有什么好的學(xué)習(xí)方式嗎？

A：網(wǎng)絡(luò)雖然很復(fù)雜，但萬變不離其宗。容器網(wǎng)絡(luò)這個詞最近幾年比較流行，是因為網(wǎng)絡(luò)再容器環(huán)境下遇到了一些挑戰(zhàn)，但網(wǎng)絡(luò)本質(zhì)的概念還是過去非常成熟的那一套。所以首先得學(xué)習(xí)基本的網(wǎng)絡(luò)知識，然后去看下容器環(huán)境快速彈性等帶來的痛點。

Q：TC怎么實現(xiàn)的？

A：這個實現(xiàn)的比較久了，早在過去重點支持Calico的時候就已經(jīng)做了。有些細節(jié)模糊了，但基本是通過Linux tc實現(xiàn)的，因為本質(zhì)是veth pair，所以限速可以在主機側(cè)veth端實現(xiàn)?；镜南匏倜羁梢圆檎襱c機制就可以了，我們碰到限速不太準確，最后也通過調(diào)整參數(shù)解決了，誤差控制在百分之幾吧。

Q：與Kube-OVN做過對比嗎？

A：Kube-OVN是友商開源的產(chǎn)品，我了解過。首先Kube-OVN和Fabric項目都是基于OVS進行研發(fā)的，都支持Overylay/underlay模式，都可以實現(xiàn)CNI協(xié)議。但其實差別還是比較大。OVN項目源于OpenStack，OpenStack里的網(wǎng)絡(luò)模型是非常重的，概念、組件都比較多，OVN也在試圖統(tǒng)一Kubernetes/OpenStack的網(wǎng)絡(luò)模型，所以Kube-OVN里有一些能力其實已經(jīng)不在CNI spec的范圍內(nèi)了，比如負載均衡，DNS等，其實在社區(qū)都有對應(yīng)的實現(xiàn)。而Fabric會簡單很多，是一個標(biāo)準的CNI實現(xiàn)，網(wǎng)絡(luò)模型也非常清晰，能夠把容器直接融入現(xiàn)網(wǎng)環(huán)境，企業(yè)的網(wǎng)管一般都能掌控，對安全監(jiān)管等已有體系兼容性比較好。

網(wǎng)絡(luò)是非常復(fù)雜的，很難有一個統(tǒng)一的模型去兼顧所有的場景，個人認為這也是Kubernetes社區(qū)聰明的地方，把這些復(fù)雜的，不宜標(biāo)準的東西抽象出來，交給第三方去做。也正是由于CNI協(xié)議的簡單性和網(wǎng)絡(luò)的復(fù)雜性，現(xiàn)在市場上CNI可以說百家爭鳴，各有所長。個人認為這是一個非常好的現(xiàn)象。具體使用哪種CNI，還是要根據(jù)企業(yè)自身的情況作出決定。