2.0版本中引入了呼聲很高的overlay部署模式,采用了目前應(yīng)用最廣、生態(tài)建設(shè)最全面的VXLAN協(xié)議。Overlay模式相對(duì)Underlay模式雖然性能差一些,但其與物理網(wǎng)絡(luò)解耦、IP地址空間巨大等特點(diǎn)非常契合如今微服務(wù)彈性、靈活的特點(diǎn)。在overlay模式下,集群外部默認(rèn)將無法直接訪問pod的IP地址,此時(shí)建議通過Ingress將服務(wù)暴露出去;同時(shí),BeyondFabric將每個(gè)節(jié)點(diǎn)作為分布式egress網(wǎng)關(guān)以滿足pod訪問外部網(wǎng)絡(luò)的需求。

在安全性方面,BeyondFabric2.0支持了租戶隔離、NetworkPolicy、pod-security等特性。

? 租戶隔離

Kubernetes中沒有租戶的概念,但企業(yè)在落地過程中租戶又是一個(gè)非常重要的概念。社區(qū)里相應(yīng)的工作組在這方面的探討及驗(yàn)證工作也一直在進(jìn)行中。在已有的Kubernetes集群中,網(wǎng)絡(luò)隔離通常有幾種手段,例如通過networkpolicy實(shí)現(xiàn),但很多網(wǎng)絡(luò)插件的NetworkPolicy依賴效率較低的Iptables規(guī)則,同時(shí)當(dāng)NetworkPolicy數(shù)量增加后對(duì)日常運(yùn)維工作帶來了很大難度。有的L2的CNI插件可以通過結(jié)合物理網(wǎng)絡(luò)實(shí)現(xiàn)隔離,這種隔離方式雖然強(qiáng)度很高,但非常不靈活。在BeyondFabric 2.0中,我們引入了CNI規(guī)范中沒有提及的“租戶”概念,同時(shí)為了盡量減少和Kubernetes的耦合性,我們簡單的將一組namespaces視為一個(gè)租戶,同一個(gè)租戶的namespace都攜帶有同樣id的注解。一個(gè)namespace下的資源只能訪問帶有相同id的其他namespace下的資源,例如pod、service等。默認(rèn)情況下所有namespace都不帶有這條注解,因此所有的namespace下的業(yè)務(wù)實(shí)例默認(rèn)是沒有租戶隔離的。如果平臺(tái)管理員需要配置租戶隔離,僅需給相應(yīng)的namespace設(shè)置注解即可,非常簡單。

? 支持基于OVS ACL的NetworkPolicy

NetworkPolicy是Kubernetes內(nèi)置的“防火墻”規(guī)則,fabirc利用OVS的ACL實(shí)現(xiàn)了全部的NetworkPolicy spec。用戶可以按需的配置相應(yīng)的networkpolicy規(guī)則,為了簡化使用,BeyondFabric還針對(duì)networkpolicy提供了debug工具。

? 支持pod-security

BeyondFabric在轉(zhuǎn)發(fā)流量時(shí)會(huì)檢查報(bào)文的IP及MAC地址,如果發(fā)生IP地址偽裝等行為,則直接丟棄該報(bào)文。

核心架構(gòu)設(shè)計(jì)

Kubernetes正在進(jìn)入越來越多的數(shù)據(jù)中心,企業(yè)里也會(huì)有越來越多的業(yè)務(wù)往Kubernetes集群進(jìn)行遷移。網(wǎng)絡(luò)對(duì)于容器云平臺(tái)的穩(wěn)定性、擴(kuò)展性的影響非常大。對(duì)于一個(gè)CNI插件而言,好用易用、功能豐富是非常重要的,它很大程度上消除了容器云平臺(tái)的落地階段的痛點(diǎn)。但對(duì)一個(gè)需要長期運(yùn)行、按需擴(kuò)展、規(guī)模越來越大、承載業(yè)務(wù)越來越多的基礎(chǔ)平臺(tái)而言,它還需要具備簡單、穩(wěn)定可靠、高可擴(kuò)展性、高可用性的特點(diǎn)。

01場景豐富,同時(shí)支持underlay和overlay

BeyondFabric同時(shí)支持underlay和overlay網(wǎng)絡(luò),企業(yè)可以根據(jù)需求自主選擇。例如有的企業(yè)在容器云平臺(tái)選型時(shí)采用了overlay網(wǎng)絡(luò),而對(duì)業(yè)務(wù)系統(tǒng)的調(diào)用關(guān)系及部署拓?fù)涮岢隽撕芨叩囊?有的企業(yè)現(xiàn)網(wǎng)IP地址空間比較少,可以選擇overlay網(wǎng)絡(luò)。overlay和underlay有各自的應(yīng)用場景,不是互相替代的關(guān)系,相反很多企業(yè)在落地容器云平臺(tái)時(shí),可能同時(shí)需要兩種場景。

02全分布式,消除中央控制器,提升擴(kuò)展性和可用性

