歡迎光臨
每天分享高質量文章

基於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:如何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:請問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網絡。

Service Mesh入門與進階實戰培訓

Service Mesh入門與進階實戰培訓將於2019年4月12日在北京開課,3天時間帶你系統學習Service Mesh,學習效果不好可以繼續學習。本次培訓包括:Istio介紹、核心功能、使用場景、安裝與配置、升降級,Envoy介紹、架構、內部實現,Istio控制面板,Mixer核心功能與規則、監控、工作原理,Pilot介紹與配置,Istio安全,主要資源配置,策略配置,遙測,落地實踐,傳統微服務架構改造,Istio運維等,點擊下麵圖片查看具體詳情。