爲何咱們要自主開發一個穩定可靠的容器網絡

做者：博雲產品架構師

2018年6月，京東智聯雲宣佈戰略投資中國雲計算PaaS市場的企業級解決方案提供商BoCloud博雲。京東智聯雲一直將博雲視爲重要的戰略合做夥伴，致力於共同爲客戶打造全方位解決方案，知足客戶對業務的多元需求。
今天這篇內容，也是來自於博雲BeyondFabric研發團隊。

在過去的幾年裏，隨着Kubernetes贏得了容器編排之爭，企業業務開始全面向Kubernetes切換，衆多新的企業軟件已經默認以Kubernetes形態交付。同時技術上圍繞Kubernetes的創新點也是層出不窮，其中以容器網絡舉例，如今Kubernetes官網登記在冊的CNI已經有近30種，能夠算的上百家爭鳴、各有所長了。

博雲從2014年就開始幫助企業落地容器雲平臺，其中的網絡模型則使用了設計優良又有着普遍應用的Calico。Calico簡單易用、適配性強、性能優秀、穩定可靠的特色對構建一個大規模的Kubernetes集羣很是有幫助，但隨着企業開始使用Kubernetes承載愈來愈多的業務，如何融入現網環境，如何加強安全審計等問題開始凸顯出來。時至今日，企業對容器網絡的要求愈來愈高，有些甚至已經超出了CNI的範疇。Calico開始出現了一些水土不服，例如，落地容器雲時常常提到如下問題：

• IP地址是業務的代名詞，能支持固定IP嗎？

• 外部服務能不經過負載均衡器直接調用容器雲裏提供的服務嗎？

• BGP? 設備比較老啦，開BGP怕影響性能，網絡部門阻力重重，該怎麼辦？

• 能支持限速嗎？多租戶環境下仍是很重要的。

• 支持多租戶嗎？不一樣的租戶要求不能互相訪問。

• 網絡性能如何？業務流量大了之後會不會致使集羣狀態不穩定？

• 企業內部現網已經有了大量監控和分析工具，容器網絡當前是個黑洞，出了問題怎麼辦？

• 有些場景須要overlay，有些場景須要underlay，能同時支持嗎？（ps: calico這個其實作的很好了，只是BGP落地時接受度不高）

相信這幾年落地容器雲時你們都會或多或少的碰到這些問題，而且相似的問題還有很多。針對以上問題，技術社區也出現過相似Macvlan之類的解決方案，將容器網絡直接與企業二層網絡打通，爲容器提供了很好的性能和連通性。Macvlan雖然能夠算是一個不錯的過分方案，但也有其技術缺陷，社區活躍度也不高。

到2018年初的時候，如何緩解企業在落地私有容器雲平臺時遇到的網絡阻力，已經發展成了一個很是重要又急迫的問題。對市面上主流的CNI插件進行了普遍的調研後，發現主流的CNI插件對以上需求的支持並不理想，難以同時知足如上的網絡需求，集中體如今內外網互通、管理業務網絡分離、靈活的網絡隔離機制、易於運維管理和調試等問題上，因而博雲容器雲（BeyondContainer）研發團隊決定基於openVswitch(OVS)自研一個Kubernetes CNI插件來解決這些痛點問題，並命名爲BeyondFabric。

選擇OVS的緣由是，在主流的二層網絡方案bridge、macvlan、OVS中，OVS的功能更加豐富，同時在主流的雲技術平臺中有着大量的應用，經受了足夠的考驗。2018年末，博雲發佈了BeyondFabric的1.0版本，此時正逢企業大量落地容器雲的初期。BeyondFabric 1.0具備簡單易用、支持underlay模式、支持固定IP地址、性能損耗低等特性，重點解決微服務上雲過程當中集羣內外互相直接通訊的問題，使得企業落地容器雲平臺的複雜度大大下降。_業務遷移到容器雲後幾乎感知不到基礎設施從虛擬化到容器化變動帶來的變化。_這種部署模式能夠很好的支持中間件和數據庫在Kubernetes集羣外部署，應用跑在Kubernetes集羣內，或者微服務系統註冊中心在虛擬機環境下部署但微服務跨集羣內外部署，等須要Kubernetes內外直接互通的場景。

一年多來，BeyondFabric 1.0版本在多個客戶的生產環境中穩定運行，完美的支持了物理環境以及vmware、openstack等虛擬化環境。隨着BeyondContainer 2.3版本的發佈，BeyondFabric迎來了2.0版本。在2.0版本里，網絡功能更加豐富、同時在可擴展性、可用性等方面有了很大加強。

BeyondFabric 2.0功能加強

在2.0版本中，咱們針對企業所需的不少重要特性進行了加強，例如支持overlay部署、租戶隔離、安全加強等，爲企業落地容器雲、更多業務實現數字化轉型助力。

2.0版本中引入了呼聲很高的overlay部署模式，採用了目前應用最廣、生態建設最全面的VXLAN協議。Overlay模式相對Underlay模式雖然性能差一些，但其與物理網絡解耦、IP地址空間巨大等特色很是契合現在微服務彈性、靈活的特色。在overlay模式下，集羣外部默認將沒法直接訪問pod的IP地址，此時建議經過Ingress將服務暴露出去；同時，BeyondFabric將每一個節點做爲分佈式egress網關以知足pod訪問外部網絡的需求。

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

租戶隔離

