基於OVN的Kubernetes網絡架構解析

【編者的話】Kubernetes通過了幾年的發展，存在着不少的網絡方案。然而網絡虛擬化在Kubernetes出現前就一直在發展，其中基於OpenVswitch的方案在OpenStack中已經有了很成熟的方案。其中OVN做爲OVS的控制器提供了構建分佈式虛擬網絡的完整控制平面，並已經成爲了最新的OpenStack網絡標準。咱們將OVN的網絡架構和Kubernetes的容器平臺進行結合，將業界成熟的網絡架構引入Kubernetes大幅加強現有容器網絡的能力。

Kubernetes網絡的侷限性

Kubernetes提出了不少網絡概念，不少開源項目都有本身的實現。然而因爲各個網絡功能都是在不一樣的項目中實現，功能和性能也各有千秋，缺少統一的解決方案，在使用過程當中常常會陷入到底該用哪一個的抉擇中。同時CNI、DNS、Service的實現又在不一樣的項目，一旦網絡出現問題，排查也會在多個組件間遊走，是一個十分痛苦的過程。

儘管Kubernetes提出了不少網絡的概念，可是在真實應用中不少人會有這樣的感受：網絡這塊仍是很薄弱，不少功能缺少，方案也不夠靈活。尤爲是和搞傳統基礎設施網絡的人溝通會發現，在他們眼裏，Kubernetes的網絡還很初級。咱們熟悉的Kubernetes網絡是CNI、Service、DNS、Ingress、Network Policy這樣的模式。而作IaaS的視角徹底不一樣，他們每次提起是VPC、Subnet、VNIC、 Floating IP，在此之上有DHCP，路由控制，安全組，QoS，負載均衡，域名解析這樣的基礎網絡功能。

從IaaS的視角來看，Kubernetes的網絡功能確實比較單薄。常常碰到來自傳統網絡部門的挑戰，諸如子網劃分VLAN隔離，集羣內外網絡打通，容器NAT設置，帶寬動態調節等等。現有的開源網絡方案很難完美支持，最簡單的一個例子，好比說起容器的固定IP功能一般就要上升到意識形態鬥爭的層面去討論。這本質上仍是Kubernetes的網絡功能不足，模型也不夠靈活致使的。從更高層面來講，Kubernetes中抽象類一層網絡虛擬化的內容，然而網絡虛擬化或者SDN並非Kubernetes帶來的新東西，相關技術已經發展好久。尤爲是在IaaS領域裏已經有着比較成熟且完善的一整套網絡方案。

傳統網絡部門的人都會問，爲何不用OVS來作網絡方案，不少需求用只要容器網絡接入OVS網絡，剩下事情網絡部門本身就知道怎麼去作了，都不用咱們實現太多額外的功能。也有不少人向咱們推薦了OVN，用這個能很方便地實現這些功能。也正由此咱們開始去關注OVS/OVN這種以前主要應用於OpenStack生態系統的網絡工具。下面我就來介紹一下OVS和OVN。 OVS和OVN網絡方案的能力 網絡的概念比較晦澀一些，可是好在你們都對Docker和Kubernetes比較熟悉，能夠作個類比。若是說Docker是對單機計算資源的虛擬化，那麼OVS就是對單機網絡進行虛擬化的一個工具。它最基本的功能是實現了虛擬交換機，能夠把虛擬網卡和虛擬交換機的端口鏈接，這樣一個交換機下的多個網卡網絡就打通了，相似Linux Bridge的功能。在此之上，OVS很重要的一點就是支持OpenFlow，這是一種可編程的流量控制語言，能夠方便咱們以編程的方式對流量進行控制，例如轉發，拒絕，更改包信息，NAT，QoS 等等。此外OVS還支持多中網絡流量監控的協議，方便咱們可視化監控並跟蹤整個虛擬網絡的流量狀況。

可是，OVS只是一個單機軟件，它並無集羣的信息，本身沒法瞭解整個集羣的虛擬網絡情況，也就沒法只經過本身來構建集羣規模的虛擬網絡。這就比如是單機的Docker，而OVN就至關因而OVS的Kubernetes，它提供了一個集中式的OVS控制器。這樣能夠從集羣角度對整個網絡設施進行編排。同時OVN也是新版OpenStack中Neutron的後端實現，基本能夠認爲將來的OpenStack網絡都是經過OVN來進行控制的。

上圖是一個OVN的架構，從下往上看：

ovs-vswitchd和ovsdb-server能夠理解爲單機的Docker負責單機虛擬網絡的真實操做。

ovn-controller相似於kubelet，負責和中心控制節點通訊獲取整個集羣的網絡信息，並更新本機的流量規則。

Southbound DB相似於etcd（不太準確），存儲集羣視角下的邏輯規則。

Northbound DB相似apiserver，提供了一組高層次的網絡抽象，這樣在真正建立網絡資源時無需關心負責的邏輯規則，只須要經過Northoboud DB的接口建立對應實體便可。

CMS能夠理解爲OpenStacke或者Kubernetes這樣的雲平臺，而 CMS Plugin是雲平臺和OVN對接的部分。

