當咱們談論雲原生網絡時，究竟在談論什麼？（上）

你們好！今天很高興能有機會在這裏跟各位分享靈雀雲在雲原生網絡方面的實踐和咱們的思考。隨着容器、Kubernetes、微服務等理念、技術的普及，雲原生大幕開啓。與此相應地，不管是平臺的分佈式化，仍是業務的微服務化，都須要一個強大的網絡來支撐虛擬節點和微服務之間的通訊。

首先來看CNCF下面的這張圖，CNCF對於網絡架構的定義，能夠看到Runtime這一層又能夠分爲資源管理、雲原生網絡、雲原生存儲。

1什麼是雲原生網絡

雲原生網絡和傳統網絡的區別，能夠從容器網絡和物理網絡之間的對比來看。一個直觀的感覺就是，容器網絡的變化頻率很是高。對物理網絡來講，當機器上架，交換機路由器接好，全部物理機接到交換機以後，總體的網絡拓撲就不會變了，後面的增刪改查不會很頻繁。

對於容器網絡來講，在整個集羣node、pod、工做負載、節點的數量變化都很頻繁，每一個容器的生命週期很短暫，致使網絡的總體變化比傳統網絡高不少。同時，網絡策略的變化也很頻繁，對網絡自動化有很高的要求。想象一下，生成容器若是須要人工進行網絡配置，就沒法發揮出雲原生的價值。

此外，容器網絡對網絡自愈能力也有很高的要求，在如此變化頻繁的狀況下，單一硬件很難解決，會有不少軟件，包括軟件的可靠性、應用可靠性都會對網絡產生干擾。若是網絡節點的上線、下線，任何容器的啓停、節點的故障調整都須要人去參與、恢復，對總體網絡產生很大的影響，對網絡自愈能力要求特別高。

可是，容器網絡並不徹底等於雲原生網絡。咱們能夠想象雲原生最初的思路，它是爲了跨平臺的，雲原生的應用不該該依賴於底層的基礎設施；網絡最好是跨各類環境的，公有云、私有云、物理機，能夠隨時在不一樣的雲上進行遷移。若是你的網絡是跟底層的某些具體實現綁定的，好比某個公有云或私有云，在跨平臺方面的能力就會弱不少。在我來看，一個雲原生的網絡，是跟平臺無關的，能夠方便地跨雲進行遷移。

容器網絡的基本要求，首先每一個pod須要單獨IP，其次全部pod之間的網絡三層直接可達，不通過任何NAT設備。也就是說，從這個pod直接訪問另外一pod看到的目標IP應該是同一個IP。第三，網絡還須要提供一系列的網絡應用，好比Service、DNS、NetworkPolicy、Ingress等。這些網絡應用加上以前的容器網絡，以及跨平臺的特性，才構成了完整的雲原生網絡。

2雲原生網絡的開源實現

關於開源實現，CNCF很早就定義了一個標準——CNI（container network interface），它實際是一個可插拔式的容器網絡協議，Flannel、Clillium、Calico等都是基於CNI協議來作的。它規定了上層調度系統和底層容器網絡之間的一個交互協議，交互協議定義了兩個接口：ADD和DEL。

咱們從控制平面和數據平面兩個角度對網絡插件實現進行分類。控制平面是指網絡之間是如何相互發現的，容器網絡至關於在物理機器的網絡上面又加了一層網絡，那麼網絡之間是如何相互學習瞭解的？一個節點的容器是如何發現另外一節點的容器？其中的機制是怎樣的？

這種實現機制大體能夠分爲四類：一種是全部控制信息用分佈式kv進行存儲，典型如Flannel、Cillium，把全部的控制信息存到etcd，而後下發到每一個節點。靈雀雲開源的Kube-OVN是把全部的控制信息存到OVS DB，也是一個raft協議的分佈式存儲。

第二種是不經過物理層面的存儲，直接經過現有網絡層面的路由器或者交換機上的自我發現能力，好比Calico, Kube-Router經過路由協議，有一個協議的Agent，把路由信息發佈到外部路由器和交換機，外部硬件的信息就能夠經過路由協議把整個控制平臺的信息進行轉發。

第三種是用底層物理設備，物理機的控制平面就是交換機，至關於每一個機器把網絡接到交換機上以後，交換機就學到了如何進行控制平面的轉發。若是容器可以直接接入底層物理設備的話，能夠試試這種作法，比較典型的是Macvlan，IPvlan。

還有一種比較少見但挺有意思的實現方式，Gossip協議Weave，也叫八卦協議或者流行病協議。就是一我的告訴另外一我的，另一我的再去不斷告訴其餘人。

從數據平面角度來看，主要分爲兩種：一種封裝模式，好比Flannel Vxlan, Kube-OVN Geneve, CalicoIPIP, Cillium Vxlan，以及跟封裝模式相對的Underlay 模式: Flannel hostGateway, Kube-OVNVlan, Calico BGP 。

3雲原生網絡面臨的挑戰

雲原生網絡在實際落地時，也面臨着一些挑戰，主要分爲四個方面。

第一，功能層面來看，雲原生網絡功能方面的能力比較少，落地時會碰到不少客戶要作的新功能。

好比固定IP，當用戶提出要求，只能要麼網絡這邊改，要麼應用方面改。多租戶的能力，有的用戶有很大的集羣，有不少項目組，但願有租戶管理的功能。租戶不只指計算資源的隔離，也包括網絡資源的隔離。好比地址空間相對獨立，網絡控制獨立，一些銀行或其餘金融機構但願流量通過交換機時是加密的，還有一些客戶並不是全部業務都上了K8s，這些應用須要相互之間進行交互，集羣內外的網絡互通也是一個問題。

第二，監控和故障排查，這是比功能層面更讓人頭疼的問題，上了容器網絡後會發現大部分時間都是在運維這個網絡，檢查各類各樣的網絡問題。這其中最典型的可能就是網絡不通。並且，若是涉及開發環境，微服務也可能一塊上了，就會致使網絡結構和拓撲變得特別複雜。

還有一個網絡容易出現的問題--與已有技術棧的兼容。有些客戶還有傳統的網絡監控方式，傳統的網絡監控已經很成熟了，但在容器網絡這塊是空缺的，會致使總體監控是缺失的，總體的排查經驗也是缺失的，網絡一旦出現問題，就會是很難解決的問題。

第三，安全性。傳統方式可能採用基於黑白名單，或者基於IP劃分的網絡策略，可是容器在K8s上面，若是是用Networkpolicy，不少方式和傳統是不一致的，會帶來不少兼容性的問題。傳統的流量審計流量回放會收集通過集羣的全部流量，這種形式若是沒有好的底層基礎設施，不少安全機制至關於被架空了，這些都是落地時會碰到的問題。

第四，性能，提到性能大多數人會關注數據平面的性能。但在咱們來看，現階段比較大的問題是，用戶的網絡究竟能撐多大規模的集羣，何時控制平面的性能會出現明顯的衰減，這是在選型時需着重考慮的。數據平面的性能到實際應用時，不少狀況下沒有那麼突出。它須要根據應用所須要的性能進行評估，不少狀況下最大的極端的性能反而不是最須要的性能。