Kubernetes中沒有租戶的概念，但企業在落地過程當中租戶又是一個很是重要的概念。社區裏相應的工做組在這方面的探討及驗證工做也一直在進行中。在已有的Kubernetes集羣中，網絡隔離一般有幾種手段，例如經過networkpolicy實現，但不少網絡插件的NetworkPolicy依賴效率較低的Iptables規則，同時當NetworkPolicy數量增長後對平常運維工做帶來了很大難度。有的L2的CNI插件能夠經過結合物理網絡實現隔離，這種隔離方式雖然強度很高，但很是不靈活。在BeyondFabric 2.0中，咱們引入了CNI規範中沒有說起的「租戶」概念，同時爲了儘可能減小和Kubernetes的耦合性，咱們簡單的將一組namespaces視爲一個租戶，同一個租戶的namespace都攜帶有一樣id的註解。一個namespace下的資源只能訪問帶有相同id的其餘namespace下的資源，例如pod、service等。默認狀況下全部namespace都不帶有這條註解，所以全部的namespace下的業務實例默認是沒有租戶隔離的。若是平臺管理員須要配置租戶隔離，僅需給相應的namespace設置註解便可，很是簡單。

支持基於OVS ACL的NetworkPolicy

NetworkPolicy是Kubernetes內置的「防火牆」規則，fabirc利用OVS的ACL實現了所有的NetworkPolicy spec。用戶能夠按需的配置相應的networkpolicy規則，爲了簡化使用，BeyondFabric還針對networkpolicy提供了debug工具。

支持pod-security

BeyondFabric在轉發流量時會檢查報文的IP及MAC地址，若是發生IP地址假裝等行爲，則直接丟棄該報文。

核心架構設計

Kubernetes正在進入愈來愈多的數據中心，企業裏也會有愈來愈多的業務往Kubernetes集羣進行遷移。網絡對於容器雲平臺的穩定性、擴展性的影響很是大。對於一個CNI插件而言，好用易用、功能豐富是很是重要的，它很大程度上消除了容器雲平臺的落地階段的痛點。但對一個須要長期運行、按需擴展、規模愈來愈大、承載業務愈來愈多的基礎平臺而言，它還須要具有簡單、穩定可靠、高可擴展性、高可用性的特色。

01 場景豐富，同時支持underlay和overlay

BeyondFabric同時支持underlay和overlay網絡，企業能夠根據需求自主選擇。例若有的企業在容器雲平臺選型時採用了overlay網絡，而對業務系統的調用關係及部署拓撲提出了很高的要求；有的企業現網IP地址空間比較少，能夠選擇overlay網絡。overlay和underlay有各自的應用場景，不是互相替代的關係，相反不少企業在落地容器雲平臺時，可能同時須要兩種場景。

02 全分佈式，消除中央控制器，提高擴展性和可用性

隨着愈來愈多的業務實現容器化，Kubernetes集羣的規模會愈來愈大。BeyondFabric採用了全分佈式設計，無中心節點，集羣中的全部節點是對等的關係，任何一個節點或服務下線不會對其餘節點產生影響。這種全分佈式的架構設計帶來了衆多好處，例如No SPOF、消除單點潛在的性能瓶頸、提高可擴展性、可用性。

03 不預下發，流表按需生成，提高查詢性能

對於單個節點上的fabric-node服務而言，流表的數量是限制集羣擴展性的關鍵因素。若是針對集羣上運行的每個業務實例設置流表條目，那麼對集羣網絡的性能、擴展性、可維護性都會形成很大影響。而對於業務系統而言，其實單個節點上的業務實例和其餘節點的業務實例之間交互是很是有限的，所以超過80%的流表條目實際上是不須要的。所以BeyondFabric採起了按需生成流表的設計，即fabric-node啓動時僅包含少許的默認流表，隨着所在節點上啓動的業務實例開始和其餘實體創建網絡鏈接，表項隨之創建；隨着業務實例的消亡，表項隨之刪除。這種設計很好的提高了集羣的擴展性及單節點的流表查詢性能，對集羣的網絡收斂也有很好的效果。與之對應的，網絡鏈接的第一個報文在創建表項的過程當中會有毫秒級別的延遲，後續報文會隨着表項的創建而快速轉發或丟棄。

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

在使用CNI的過程當中，人們每每會問：出現了問題，如何快速debug？確實，網絡的重要性和複雜性都給運維人員帶了了很大的壓力。網絡管理人員廣泛對傳統網絡比較瞭解，企業裏通常也有專業的網絡監控分析平臺。可當傳統網絡疊加上Kubernetes容器網絡生態(CNI)、network namespace、networkpolicy等新概念時，不論是網絡管理人員仍是已有的網絡分析平臺都須要從新去適應。這時候，一個靈活的trace工具就會很是重要。針對網絡流量異常的狀況，能夠給定源地址及目的地址，BeyondFabric工具自動構造報文並進行發送到鏈路上進行測試，在報文通路上的關鍵節點進行數據採集，最終彙總出可能的故障點。針對Kubernetes內置的「防火牆」NetworkPolicy，當對象多了之後debug的困難度很高，所以BeyondFabric trace工具支持了對NetworkPolicy進行了支持，對鏈路上可能的規則進行逐一檢查以判斷是否容許通行。

選型建議

BeyondFabric overlay/underlay之間的選型建議其實也適用於其餘CNI，主要從內外通訊機制、性能損耗、是否與物理網絡解耦、高級功能等方面進行取捨。不少時候，其實企業裏會創建多套集羣，每套集羣可能選擇不一樣的網絡解決方案。

即將到來的BeyondFabric 2.1版本

BeyondFabric 2.0版本在功能、擴展性方面迎來了衆多的增強，爲構建具有企業特性、真正生產大規模可用的Kubernetes集羣作好準備。在即將到來的2.1版本中，咱們將圍繞性能、穩定性、可用性進一步進行優化：

• 進一步優化控制面性能。
• 支持更多的封裝協議。
• 更好用、可視化的trace工具。
• 對網絡進行全方面監控，並對接主流的流量分析平臺。

點擊「更多」瞭解博雲技術！