摘要：它最基本的功能是實(shí)現(xiàn)了虛擬交換機(jī)，可以把虛擬網(wǎng)卡和虛擬交換機(jī)的端口連接，這樣一個(gè)交換機(jī)下的多個(gè)網(wǎng)卡網(wǎng)絡(luò)就打通了，類似的功能。最基礎(chǔ)的分布式虛擬交換機(jī)，這樣可以將多臺(tái)機(jī)器上的容器組織在一個(gè)二層網(wǎng)絡(luò)下，看上去就好像所有容器接在一臺(tái)交換機(jī)上。

【編者的話】Kubernetes經(jīng)過了幾年的發(fā)展，存在著很多的網(wǎng)絡(luò)方案。然而網(wǎng)絡(luò)虛擬化在Kubernetes出現(xiàn)前就一直在發(fā)展，其中基于OpenVswitch的方案在OpenStack中已經(jīng)有了很成熟的方案。其中OVN作為OVS的控制器提供了構(gòu)建分布式虛擬網(wǎng)絡(luò)的完整控制平面，并已經(jīng)成為了最新的OpenStack網(wǎng)絡(luò)標(biāo)準(zhǔn)。我們將OVN的網(wǎng)絡(luò)架構(gòu)和Kubernetes的容器平臺(tái)進(jìn)行結(jié)合，將業(yè)界成熟的網(wǎng)絡(luò)架構(gòu)引入Kubernetes大幅增強(qiáng)現(xiàn)有容器網(wǎng)絡(luò)的能力。
Kubernetes網(wǎng)絡(luò)的局限性
Kubernetes提出了很多網(wǎng)絡(luò)概念，很多開源項(xiàng)目都有自己的實(shí)現(xiàn)。然而由于各個(gè)網(wǎng)絡(luò)功能都是在不同的項(xiàng)目中實(shí)現(xiàn)，功能和性能也各有千秋，缺乏統(tǒng)一的解決方案，在使用過程中經(jīng)常會(huì)陷入到底該用哪個(gè)的抉擇中。同時(shí)CNI、DNS、Service的實(shí)現(xiàn)又在不同的項(xiàng)目，一旦網(wǎng)絡(luò)出現(xiàn)問題，排查也會(huì)在多個(gè)組件間游走，是一個(gè)十分痛苦的過程。

盡管Kubernetes提出了很多網(wǎng)絡(luò)的概念，但是在真實(shí)應(yīng)用中很多人會(huì)有這樣的感覺：網(wǎng)絡(luò)這塊還是很薄弱，很多功能缺乏，方案也不夠靈活。尤其是和搞傳統(tǒng)基礎(chǔ)設(shè)施網(wǎng)絡(luò)的人溝通會(huì)發(fā)現(xiàn)，在他們眼里，Kubernetes的網(wǎng)絡(luò)還很初級(jí)。我們熟悉的Kubernetes網(wǎng)絡(luò)是CNI、Service、DNS、Ingress、Network Policy這樣的模式。而做IaaS的視角完全不同，他們每次提起是VPC、Subnet、VNIC、 Floating IP，在此之上有DHCP，路由控制，安全組，QoS，負(fù)載均衡，域名解析這樣的基礎(chǔ)網(wǎng)絡(luò)功能。

