文章目錄

• Kubernetes 網絡的局限性
• OVS和OVN網絡方案的能力
• Kubernetes 網絡未來增強的方向

本文為2019-3月26日靈雀云Kubernetes專家劉夢馨在Dockone社區的主題分享。他從Kubernetes網絡的局限性、OVS和OVN網絡方案的能力、OVN和Kubernetes的結合、Kubernetes網絡增強的未來方向等方面分享了他本人的思考，以及靈雀云在此方面的產品進展。

作者：靈雀云劉夢馨

Kubernetes 網絡的局限性

Kubernetes 提出了很多網絡概念，很多開源項目都有自己的實現。然而由于各個網絡功能都是在不同的項目中實現，功能和性能也各有千秋，缺乏統一的解決方案，在使用過程中經常會陷入到底該用哪個的抉擇中。同時 cni, dns, service 的實現又在不同的項目，一旦網絡出現問題，排查也會在多個組件間游走，是一個十分痛苦的過程。

盡管 k8s 提出了很多網絡的概念，但是在真實應用中很多人會有這樣的感覺：網絡這塊還是很薄弱，很多功能缺乏，方案也不夠靈活。尤其是和搞傳統基礎設施網絡的人溝通會發現，在他們眼里，k8s的網絡還很初級。我們熟悉的 k8s 網絡是 cni，service，dns，ingress，network policy這樣的模式。而做IaaS的視角完全不同，他們每次提起是 vpc，subnet，vnic，floating ip，在此之上有dhcp，路由控制，安全組，QoS，負載均衡，域名解析這樣的基礎網絡功能。

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

傳統網絡部門的人都會問，為什么不用 OVS 來做網絡方案，很多需求用只要容器網絡接入ovs網絡，剩下事情網絡部門自己就知道怎么去做了，都不用我們實現太多額外的功能。也有很多人向我們推薦了 OVN ，用這個能很方便地實現這些功能。也正由此我們開始去關注 OVS/OVN 這種之前主要應用于 OpenStack 生態系統的網絡工具。下面我就來介紹一下 OVS 和 OVN。

OVS和OVN網絡方案的能力

網絡的概念比較晦澀一些，但是好在大家都對 Docker 和k8s比較熟悉，可以做個類比。如果說 Docker 是對單機計算資源的虛擬化，那么 OVS 就是對單機網絡進行虛擬化的一個工具。它最基本的功能是實現了虛擬交換機，可以把虛擬網卡和虛擬交換機的端口連接，這樣一個交換機下的多個網卡網絡就打通了，類似Linux Bridge 的功能。在此之上，OVS 很重要的一點就是支持 Openflow，這是一種可編程的流量控制語言，可以方便我們以編程的方式對流量進行控制，例如轉發，拒絕，更改包信息，NAT，QoS 等等。此外 OVS 還支持多中網絡流量監控的協議，方便我們可視化監控并跟蹤整個虛擬網絡的流量情況。

但是，OVS 只是一個單機軟件，它并沒有集群的信息，自己無法了解整個集群的虛擬網絡狀況，也就無法只通過自己來構建集群規模的虛擬網絡。這就好比是單機的 Docker，而 OVN 就相當于是 OVS 的k8s，它提供了一個集中式的 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 控制內部和外部之間的集中式通信。

了解了這些，大家應該就能發現，k8s 目前的網絡從功能層面其實只是 OVN 支持的一個子集，基本上所有 k8s 的網絡需求都能在 OVN 中找到映射關系，我們簡單來看下他們之間的映射。

OVN 和 Kubernetes 的結合

Switch/Router -> k8s基本的東西向互通容器網絡。這塊 OVN 的能力其實是大大超出，畢竟 OVN 的這套模型是針對多租戶進行設計的，而 k8s 現在只需要一個簡單的二層網絡。

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

ACL -> Networkpolicy 本質上更靈活因為可以從 L2 控制到 L4 并且 DSL 也支持更多的語法規則。

DNS -> 可以取代 kube-dns/coredns，同時由于 OVN 實現的是分布式 DNS，整體的健壯性會比現在的 k8s 方案要好。

可以看到 k8s 的 cni, kube-proxy, kube-dns, networkpolicy, service 等等概念 OVN 都有對應的方案，而且在功能或者穩定性上還有增強。更不要說還有 QoS, NAT, Gateway 等等現在 k8s 中沒有的概念?？梢钥吹饺绻馨?IaaS 領域的網絡能力往 k8s 平移，我們還有很多的提升空間。

Kubernetes 網絡未來增強的方向

最后來說說我認為的未來 k8s 網絡可能的增強方向。

1. k8s 網絡功能和 IaaS 網絡功能打平

