靈雀雲開源Kube-OVN網絡組件，增強Kubernetes網絡功能

• 2019 年 12 月 4 日
• 筆記

近日，靈雀雲宣布發佈基於OVN的Kubernetes網絡組件Kube-OVN，並正式將其在Github上開源。Kube-OVN提供了大量目前Kubernetes不具備的網絡功能，並在原有基礎上進行增強。通過將OpenStack領域成熟的網絡功能平移到Kubernetes，來應對更加複雜的基礎環境和應用合規性要求。

目前Kube-OVN項目代碼已經在Github 上開源，項目地址為：https://github.com/alauda/kube-ovn。項目使用寬鬆的Apache 2.0 協議，歡迎更多技術開發者和愛好者前去試用和使用。

Kube-OVN 五大重要功能

靈雀雲Kube-OVN主要實現五大功能：

Namespace和子網的綁定，以及子網間的訪問控制；

靜態IP分配；

動態QoS；

分佈式和集中式網關；

內嵌 LoadBalancer；

Kube-OVN架構圖

子網是靈雀雲Kube-OVN最重要的概念，子網與namespace 關聯，只需在 namespace中設置對應的 annotation即可實現子網的功能。Kube-OVN支持子網cidr、gateway、exclude_ips以及 switch_name 設置，同時支持基於子網的IP隔離，用戶可以輕鬆實施基本的網絡隔離策略。

靜態IP可以直接在 Pod 中加入對應annotation，Controller 在發現相關 annotation 時會跳過自動分配階段，直接使用用戶指定的 IP/Mac。

在QoS功能中，Kube-OVN分別實現了 ingress 和 egress 的帶寬限制，用戶可以在 Pod 運行時通過動態調整 annotation 來實現 QoS 的動態調整，無需重啟 Pod。

在網關設計中，使用策略路由根據網絡包的源 IP 選擇下一跳的機器，通過這種方式將流量導入所希望的邊界網關節點，在網關節點通過SNAT 的方式對外進行訪問。此外，也支持非SNAT將容器IP直接暴露給外網的場景。

內嵌LoadBalancer使用OVN 內置的 L2 LB，集群內部的服務發現功能可以直接在 OVS 層面完成，kube-porxy 的功能也整合到 Kube-OVN 當中。

網絡插件千千萬，

為啥還需要Kube-OVN？

在談及Kube-OVN開發的初衷時，靈雀雲首席Kubernetes專家劉夢馨表示，當前Kubernetes網絡組件非常分散，實現方式五花八門。

例如，CNI 負責基礎的容器網絡，本身只是接口標準，社區和市場上有很多實現；集群內的服務發現網絡需要依賴 kube-proxy，而 kube-proxy 本身又有 iptables 和 ipvs 兩種實現；集群內DNS 需要依賴額外的組件kube-dns或者coredns；集群對外訪問的負載均衡器服務依賴各個雲廠商提供的Cloud-Provider等等。分散的網絡組件給網絡問題排查帶來了巨大的複雜度，需要維護人員掌握全鏈路上所有組件的使用、原理以及排查方式。靈雀雲希望能夠通過一個網絡方案實現所有數據平面的統一，從而降低問題排查難度和工作量。

其次，現有網絡插件儘管種類繁多，但由於覆蓋的功能集合不同，落地時很難有一套方案能夠通吃所有場景。同時，很多傳統的網絡方案在容器網絡中都是缺失的，現有 Kubernetes網絡能力遠遠不足。而在OpenStack領域，虛擬網絡有了長足的發展，方案成熟，事實上OVS 已經成為網絡虛擬化的標準。而OVN 和 OVS 的關係好比 Kubernetes 和 Docker。OVN 將高層次的網絡抽象轉換成具體的網絡配置和流表，下發到各個節點的OVS實現集群網絡的管理。

OVN提供了大量 Kubernetes 網絡目前不存在的功能，涵蓋CNI、 Kube-Proxy、LoadBalancer、NetworkPolicy、DNS等在內的所有 Kubernetes 網絡功能，並在原有基礎上都有所增強。同時支持多平台，可以在Linux、Windows、KVM、XEN、Hyper-V 以及 DPDK 等環境下運行。

據悉，接下來靈雀雲將在Kubernetes網絡方面繼續加大研發力度，增強各方面功能。不斷解決每個單點問題，改善網絡性能，引入更多工具，打造更加完整的Kubernetes網絡體系。

靈雀雲CTO陳愷表示：「靈雀雲是開源技術和開源精神的受益者，也是CNCF/CDF等開源社區的早期倡導者和貢獻者。取之開源回饋開源，未來我們將在開源領域持續大力投入，在Kubernetes及其周邊項目／技術上繼續做出貢獻，進一步推動Kubernetes、DevOps、微服務等雲原生相關技術和理念的成熟與普及。」