從IaaS的視角來看，Kubernetes的網(wǎng)絡(luò)功能確實(shí)比較單薄。經(jīng)常碰到來自傳統(tǒng)網(wǎng)絡(luò)部門的挑戰(zhàn)，諸如子網(wǎng)劃分VLAN隔離，集群內(nèi)外網(wǎng)絡(luò)打通，容器NAT設(shè)置，帶寬動(dòng)態(tài)調(diào)節(jié)等等?，F(xiàn)有的開源網(wǎng)絡(luò)方案很難完美支持，最簡(jiǎn)單的一個(gè)例子，比如提及容器的固定IP功能通常就要上升到意識(shí)形態(tài)斗爭(zhēng)的層面去討論。這本質(zhì)上還是Kubernetes的網(wǎng)絡(luò)功能不足，模型也不夠靈活導(dǎo)致的。從更高層面來說，Kubernetes中抽象類一層網(wǎng)絡(luò)虛擬化的內(nèi)容，然而網(wǎng)絡(luò)虛擬化或者SDN并不是Kubernetes帶來的新東西，相關(guān)技術(shù)已經(jīng)發(fā)展很久。尤其是在IaaS領(lǐng)域里已經(jīng)有著比較成熟且完善的一整套網(wǎng)絡(luò)方案。

傳統(tǒng)網(wǎng)絡(luò)部門的人都會(huì)問，為什么不用OVS來做網(wǎng)絡(luò)方案，很多需求用只要容器網(wǎng)絡(luò)接入OVS網(wǎng)絡(luò)，剩下事情網(wǎng)絡(luò)部門自己就知道怎么去做了，都不用我們實(shí)現(xiàn)太多額外的功能。也有很多人向我們推薦了OVN，用這個(gè)能很方便地實(shí)現(xiàn)這些功能。也正由此我們開始去關(guān)注OVS/OVN這種之前主要應(yīng)用于OpenStack生態(tài)系統(tǒng)的網(wǎng)絡(luò)工具。下面我就來介紹一下OVS和OVN。
OVS和OVN網(wǎng)絡(luò)方案的能力
網(wǎng)絡(luò)的概念比較晦澀一些，但是好在大家都對(duì)Docker和Kubernetes比較熟悉，可以做個(gè)類比。如果說Docker是對(duì)單機(jī)計(jì)算資源的虛擬化，那么OVS就是對(duì)單機(jī)網(wǎng)絡(luò)進(jìn)行虛擬化的一個(gè)工具。它最基本的功能是實(shí)現(xiàn)了虛擬交換機(jī)，可以把虛擬網(wǎng)卡和虛擬交換機(jī)的端口連接，這樣一個(gè)交換機(jī)下的多個(gè)網(wǎng)卡網(wǎng)絡(luò)就打通了，類似Linux Bridge的功能。在此之上，OVS很重要的一點(diǎn)就是支持OpenFlow，這是一種可編程的流量控制語言，可以方便我們以編程的方式對(duì)流量進(jìn)行控制，例如轉(zhuǎn)發(fā)，拒絕，更改包信息，NAT，QoS 等等。此外OVS還支持多中網(wǎng)絡(luò)流量監(jiān)控的協(xié)議，方便我們可視化監(jiān)控并跟蹤整個(gè)虛擬網(wǎng)絡(luò)的流量情況。

但是，OVS只是一個(gè)單機(jī)軟件，它并沒有集群的信息，自己無法了解整個(gè)集群的虛擬網(wǎng)絡(luò)狀況，也就無法只通過自己來構(gòu)建集群規(guī)模的虛擬網(wǎng)絡(luò)。這就好比是單機(jī)的Docker，而OVN就相當(dāng)于是OVS的Kubernetes，它提供了一個(gè)集中式的OVS控制器。這樣可以從集群角度對(duì)整個(gè)網(wǎng)絡(luò)設(shè)施進(jìn)行編排。同時(shí)OVN也是新版OpenStack中Neutron的后端實(shí)現(xiàn)，基本可以認(rèn)為未來的OpenStack網(wǎng)絡(luò)都是通過OVN來進(jìn)行控制的。
01.jpeg

上圖是一個(gè)OVN的架構(gòu)，從下往上看：

ovs-vswitchd和ovsdb-server可以理解為單機(jī)的Docker負(fù)責(zé)單機(jī)虛擬網(wǎng)絡(luò)的真實(shí)操作。

ovn-controller類似于kubelet，負(fù)責(zé)和中心控制節(jié)點(diǎn)通信獲取整個(gè)集群的網(wǎng)絡(luò)信息，并更新本機(jī)的流量規(guī)則。