隨著越來越多的業(yè)務(wù)實(shí)現(xiàn)容器化,Kubernetes集群的規(guī)模會(huì)越來越大。BeyondFabric采用了全分布式設(shè)計(jì),無中心節(jié)點(diǎn),集群中的所有節(jié)點(diǎn)是對(duì)等的關(guān)系,任何一個(gè)節(jié)點(diǎn)或服務(wù)下線不會(huì)對(duì)其他節(jié)點(diǎn)產(chǎn)生影響。這種全分布式的架構(gòu)設(shè)計(jì)帶來了眾多好處,例如No SPOF、消除單點(diǎn)潛在的性能瓶頸、提升可擴(kuò)展性、可用性。

03 不預(yù)下發(fā),流表按需生成,提升查詢性能

對(duì)于單個(gè)節(jié)點(diǎn)上的fabric-node服務(wù)而言,流表的數(shù)量是限制集群擴(kuò)展性的關(guān)鍵因素。如果針對(duì)集群上運(yùn)行的每一個(gè)業(yè)務(wù)實(shí)例設(shè)置流表?xiàng)l目,那么對(duì)集群網(wǎng)絡(luò)的性能、擴(kuò)展性、可維護(hù)性都會(huì)造成很大影響。而對(duì)于業(yè)務(wù)系統(tǒng)而言,其實(shí)單個(gè)節(jié)點(diǎn)上的業(yè)務(wù)實(shí)例和其他節(jié)點(diǎn)的業(yè)務(wù)實(shí)例之間交互是非常有限的,因此超過80%的流表?xiàng)l目其實(shí)是不需要的。因此BeyondFabric采取了按需生成流表的設(shè)計(jì),即fabric-node啟動(dòng)時(shí)僅包含少量的默認(rèn)流表,隨著所在節(jié)點(diǎn)上啟動(dòng)的業(yè)務(wù)實(shí)例開始和其他實(shí)體建立網(wǎng)絡(luò)連接,表項(xiàng)隨之建立;隨著業(yè)務(wù)實(shí)例的消亡,表項(xiàng)隨之刪除。這種設(shè)計(jì)很好的提升了集群的擴(kuò)展性及單節(jié)點(diǎn)的流表查詢性能,對(duì)集群的網(wǎng)絡(luò)收斂也有很好的效果。與之對(duì)應(yīng)的,網(wǎng)絡(luò)連接的第一個(gè)報(bào)文在建立表項(xiàng)的過程中會(huì)有毫秒級(jí)別的延遲,后續(xù)報(bào)文會(huì)隨著表項(xiàng)的建立而快速轉(zhuǎn)發(fā)或丟棄。

04 用戶友好,靈活的trace工具

在使用CNI的過程中,人們往往會(huì)問:出現(xiàn)了問題,如何快速debug?確實(shí),網(wǎng)絡(luò)的重要性和復(fù)雜性都給運(yùn)維人員帶了了很大的壓力。網(wǎng)絡(luò)管理人員普遍對(duì)傳統(tǒng)網(wǎng)絡(luò)比較了解,企業(yè)里一般也有專業(yè)的網(wǎng)絡(luò)監(jiān)控分析平臺(tái)?？僧?dāng)傳統(tǒng)網(wǎng)絡(luò)疊加上Kubernetes容器網(wǎng)絡(luò)生態(tài)(CNI)、network namespace、networkpolicy等新概念時(shí),不管是網(wǎng)絡(luò)管理人員還是已有的網(wǎng)絡(luò)分析平臺(tái)都需要重新去適應(yīng)。這時(shí)候,一個(gè)靈活的trace工具就會(huì)非常重要。針對(duì)網(wǎng)絡(luò)流量異常的情況,可以給定源地址及目的地址,BeyondFabric工具自動(dòng)構(gòu)造報(bào)文并進(jìn)行發(fā)送到鏈路上進(jìn)行測試,在報(bào)文通路上的關(guān)鍵節(jié)點(diǎn)進(jìn)行數(shù)據(jù)采集,最終匯總出可能的故障點(diǎn)。針對(duì)Kubernetes內(nèi)置的“防火墻”NetworkPolicy,當(dāng)對(duì)象多了以后debug的困難度很高,因此BeyondFabric trace工具支持了對(duì)NetworkPolicy進(jìn)行了支持,對(duì)鏈路上可能的規(guī)則進(jìn)行逐一檢查以判斷是否允許通行。

選型建議

BeyondFabric overlay/underlay之間的選型建議其實(shí)也適用于其他CNI,主要從內(nèi)外通信機(jī)制、性能損耗、是否與物理網(wǎng)絡(luò)解耦、高級(jí)功能等方面進(jìn)行取舍。很多時(shí)候,其實(shí)企業(yè)里會(huì)建立多套集群,每套集群可能選擇不同的網(wǎng)絡(luò)解決方案。

即將到來的BeyondFabric 2.1版本

BeyondFabric 2.0版本在功能、擴(kuò)展性方面迎來了眾多的加強(qiáng),為構(gòu)建具備企業(yè)特性、真正生產(chǎn)大規(guī)?？捎玫腒ubernetes集群做好準(zhǔn)備。在即將到來的2.1版本中,我們將圍繞性能、穩(wěn)定性、可用性進(jìn)一步進(jìn)行優(yōu)化:

? 進(jìn)一步優(yōu)化控制面性能。

? 支持更多的封裝協(xié)議。

? 更好用、可視化的trace工具。

? 對(duì)網(wǎng)絡(luò)進(jìn)行全方面監(jiān)控,并對(duì)接主流的流量分析平臺(tái)。

songjy