現在的 k8s 網絡模型很類似之前公有云上的經典網絡，所有用戶大二層打通，通過安全策略控制訪問。我們現在也都知道公有云多租戶不能這么做 vpc 肯定是標配。因此未來 k8s 網絡可能也會向著多租戶方向前進，在 vpc 的基礎上有更多的路由控制，nat控制，帶寬控制，浮動 IP 等等現在 IaaS 上很常見的功能。

2. 性能

現有的開源方案其實主要還是依賴原有的 linux 網絡棧，沒有針對性的優化。理論上容器的密度比傳統虛擬化高，網絡壓力會更大。OVS 現在有 DPDK 等 kernel bypass 的 datapath，繞過 Linux 內核棧來實現低延遲和大吞吐網絡。未來隨著容器的密度越來越大，我認為會出現這種針對容器架構專門優化的網絡方案，而不是依舊依賴 linux網絡棧。

3. 監控和問題排查

現有的網絡問題排查十分困難，如果所有的數據平面都由一個項目完成，比如 OVN，那么學習成本和排障都會容易一些。此外 OVS 社區已經有了很多成熟的監控，追蹤，排障方案，隨著容器的使用場景變多，我認為外圍的工具也需要能夠很好的支撐這種模式的網絡運維問題。

今天我要分享的內容基本就結束了，我們靈雀云內部目前使用的基于ovn的kubernetes網絡，四月份會開源出來，感興趣的同學到時候可以關注一下。

Q&A

Q1：OVS 方案與基于三層交換機方案對比，各有什么優缺點？

A1：OVS最大的優點在于可編程，靈活性比較好。虛擬網絡不用手動插網線，而且有openflow加持，可以實現一些普通交換機無法實現的流量控制。物理交換機的主要有點就是性能好，而且比較穩定，不容易出問題。

Q2：OVN不支持ecmp，貌似現在還是active-standby機制，你們怎么解決gateway瓶頸問題？

A2：有幾種方式：1. gateway 用 dpdk 這樣的高速 datapath；2. 多gateway，用策略路不同的ip段走不同gateway，可以分擔流量；3. 不使用 ovn概念的 gateway，自己做一些手腳從每臺宿主機直接出去，也是分擔流量降低單點的風險。

Q3：ovn-k8s好像只支持每個部署節點一個虛擬網絡網段。如何避免ip池浪費和不均衡？

A3：這個其實是這個項目實現的網絡模型的一個局限性。在我們的實現里是以 namespace 為粒度劃分子網，可以對每個namespace進行控制，情況會好很多.

Q4：ovn如果有不同的chassis，但是相同ip就會造成網絡異常（比如物理機，vm裝上ovn，注冊到遠端后，被重建，后面又注冊到遠端，但是chassis已經改變），會導致大量節點geneve網絡異常。你們怎么解決這個問題？

A4：暫時沒碰到這個問題，但是我們在實現的一個原則就是盡可能保證所有的操作都是冪等的。向這種可能需要在重連前做一個檢查，判斷是否有過期的數據需要清理，再連接，或者復用舊的連接信息去連接。

Q5：如何debug ovn邏輯拓撲是否配置有問題？

A5：目前debug確實很多情況只能靠眼看，也可以使用 ovn-trace 這個工具可以打印數據包在邏輯流里的鏈路來排查.

Q6：ovs跟calico等有啥區別？

A6: calico 主要依賴 linux 的路由功能做網絡打通，ovs 是在軟件交換機層面實現網絡打通，并提供了更豐富的網絡功能。

Q7：ovn 的封包支持有stt 和geneve，你們選用哪種，為什么？

A7：其實還支持 vxlan，我們選的geneve。原因比較簡單，geneve是第一個ovn支持的封包協議，而且看了一些評測，據說在搞內核開啟 udp checksum 的情況下性能會比 vxlan 要好一些。

Q8：ovs如何實現固定容器ip？

A8：這個其實ovs有對應的設置可以給每個端口設定 ip 和 mac，這樣網卡啟動時配置相同的信息就可以了，難點其實是如何控制ovn來分配 ip，感覺這個話題可以再開一場分享來討論了。

Q9：可以簡單介紹下你們準備開源的網絡功能嗎？

A9：每個 namespace 和一個 logical_switch綁定，支持子網分配，支持固定 ip，支持 qos，支持 networkpolicy，內置的 lb，內置的 dns，大致就是把 ovn的概念映射到kuberentes。

Q10：想了解一下，如果采用OVN，是不是意味著使用Openstack平臺和k8s網絡可以直接互通？完成業務在虛擬機和POD之間的全新負載方式？

A10：是這樣的，如果涉及的合理可以做到容器和vm使用同一個底層網絡基礎設施，vm和容器之間可以 ip 直達，所有的acl，lb，都是打通的。

