Kubernetes經過了幾年的發展，存在著很多的網路方案。然而網路虛擬化在Kubernetes出現前就一直在發展，其中基於OpenVswitch的方案在OpenStack中已經有了很成熟的方案。其中OVN作為OVS的控制器提供了構建分散式虛擬網路的完整控制平面，並已經成為了最新的OpenStack網路標準。我們將OVN的網路架構和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。
網路的概念比較晦澀一些，但是好在大家都對Docker和Kubernetes比較熟悉，可以做個類比。如果說Docker是對單機計算資源的虛擬化，那麼OVS就是對單機網路進行虛擬化的一個工具。它最基本的功能是實現了虛擬交換機，可以把虛擬網絡卡和虛擬交換機的埠連線，這樣一個交換機下的多個網絡卡網路就打通了，類似Linux Bridge的功能。在此之上，OVS很重要的一點就是支援OpenFlow，這是一種可程式設計的流量控制語言，可以方便我們以程式設計的方式對流量進行控制，例如轉發，拒絕，更改包資訊，NAT，QoS 等等。此外OVS還支援多中網路流量監控的協議，方便我們視覺化監控並跟蹤整個虛擬網路的流量情況。
但是，OVS只是一個單機軟體，它並沒有叢集的資訊，自己無法瞭解整個叢集的虛擬網路狀況，也就無法只通過自己來構建叢集規模的虛擬網路。這就好比是單機的Docker，而OVN就相當於是OVS的Kubernetes，它提供了一個集中式的OVS控制器。這樣可以從叢集角度對整個網路設施進行編排。同時OVN也是新版OpenStack中Neutron的後端實現，基本可以認為未來的OpenStack網路都是透過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的請求。
瞭解了這些，大家應該就能發現，Kubernetes目前的網路從功能層面其實只是OVN支援的一個子集，基本上所有Kubernetes的網路需求都能在OVN中找到對映關係，我們簡單來看下他們之間的對映。
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網路功能和IaaS網路功能打平
現在的Kubernetes網路模型很類似之前公有雲上的經典網路，所有使用者大二層打通，透過安全策略控制訪問。我們現在也都知道公有雲多租戶不能這麼做VPC肯定是標配。因此未來Kubernetes網路可能也會向著多租戶方向前進，在VPC的基礎上有更多的路由控制、NAT控制、頻寬控制、浮動IP等等現在IaaS上很常見的功能。
現有的開源方案其實主要還是依賴原有的Linux網路棧，沒有針對性的最佳化。理論上容器的密度比傳統虛擬化高，網路壓力會更大。OVS現在有DPDK等Kernel bypass的DataPath，繞過Linux核心棧來實現低延遲和大吞吐網路。未來隨著容器的密度越來越大，我認為會出現這種針對容器架構專門最佳化的網路方案，而不是依舊依賴Linux網路棧。
現有的網路問題排查十分困難，如果所有的資料平面都由一個專案完成，比如OVN，那麼學習成本和排障都會容易一些。此外OVS社群已經有了很多成熟的監控，追蹤，排障方案，隨著容器的使用場景變多，我認為外圍的工具也需要能夠很好的支撐這種樣式的網路運維問題。
Q：OVS方案與基於三層交換機方案對比，各有什麼優缺點？
A：OVS最大的優點在於可程式設計，靈活性比較好。虛擬網路不用手動插網線，而且有OpenFlow加持，可以實現一些普通交換機無法實現的流量控制。物理交換機的主要有點就是效能好，而且比較穩定，不容易出問題。
Q：OVN不支援ECMP，貌似現在還是active-standby機制，你們怎麼解決Gateway瓶頸問題？
A：有幾種方式：1. Gateway用DPDK這樣的高速DataPath；2. 多Gateway，用策略路不同的IP段走不同Gateway，可以分擔流量；3. 不使用OVN概念的Gateway，自己做一些手腳從每臺宿主機直接出去，也是分擔流量降低單點的風險。
Q：如何debug OVN邏輯拓撲是否配置有問題？
A：目前debug確實很多情況只能靠眼看，也可以使用ovn-trace這個工具可以列印資料包在邏輯流裡的鏈路來排查。
A：Calico主要依賴Linux的路由功能做網路打通，OVS是在軟體交換機層面實現網路打通，並提供了更豐富的網路功能。
Q：OVS的封包支援有STT和Geneve，你們選用哪種，為什麼？
A：其實還支援VXLAN，我們選的Geneve。原因比較簡單，Geneve是第一個OVN支援的封包協議，而且看了一些評測，據說在搞核心開啟UDP Checksum的情況下效能會比VXLAN要好一些。
A：這個其實OVS有對應的設定可以給每個埠設定IP和MACE，這樣網絡卡啟動時配置相同的資訊就可以了，難點其實是如何控制OVN來分配 IP，感覺這個話題可以再開一場分享來討論了。
A：每個namespace和一個logical_switch系結，支援子網分配，支援固定 IP，支援 QoS，支援NetworkPolicy，內建的LB，內建的DNS，大致就是把OVN的概念對映到Kubernetes。
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網路。
Service Mesh入門與進階實戰培訓將於2019年4月12日在北京開課，3天時間帶你係統學習Service Mesh，學習效果不好可以繼續學習。本次培訓包括：Istio介紹、核心功能、使用場景、安裝與配置、升降級，Envoy介紹、架構、內部實現，Istio控制面板，Mixer核心功能與規則、監控、工作原理，Pilot介紹與配置，Istio安全，主要資源配置，策略配置，遙測，落地實踐，傳統微服務架構改造，Istio運維等，點選下麵圖片檢視具體詳情。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