Southbound DB類似于etcd（不太準(zhǔn)確），存儲(chǔ)集群視角下的邏輯規(guī)則。

Northbound DB類似apiserver，提供了一組高層次的網(wǎng)絡(luò)抽象，這樣在真正創(chuàng)建網(wǎng)絡(luò)資源時(shí)無需關(guān)心負(fù)責(zé)的邏輯規(guī)則，只需要通過Northoboud DB的接口創(chuàng)建對(duì)應(yīng)實(shí)體即可。

CMS可以理解為OpenStacke或者Kubernetes這樣的云平臺(tái)，而 CMS Plugin是云平臺(tái)和OVN對(duì)接的部分。

下面我們具體介紹一下OVN提供的網(wǎng)絡(luò)抽象，這樣大家就會(huì)有比較清晰的認(rèn)知了。

Logical_Switch最基礎(chǔ)的分布式虛擬交換機(jī)，這樣可以將多臺(tái)機(jī)器上的容器組織在一個(gè)二層網(wǎng)絡(luò)下，看上去就好像所有容器接在一臺(tái)交換機(jī)上。之后可以在上面增加諸如ACL、LB、QoS、DNS、VLAN等等二層功能。

Logical_Router虛擬路由器，提供了交換機(jī)之間的路由，虛擬網(wǎng)絡(luò)和外部網(wǎng)絡(luò)連接，之后可以在路由器層面增加DHCP、NAT、Gateway等路由相關(guān)的功能。

Loadbalancer，L2和L3的Loadbalancer，可以類比公有云上的內(nèi)部LB和外部LB的功能。

ACL基于L2到L4的所有控制信息進(jìn)行管控的一組DSL，可以十分靈活，例如：outport == “port1” && ip4 && tcp && tcp.src >= 10000 && tcp.dst <= 1000。

QoS，可以基于和ACL同樣的DSL進(jìn)行帶寬的控制。

NAT，同時(shí)提供DNAT和SNAT的控制方便內(nèi)外網(wǎng)絡(luò)通信。

DNS，內(nèi)置的分布式DNS，可以在本機(jī)直接返回內(nèi)部DNS的請(qǐng)求。

Gateway控制內(nèi)部和外部之間的集中式通信。

了解了這些，大家應(yīng)該就能發(fā)現(xiàn)，Kubernetes目前的網(wǎng)絡(luò)從功能層面其實(shí)只是OVN支持的一個(gè)子集，基本上所有Kubernetes的網(wǎng)絡(luò)需求都能在OVN中找到映射關(guān)系，我們簡(jiǎn)單來看下他們之間的映射。
OVN和Kubernetes的結(jié)合
Switch/Router -> Kubernetes基本的東西向互通容器網(wǎng)絡(luò)。這塊OVN的能力其實(shí)是大大超出，畢竟OVN的這套模型是針對(duì)多租戶進(jìn)行設(shè)計(jì)的，而Kubernetes現(xiàn)在只需要一個(gè)簡(jiǎn)單的二層網(wǎng)絡(luò)。

Loadbalancer → ClusterIP以及Loadbalancer類型的Service，可以取代kube-proxy的功能，OVN本身也可以實(shí)現(xiàn)云上ELB的功能。

ACL -> Networkpolicy本質(zhì)上更靈活因?yàn)榭梢詮腖2控制到L4并且DSL也支持更多的語法規(guī)則。

DNS -> 可以取代Kube-DNS/CoreDNS，同時(shí)由于OVN實(shí)現(xiàn)的是分布式DNS，整體的健壯性會(huì)比現(xiàn)在的Kubernetes方案要好。