Q11：ovs/OVN是如何集成到k8s平臺的？是直接以網絡插件的方式?類似calico或者OpenShiftSDN那種？

A11：網絡插件的形式，兩個 yaml 就可以部署出來。

Q12:直接把openshift ovs抽出來做k8s的網絡插件和靈雀云做的這個區別在哪？

A12：功能上有很多是相同的，因為底層都是 ovs。如果關注 roadmap 會發現 openshift 之后也會采用 ovn 的模式。從架構的角度來看，現在openshift-multitenant 的實現很類似neutron之前那一套，各種agent，之后會統一到 ovn。另一方面 openshift的網絡插件綁定的太死了，所以我們決定還是自己抽出來，順便能實現我們的一些特殊功能，比如固定IP，子網共享，以及一些網關控制層面的功能。

Q13：你們的ovn使用版本是多少，集群規模如何？

A13：我們目前是2.10.1，我們現在規模還比較小，幾十臺這個規模，主要是內部的一些環境在使用。

Q14:前面說支持vxlan，貌似vxlan攜帶信息很少，ovn如何解決vxlan攜帶metadata信息少的問題？

A14:這個沒有具體關注是如何攜帶這些信息的，如果使用的是 geneve 支持變長的頭部，可以多加很多控制信息。

Q15:請問geneve和vxlan的區別有哪些？

A15: geneve 可以理解為下一代vxlan，vxlan 相對 vlan 來說頭部更長可以支持更多的vlan，但是由于是固定長度的封裝頭，不能任意加控制信息。geneve采用變長的封裝頭，可以加很多自定義的控制信息，方便之后做更復雜的網絡管控。

Q16:openstack 有個kuryr-kubernetes 項目，它的目的是通過neutron來納管pod網絡，可以實現namespace對應network，service對應lb，pod對應port等，這個貌似支持的也很好，但不支持多租戶，和你們做的ovn的方案有類似和不同吧？！如果你們開源了很想試一試！

A16: 之前沒有細看這個項目，看描述的話我覺得是很可能用到是相同的方案。多租戶這塊其實有很多的問題，有的是 k8s 本身設計層面的問題，可能還是一個很長期的事情。開源了我會第一時間通知大家的。

Q17:如果你們開源的話，會以什么形式呈現呢，是在github上開源，還是如何？我們如何能獲取到你們開源的信息？？

A17: 會在 github上。歡迎大家關注靈雀云的公眾號會有官方通知。

Q18:openstack現在有個mangrum項目，基本上就是讓openstack跟k8s做一些融合，不知道這個跟您講得這個融合之間有沒有類似的地方，以及異同？

A18: 早期關注過這個項目，最近關注的不多了，如果是做融合我覺得大家的方案可能都是大同小異的，可能我們會增加一些我們比較特色的功能（固定IP，網關控制等等。

Q19: 用genve的網絡方案有哪些能舉幾個例子嗎？

A19: 我了解的就是ovs，還有一些特殊的交換機也支持，不過相對來說還是個比較新的協議。

Q20:現在很多公司要么是做k8s應用層開發，要么是做IaaS層的云平臺，不知道你們公司是具體做什么的，為什么會在這么重的兩個地方同時發力？

A20：這我得給你問問老板去，我感覺還是需求驅動吧，就比如網絡這塊，碰到客戶成熟了，要求上來了，就不得不從根本的地方去提升我們的能力。

Q21：docker CNM也支持固定ip，和你說的固定ip是一回事嘛？另外，基于OVS建立的網絡是CNI還是CNM的呢？

A21:基于CNI，因為我們依賴k8s的模型。不過話說回來我很喜歡docker cnm 那套模型，比 cni要實用很多。固定IP其實只是個功能，各種模型下都可以實現，效果就是可以給 pod 指定ip啟動，workload 下的多個pod實用的是一組固定的地址。

Q22: 目前你們對企業的解決方案里會默認采用這種網絡模式么？

A22：這個方案是我們這幾年需求和碰到坑的一個積累吧，現在還不會直接給企業用，我們還需要一些功能的開發和測試，但是之后overlay的場景這個肯定是主推了，主要是取代原來的 flannel vxlan 網絡。

Q23:您了解contiv網絡方案嗎，和貴公司的實現有哪些區別？

A23：contiv 是思科做的，也是 ovs 實現的，不過它的實現比較早，自己手動實現了整個控制平面，可以認為自己寫了個跟 ovn 類似的東西來控制 ovs。不過看他最近已經很少更新了。用 ovn 能用很少的代碼就實現基本相同的功能。contiv 有個比較獨特的功能就是支持 bgp 的網絡間通信，這個是 ovn 暫時不支持的。

總結

以上是生活随笔為你收集整理的灵雀云基于 OVN 的 Kubernetes 网络架构解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。