本文根據博雲在dockerone社區微信羣分享內容整理
過去幾年博雲在企業中落地容器雲平臺遇到了很多痛點，其中一個比較典型的痛點來自網絡方面，今天很高興跟大家聊聊這個話題並介紹下我們基於OVS自研的CNI插件——內部稱之爲fabric項目。
01
容器平臺落地時網絡方面的需求
從2013年左右Docker技術在開發者中流行起來，到如今kubernetes已經成爲事實上的容器編排引擎，容器、微服務、DevOps互相支持互相促進，容器雲平臺的實際落地案例開始越來越多。特別是2018年以來，越來越多的企業開始思考如何利用容器雲平臺支持其生產場景最終提高生產效率。
不同於開發測試場景，生產場景上線一套平臺或系統要求會嚴格很多。安全、監控、流程、現有系統集成、業務暴露等等的建設要求都要匹配上，否則不可能上線。在這個過程中，特別是在傳統的金融類企業對監管要求嚴格的情況下，容器雲平臺落地時會碰到很多問題，這其中，最典型的一個需求就是容器雲平臺的網絡建設，必須同時滿足業務方，運維人員，安全人員，網絡人員的訴求。
現在容器雲平臺大部分都是基於Kubernetes構建，市面上的CNI插件也非常多，各個企業現網的需求也有很大的不同，所以幾乎不可能出現一種網絡模型適配所有客戶場景的情況。現在主流的比較成熟穩定的CNI比如calico在擴展性、穩定性等方面表現優秀，但在傳統金融類企業落地時非常困難，經常需要對不同的需求做出妥協。
我們和多家客戶進行了深入溝通，雖然需求有所差異，但總結下來主要的訴求包括：
-
在主流的二層組網的數據中心中，受限於硬件能力或管理複雜度，大部分客戶不希望引入BGP等三層路由概念。
-
企業業務系統往往會在容器雲平臺內外同時同時部署，希望平臺內外網絡能夠直接打通。
-
IP地址是業務的身份識別，希望能夠具備固定IP的能力，而且是可管理、可審計的IP地址。
-
管理網絡和數據網絡分離。
-
具備網絡隔離能力，硬件隔離的強安全性和軟件隔離的靈活性都需要。
-
網絡模型應該儘量簡單，易於掌控，易於調試。
-
高性能，低抖動的網絡吞吐能力。
-
其他的高級特性，如雙向限速、DPDK、overlay等。
我們對市面上主流的CNI插件進行了廣泛的調研後，發現主流的CNI對以上“國產化”的需求的支持並不理想，主要的不滿足點包括：
-
網絡模型差異（三層VS二層，當然L2的方案也很多，OVS有流表等等高級功能，非常適合當今雲化的環境），要適配現網環境、安全策略等。
-
雲原生理念。主流的CNI較好的滿足了雲原生的概念，但客戶的實際需求中其實是有些“anti-cloudnative”的，如何在cloudnative和anti-cloudnative之間做到平衡其實普遍缺少實踐經驗。
-
簡單穩定可靠。這其實是非常重要的要考慮的點，廠商、企業都要有相應的人員能夠掌控網絡模型，畢竟網絡作爲雲平臺的底層，出現問題後影響太大。
我們針對網絡建設的核心需求及社區現狀綜合分析之後，決定啓動beyondFabric項目，目前該項目已經作爲博雲容器雲平臺重點支持的兩個網絡模型（calico/beyondFabric）之一，支撐了多家企業的生產系統的穩定運行。
02
BeyondFabric
BeyondFabric是我們自研的kubernetes CNI插件，利用etcd作爲其數據存儲單元，內置完善的IPAM能力，能夠很好的滿足前面提到的客戶的核心訴求。因爲BeyondFabric是基於二層網絡設計的，同時針對特定需求做了很多優化，所以其在一部分場景下（特別是國內高度重視安全的金融類企業數據中心中）表現良好；但同時也決定了BeyondFabric不能適合於所有的場景，具體選擇哪種CNI還是要根據自身情況作出評估。（實際上沒有任何一種CNI能滿足所有的場景需求。）
fabric經典模式示意圖
從fabric的概念圖中可以一目瞭然的看清楚雲平臺的網絡拓撲，每個計算節點上安裝一個OVS，並且作爲一個單純的虛擬交換機使用，容器通過veth pair連接到OVS的端口上從而自然的獲得物理環境下的網絡身份；在網絡的層面上，容器、虛擬機、物理機是完全對等的。不論是網絡管理人員還是業務人員都可以簡單清晰的瞭解到網絡的拓撲情況。而且在這種簡化的部署模型中（同時也是使用度最廣的模型）不包括控制器等複雜邏輯，提供了簡單、高效、穩定的網絡環境。
fabric的組件圖
-
fabric是基於OVS的CNI插件，其具體職能爲爲POD組建網絡並設置IP地址。
-
fabric-ctl負責網絡及IP地址管理，通過RESTFUL API提供網絡/IP的管理能力，如創建網絡， 編輯網絡，查找IP等。fabric-ctl本身是無狀態的，所有狀態信息存儲到etcd中。
-
fabric-admin的主要使用人員爲平臺管理員或BOC運維人員，方便使用人員查看和管理網絡及IPAM等。fabric-admin的命令行格式參考Kubectl。
在經典組網模式下，將ovs作爲一個基本的虛擬交換機使用即可，非常簡單。如果使用networkpolicy等隔離策略，需要在每個節點上引入一個分佈式控制器。
網絡管理能力
fabric項目除了CNI協議規定的組建容器網絡的功能之外，還以restful API、annotation等方式額外提供了對網絡的管理能力。通過界面集成後可以方便管理人員使用，如下圖中的增加網絡，查看網絡，查看IP地址使用，固定IP等。
增加網絡
查看網絡
查看IP地址使用
固定IP地址
成熟度
接下來看一下fabric項目的成熟度，一個項目的成熟度是由很多方面決定的，除了fabric設計之初的簡單網絡模型，成熟的組件（無額外複雜組件，即使在做策略控制/overlay等場景下，也只是在每個節點上引入一個分佈式控制器）之外，我們還做了以下幾個方面的工作。
fabric-admin
考慮到軟硬件層面的異常情況，例如kubelet或fabric的bug，環境（硬件損壞）等均可能對系統的正常運行造成不同程度的影響，所以提供了一個fabric-admin的工具，位於/opt/cni/bin目錄下，其作用類似於文件系統的FSCK能力，爲運行時管理提供保障。同時其命令行格式完全匹配kubectl，對熟悉kubernetes的用戶非常友好。
例如可以查看pod的IP佔用情況（示例輸出已被截斷） ：
同時，fabric-admin還提供了多種運行時管理能力支持，運行--help後可以提示：
如同FSCK是文件系統成熟的重要標誌，fabric-admin是beyondFabric項目成熟的有力保障！（fabric-admin雖然功能強大，但客戶現網環境中還從來沒有被使用過，也從側面說明了fabric項目的成熟度）
-
kubernetes社區CNI測試套件
因爲fabric項目完全滿足CNI協議規範，因此可以使用任意的CNI測試工具進行測試。我們的測試團隊結合社區提供的CNI測試工具及k8s job對象等對beyondFabric進行了長時間的嚴格測試，測試結果證明fabric項目具備生產可用能力。
-
多種平臺支持
私有云建設中，容器雲平臺一般運行在物理環境或vmware/openstack等虛擬化環境中。fabric對於這幾種部署環境均能完善支持。對於網絡環境複雜不易變更的場景下，fabric基於overlay可以顯著減少環境依賴。
-
多個落地案例
博雲容器雲平臺基於fabric已經有多個的落地案例，在可管理性、穩定性、性能等多個方面運行良好。
BeyondFabric性能
接下來看一下fabric的性能表現。由於fabric採用了穩定可靠的OVS作爲其基本單元，所以從原理上講其性能損耗應該是非常小的，我們在物理環境中基於萬兆網絡的性能測試也驗證了這一點。圖中可以看出pod-pod/pod-node的損耗較node-node約在5%左右。
博雲容器雲平臺網絡模型選型建議
然後我們來看一下選型建議。在客戶落地容器雲平臺的過程中，我們會和客戶進行大量溝通，其中一個很重要的溝通就是涉及業務方、安全人員、網絡人員、運維人員的網絡模型溝通。具體的選型建議如下表所示，最終的選型結果由所有涉及人員共同決定。
fabric項目的小結
OK，簡單總結一下fabric項目。fabric項目解決了企業落地容器雲平臺的一些主要的痛點，通過經典網絡模式可以很好的滿足各個職能部門的訴求。但畢竟沒有任何一種網絡方案能滿足所有的網絡訴求，fabric也有其天生的缺點，例如經典網絡模式下需要客戶真實的IP網絡，這些網絡資源在容器化的環境下消耗速度很快，需要根據業務需要提前創建好網絡資源，然而有些客戶的IPV4資源會比較緊張。當然這一點隨着VXLAN的支持和IPV6的普及，將會得到很大的改善。fabric核心是二層的解決方案，二層就必然面臨擴展性的問題，我們目前的解決方案是通過分區的概念去映射真實的網絡分區，然後通過擴展分區的方式擴展Kubernetes集羣。
Q：IPAM的固定IP是怎麼實現的？IP與Pod UID關聯嗎？
A：管理員錄入網絡信息後，Fabric會將所有IP地址存儲到etcd中統一管理。目前固定IP是通過給deployment等workload對象增加Annotation實現的。IP不與Pod UID關聯。
Q：這裏面提到的三層網絡和二層網絡是指七層協議的三層二層嗎？
A：是的，比如交換機工作在2層，路由器工作在三層。
Q：服務負載均衡怎麼實現的呢？
A：外部流量導入集羣的負載均衡是通過另外一個組件，ingress controller實現的，沒有實現在CNI裏面。Kubernetes svc的負載均衡是通過iptables實現的，Fabric項目也會往iptables裏面加入一些規則，主要是跨節點SNAT。
Q：支持流量限流麼？
A：支持Ingress/Egress限速，通過給容器加Annotation即可以實現容器的限速。
Q：有和Contiv做過對比嗎？
A：選型階段做過，比較早了，那時候貌似Contiv還不太成熟，所以沒深入研究。
Q：這些網絡方案有什麼好的學習方式嗎？
A：網絡雖然很複雜，但萬變不離其宗。容器網絡這個詞最近幾年比較流行，是因爲網絡再容器環境下遇到了一些挑戰，但網絡本質的概念還是過去非常成熟的那一套。所以首先得學習基本的網絡知識，然後去看下容器環境快速彈性等帶來的痛點。
Q：TC怎麼實現的？
A：這個實現的比較久了，早在過去重點支持Calico的時候就已經做了。有些細節模糊了，但基本是通過Linux tc實現的，因爲本質是veth pair，所以限速可以在主機側veth端實現。基本的限速命令可以查找tc機制就可以了，我們碰到限速不太準確，最後也通過調整參數解決了，誤差控制在百分之幾吧。
Q：與Kube-OVN做過對比嗎？
A：Kube-OVN是友商開源的產品，我瞭解過。首先Kube-OVN和Fabric項目都是基於OVS進行研發的，都支持Overylay/underlay模式，都可以實現CNI協議。但其實差別還是比較大。OVN項目源於OpenStack，OpenStack裏的網絡模型是非常重的，概念、組件都比較多，OVN也在試圖統一Kubernetes/OpenStack的網絡模型，所以Kube-OVN裏有一些能力其實已經不在CNI spec的範圍內了，比如負載均衡，DNS等，其實在社區都有對應的實現。而Fabric會簡單很多，是一個標準的CNI實現，網絡模型也非常清晰，能夠把容器直接融入現網環境，企業的網管一般都能掌控，對安全監管等已有體系兼容性比較好。
網絡是非常複雜的，很難有一個統一的模型去兼顧所有的場景，個人認爲這也是Kubernetes社區聰明的地方，把這些複雜的，不宜標準的東西抽象出來，交給第三方去做。也正是由於CNI協議的簡單性和網絡的複雜性，現在市場上CNI可以說百家爭鳴，各有所長。個人認爲這是一個非常好的現象。具體使用哪種CNI，還是要根據企業自身的情況作出決定。