下面咱們具體介紹一下OVN提供的網絡抽象，這樣你們就會有比較清晰的認知了。

Logical_Switch最基礎的分佈式虛擬交換機，這樣能夠將多臺機器上的容器組織在一個二層網絡下，看上去就好像全部容器接在一臺交換機上。以後能夠在上面增長諸如ACL、LB、QoS、DNS、VLAN等等二層功能。

Logical_Router虛擬路由器，提供了交換機之間的路由，虛擬網絡和外部網絡鏈接，以後能夠在路由器層面增長DHCP、NAT、Gateway等路由相關的功能。

Loadbalancer，L2和L3的Loadbalancer，能夠類比公有云上的內部LB和外部LB的功能。

ACL基於L2到L4的全部控制信息進行管控的一組DSL，能夠十分靈活，例如：outport == 「port1」 && ip4 && tcp && tcp.src >= 10000 && tcp.dst <= 1000。

QoS，能夠基於和ACL一樣的DSL進行帶寬的控制。

NAT，同時提供DNAT和SNAT的控制方便內外網絡通訊。

DNS，內置的分佈式DNS，能夠在本機直接返回內部DNS的請求。

Gateway控制內部和外部之間的集中式通訊。

瞭解了這些，你們應該就能發現，Kubernetes目前的網絡從功能層面其實只是OVN支持的一個子集，基本上全部Kubernetes的網絡需求都能在OVN中找到映射關係，咱們簡單來看下他們之間的映射。 OVN和Kubernetes的結合 Switch/Router -> Kubernetes基本的東西向互通容器網絡。這塊OVN的能力實際上是大大超出，畢竟OVN的這套模型是針對多租戶進行設計的，而Kubernetes如今只須要一個簡單的二層網絡。

Loadbalancer → ClusterIP以及Loadbalancer類型的Service，能夠取代kube-proxy的功能，OVN自己也能夠實現雲上ELB的功能。

ACL -> Networkpolicy本質上更靈活由於能夠從L2控制到L4而且DSL也支持更多的語法規則。

DNS -> 能夠取代Kube-DNS/CoreDNS，同時因爲OVN實現的是分佈式DNS，總體的健壯性會比如今的Kubernetes方案要好。

能夠看到Kubernetes的CNI、kube-proxy、Kube-DNS、NetworkPolicy、Service等等概念OVN都有對應的方案，並且在功能或者穩定性上還有加強。更不要說還有QoS、NAT、Gateway等等如今Kubernetes中沒有的概念。能夠看到若是能把IaaS領域的網絡能力往Kubernetes平移，咱們還有不少的提高空間。

Kubernetes網絡將來加強的方向

最後來講說我認爲的將來Kubernetes網絡可能的加強方向。 Kubernetes網絡功能和IaaS網絡功能打平 如今的Kubernetes網絡模型很相似以前公有云上的經典網絡，全部用戶大二層打通，經過安全策略控制訪問。咱們如今也都知道公有云多租戶不能這麼作VPC確定是標配。所以將來Kubernetes網絡可能也會向着多租戶方向前進，在VPC的基礎上有更多的路由控制、NAT控制、帶寬控制、浮動IP等等如今IaaS上很常見的功能。 性能 現有的開源方案其實主要仍是依賴原有的Linux網絡棧，沒有針對性的優化。理論上容器的密度比傳統虛擬化高，網絡壓力會更大。OVS如今有DPDK等Kernel bypass的DataPath，繞過Linux內核棧來實現低延遲和大吞吐網絡。將來隨着容器的密度愈來愈大，我認爲會出現這種針對容器架構專門優化的網絡方案，而不是依舊依賴Linux網絡棧。

監控和問題排查