可以看到Kubernetes的CNI、kube-proxy、Kube-DNS、NetworkPolicy、Service等等概念OVN都有對(duì)應(yīng)的方案，而且在功能或者穩(wěn)定性上還有增強(qiáng)。更不要說還有QoS、NAT、Gateway等等現(xiàn)在Kubernetes中沒有的概念。可以看到如果能把IaaS領(lǐng)域的網(wǎng)絡(luò)能力往Kubernetes平移，我們還有很多的提升空間。
Kubernetes網(wǎng)絡(luò)未來增強(qiáng)的方向
最后來說說我認(rèn)為的未來Kubernetes網(wǎng)絡(luò)可能的增強(qiáng)方向。
Kubernetes網(wǎng)絡(luò)功能和IaaS網(wǎng)絡(luò)功能打平
現(xiàn)在的Kubernetes網(wǎng)絡(luò)模型很類似之前公有云上的經(jīng)典網(wǎng)絡(luò)，所有用戶大二層打通，通過安全策略控制訪問。我們現(xiàn)在也都知道公有云多租戶不能這么做VPC肯定是標(biāo)配。因此未來Kubernetes網(wǎng)絡(luò)可能也會(huì)向著多租戶方向前進(jìn)，在VPC的基礎(chǔ)上有更多的路由控制、NAT控制、帶寬控制、浮動(dòng)IP等等現(xiàn)在IaaS上很常見的功能。
性能
現(xiàn)有的開源方案其實(shí)主要還是依賴原有的Linux網(wǎng)絡(luò)棧，沒有針對(duì)性的優(yōu)化。理論上容器的密度比傳統(tǒng)虛擬化高，網(wǎng)絡(luò)壓力會(huì)更大。OVS現(xiàn)在有DPDK等Kernel bypass的DataPath，繞過Linux內(nèi)核棧來實(shí)現(xiàn)低延遲和大吞吐網(wǎng)絡(luò)。未來隨著容器的密度越來越大，我認(rèn)為會(huì)出現(xiàn)這種針對(duì)容器架構(gòu)專門優(yōu)化的網(wǎng)絡(luò)方案，而不是依舊依賴Linux網(wǎng)絡(luò)棧。
監(jiān)控和問題排查
現(xiàn)有的網(wǎng)絡(luò)問題排查十分困難，如果所有的數(shù)據(jù)平面都由一個(gè)項(xiàng)目完成，比如OVN，那么學(xué)習(xí)成本和排障都會(huì)容易一些。此外OVS社區(qū)已經(jīng)有了很多成熟的監(jiān)控，追蹤，排障方案，隨著容器的使用場(chǎng)景變多，我認(rèn)為外圍的工具也需要能夠很好的支撐這種模式的網(wǎng)絡(luò)運(yùn)維問題。
Q&A
Q：OVS方案與基于三層交換機(jī)方案對(duì)比，各有什么優(yōu)缺點(diǎn)？
A：OVS最大的優(yōu)點(diǎn)在于可編程，靈活性比較好。虛擬網(wǎng)絡(luò)不用手動(dòng)插網(wǎng)線，而且有OpenFlow加持，可以實(shí)現(xiàn)一些普通交換機(jī)無法實(shí)現(xiàn)的流量控制。物理交換機(jī)的主要有點(diǎn)就是性能好，而且比較穩(wěn)定，不容易出問題。
Q：OVN不支持ECMP，貌似現(xiàn)在還是active-standby機(jī)制，你們?cè)趺唇鉀QGateway瓶頸問題？
A：有幾種方式：1. Gateway用DPDK這樣的高速DataPath；2. 多Gateway，用策略路不同的IP段走不同Gateway，可以分擔(dān)流量；3. 不使用OVN概念的Gateway，自己做一些手腳從每臺(tái)宿主機(jī)直接出去，也是分擔(dān)流量降低單點(diǎn)的風(fēng)險(xiǎn)。
Q：OVN-Kubernetes好像只支持每個(gè)部署節(jié)點(diǎn)一個(gè)虛擬網(wǎng)絡(luò)網(wǎng)段。如何避免IP池浪費(fèi)和不均衡？
A：這個(gè)其實(shí)是這個(gè)項(xiàng)目實(shí)現(xiàn)的網(wǎng)絡(luò)模型的一個(gè)局限性。在我們的實(shí)現(xiàn)里是以namespace為粒度劃分子網(wǎng)，可以對(duì)每個(gè)namespace進(jìn)行控制，情況會(huì)好很多。
Q：OVN如果有不同的Chassis，但是相同IP就會(huì)造成網(wǎng)絡(luò)異常（比如物理機(jī)，VM裝上OVN，注冊(cè)到遠(yuǎn)端后，被重建，后面又注冊(cè)到遠(yuǎn)端，但是Chassis已經(jīng)改變），會(huì)導(dǎo)致大量節(jié)點(diǎn)Geneve網(wǎng)絡(luò)異常。你們?cè)趺唇鉀Q這個(gè)問題？
A：暫時(shí)沒碰到這個(gè)問題，但是我們?cè)趯?shí)現(xiàn)的一個(gè)原則就是盡可能保證所有的操作都是冪等的。向這種可能需要在重連前做一個(gè)檢查，判斷是否有過期的數(shù)據(jù)需要清理，再連接，或者復(fù)用舊的連接信息去連接。
Q：如何debug OVN邏輯拓?fù)涫欠衽渲糜袉栴}？
A：目前debug確實(shí)很多情況只能靠眼看，也可以使用ovn-trace這個(gè)工具可以打印數(shù)據(jù)包在邏輯流里的鏈路來排查。
Q：OVS跟Calico等有啥區(qū)別？
A：Calico主要依賴Linux的路由功能做網(wǎng)絡(luò)打通，OVS是在軟件交換機(jī)層面實(shí)現(xiàn)網(wǎng)絡(luò)打通，并提供了更豐富的網(wǎng)絡(luò)功能。
Q：OVS的封包支持有STT和Geneve，你們選用哪種，為什么？
A：其實(shí)還支持VXLAN，我們選的Geneve。原因比較簡(jiǎn)單，Geneve是第一個(gè)OVN支持的封包協(xié)議，而且看了一些評(píng)測(cè)，據(jù)說在搞內(nèi)核開啟UDP Checksum的情況下性能會(huì)比VXLAN要好一些。
Q：OVS如何實(shí)現(xiàn)固定容器IP？
A：這個(gè)其實(shí)OVS有對(duì)應(yīng)的設(shè)置可以給每個(gè)端口設(shè)定IP和MACE，這樣網(wǎng)卡啟動(dòng)時(shí)配置相同的信息就可以了，難點(diǎn)其實(shí)是如何控制OVN來分配 IP，感覺這個(gè)話題可以再開一場(chǎng)分享來討論了。
Q：可以簡(jiǎn)單介紹下你們準(zhǔn)備開源的網(wǎng)絡(luò)功能嗎？
A：每個(gè)namespace和一個(gè)logical_switch綁定，支持子網(wǎng)分配，支持固定 IP，支持 QoS，支持NetworkPolicy，內(nèi)置的LB，內(nèi)置的DNS，大致就是把OVN的概念映射到Kubernetes。
Q：想了解一下，如果采用OVN，是不是意味著使用OpenStack平臺(tái)和Kubernetes網(wǎng)絡(luò)可以直接互通？完成業(yè)務(wù)在虛擬機(jī)和Pod之間的全新負(fù)載方式？
A：是這樣的，如果涉及的合理可以做到容器和VM使用同一個(gè)底層網(wǎng)絡(luò)基礎(chǔ)設(shè)施，VM和容器之間可以IP直達(dá)，所有的ACL、LB都是打通的。
Q：直接把OpenShift OVS抽出來做Kubernetes的網(wǎng)絡(luò)插件和靈雀云做的這個(gè)區(qū)別在哪？
A：功能上有很多是相同的，因?yàn)榈讓佣际荗VS。如果關(guān)注Roadmap會(huì)發(fā)現(xiàn)OpenShift之后也會(huì)采用OVS的模式。從架構(gòu)的角度來看，現(xiàn)在openshift-multitenant的實(shí)現(xiàn)很類似Neutron之前那一套，各種Agent，之后會(huì)統(tǒng)一到OVN。另一方面OpenShift的網(wǎng)絡(luò)插件綁定的太死了，所以我們決定還是自己抽出來，順便能實(shí)現(xiàn)我們的一些特殊功能，比如固定IP，子網(wǎng)共享，以及一些網(wǎng)關(guān)控制層面的功能。
Q：請(qǐng)問Geneve和VXLAN的區(qū)別有哪些？
A：Geneve可以理解為下一代VXLAN，VXLAN相對(duì)VLAN來說頭部更長可以支持更多的VLAN，但是由于是固定長度的封裝頭，不能任意加控制信息。Geneve采用變長的封裝頭，可以加很多自定義的控制信息，方便之后做更復(fù)雜的網(wǎng)絡(luò)管控。
Q：Docker CNM也支持固定IP，和你說的固定IP是一回事嗎？另外，基于OVS建立的網(wǎng)絡(luò)是CNI還是CNM的呢？
A：基于CNI，因?yàn)槲覀円蕾嘖ubernetes的模型。不過話說回來我很喜歡Docker CNM那套模型，比CNI要實(shí)用很多。固定IP其實(shí)只是個(gè)功能，各種模型下都可以實(shí)現(xiàn)，效果就是可以給Pod指定IP啟動(dòng)，Workload下的多個(gè)Pod實(shí)用的是一組固定的地址。
Q：目前你們對(duì)企業(yè)的解決方案里會(huì)默認(rèn)采用這種網(wǎng)絡(luò)模式么？
A：這個(gè)方案是我們這幾年需求和碰到坑的一個(gè)積累吧，現(xiàn)在還不會(huì)直接給企業(yè)用，我們還需要一些功能的開發(fā)和測(cè)試，但是之后Overlay的場(chǎng)景這個(gè)肯定是主推了，主要是取代原來的Flannel VXLAN網(wǎng)絡(luò)。
Q：你了解Contiv網(wǎng)絡(luò)方案嗎，和貴公司的實(shí)現(xiàn)有哪些區(qū)別？
A：Contiv是思科做的，也是OVS實(shí)現(xiàn)的，不過它的實(shí)現(xiàn)比較早，自己手動(dòng)實(shí)現(xiàn)了整個(gè)控制平面，可以認(rèn)為自己寫了個(gè)跟OVN類似的東西來控制 OVS。不過看它最近已經(jīng)很少更新了。用OVN能用很少的代碼就實(shí)現(xiàn)基本相同的功能。Contiv有個(gè)比較獨(dú)特的功能就是支持BGP的網(wǎng)絡(luò)間通信，這個(gè)是OVN暫時(shí)不支持的。
以上內(nèi)容根據(jù)2019年3月26日晚微信群分享內(nèi)容整理。分享人劉夢(mèng)馨，靈雀云高級(jí)工程師。2014年加入靈雀云容器團(tuán)隊(duì)，長期參與容器調(diào)度平臺(tái)和容器網(wǎng)絡(luò)架構(gòu)的產(chǎn)品研發(fā)和技術(shù)架構(gòu)演進(jìn)，參與自研容器網(wǎng)絡(luò)和容器應(yīng)用網(wǎng)關(guān)。目前主要專注于容器網(wǎng)絡(luò)功能的拓展和架構(gòu)優(yōu)化。DockOne每周都會(huì)組織定向的技術(shù)分享，歡迎感興趣的同學(xué)加微信：liyingjiesd，進(jìn)群參與，您有想聽的話題或者想分享的話題都可以給我們留言。