現有的網絡問題排查十分困難，若是全部的數據平面都由一個項目完成，好比OVN，那麼學習成本和排障都會容易一些。此外OVS社區已經有了不少成熟的監控，追蹤，排障方案，隨着容器的使用場景變多，我認爲外圍的工具也須要可以很好的支撐這種模式的網絡運維問題。 Q&A Q：OVS方案與基於三層交換機方案對比，各有什麼優缺點？ A：OVS最大的優勢在於可編程，靈活性比較好。虛擬網絡不用手動插網線，並且有OpenFlow加持，能夠實現一些普通交換機沒法實現的流量控制。物理交換機的主要有點就是性能好，並且比較穩定，不容易出問題。 Q：OVN不支持ECMP，貌似如今仍是active-standby機制，大家怎麼解決Gateway瓶頸問題？ A：有幾種方式：1. Gateway用DPDK這樣的高速DataPath；2. 多Gateway，用策略路不一樣的IP段走不一樣Gateway，能夠分擔流量；3. 不使用OVN概念的Gateway，本身作一些手腳從每臺宿主機直接出去，也是分擔流量下降單點的風險。 Q：OVN-Kubernetes好像只支持每一個部署節點一個虛擬網絡網段。如何避免IP池浪費和不均衡？ A：這個實際上是這個項目實現的網絡模型的一個侷限性。在咱們的實現裏是以namespace爲粒度劃分子網，能夠對每一個namespace進行控制，狀況會好不少。 Q：OVN若是有不一樣的Chassis，可是相同IP就會形成網絡異常（好比物理機，VM裝上OVN，註冊到遠端後，被重建，後面又註冊到遠端，可是Chassis已經改變），會致使大量節點Geneve網絡異常。大家怎麼解決這個問題？ A：暫時沒碰到這個問題，可是咱們在實現的一個原則就是儘量保證全部的操做都是冪等的。向這種可能須要在重連前作一個檢查，判斷是否有過時的數據須要清理，再鏈接，或者複用舊的鏈接信息去鏈接。 Q：如何debug OVN邏輯拓撲是否配置有問題？ A：目前debug確實不少狀況只能靠眼看，也可使用ovn-trace這個工具能夠打印數據包在邏輯流裏的鏈路來排查。 Q：OVS跟Calico等有啥區別？ A：Calico主要依賴Linux的路由功能作網絡打通，OVS是在軟件交換機層面實現網絡打通，並提供了更豐富的網絡功能。 Q：OVS的封包支持有STT和Geneve，大家選用哪一種，爲何？ A：其實還支持VXLAN，咱們選的Geneve。緣由比較簡單，Geneve是第一個OVN支持的封包協議，並且看了一些評測，聽說在搞內核開啓UDP Checksum的狀況下性能會比VXLAN要好一些。 Q：OVS如何實現固定容器IP？ A：這個其實OVS有對應的設置能夠給每一個端口設定IP和MACE，這樣網卡啓動時配置相同的信息就能夠了，難點實際上是如何控制OVN來分配 IP，感受這個話題能夠再開一場分享來討論了。 Q：能夠簡單介紹下大家準備開源的網絡功能嗎？ A：每一個namespace和一個logical_switch綁定，支持子網分配，支持固定 IP，支持 QoS，支持NetworkPolicy，內置的LB，內置的DNS，大體就是把OVN的概念映射到Kubernetes。 Q：想了解一下，若是採用OVN，是否是意味着使用OpenStack平臺和Kubernetes網絡能夠直接互通？完成業務在虛擬機和Pod之間的全新負載方式？ A：是這樣的，若是涉及的合理能夠作到容器和VM使用同一個底層網絡基礎設施，VM和容器之間能夠IP直達，全部的ACL、LB都是打通的。 Q：直接把OpenShift OVS抽出來作Kubernetes的網絡插件和靈雀雲作的這個區別在哪？ A：功能上有不少是相同的，由於底層都是OVS。若是關注Roadmap會發現OpenShift以後也會採用OVS的模式。從架構的角度來看，如今openshift-multitenant的實現很相似Neutron以前那一套，各類Agent，以後會統一到OVN。另外一方面OpenShift的網絡插件綁定的太死了，因此咱們決定仍是本身抽出來，順便能實現咱們的一些特殊功能，好比固定IP，子網共享，以及一些網關控制層面的功能。 Q：請問Geneve和VXLAN的區別有哪些？ A：Geneve能夠理解爲下一代VXLAN，VXLAN相對VLAN來講頭部更長能夠支持更多的VLAN，可是因爲是固定長度的封裝頭，不能任意加控制信息。Geneve採用變長的封裝頭，能夠加不少自定義的控制信息，方便以後作更復雜的網絡管控。 Q：Docker CNM也支持固定IP，和你說的固定IP是一回事嗎？另外，基於OVS創建的網絡是CNI仍是CNM的呢？ A：基於CNI，由於咱們依賴Kubernetes的模型。不過話說回來我很喜歡Docker CNM那套模型，比CNI要實用不少。固定IP其實只是個功能，各類模型下均可以實現，效果就是能夠給Pod指定IP啓動，Workload下的多個Pod實用的是一組固定的地址。 Q：目前大家對企業的解決方案裏會默認採用這種網絡模式麼？ A：這個方案是咱們這幾年需求和碰到坑的一個積累吧，如今還不會直接給企業用，咱們還須要一些功能的開發和測試，可是以後Overlay的場景這個確定是主推了，主要是取代原來的Flannel VXLAN網絡。 Q：你瞭解Contiv網絡方案嗎，和貴公司的實現有哪些區別？ A：Contiv是思科作的，也是OVS實現的，不過它的實現比較早，本身手動實現了整個控制平面，能夠認爲本身寫了個跟OVN相似的東西來控制 OVS。不過看它最近已經不多更新了。用OVN能用不多的代碼就實現基本相同的功能。Contiv有個比較獨特的功能就是支持BGP的網絡間通訊，這個是OVN暫時不支持的。 以上內容根據2019年3月26日晚微信羣分享內容整理。分享人劉夢馨，靈雀雲高級工程師。2014年加入靈雀雲容器團隊，長期參與容器調度平臺和容器網絡架構的產品研發和技術架構演進，參與自研容器網絡和容器應用網關。目前主要專一於容器網絡功能的拓展和架構優化。DockOne每週都會組織定向的技術分享，歡迎感興趣的同窗加微信：liyingjiesd，進羣參與，您有想聽的話題或者想分享的話題均可以給咱們留言。