靈雀雲Kube-OVN：基於OVN的開源Kubernetes網絡實踐

近日，靈雀雲發佈了基於OVN的Kubernetes網絡組件Kube-OVN，並正式將其在Github上開源。Kube-OVN提供了大量目前Kubernetes不具有的網絡功能，並在原有基礎上進行加強。經過將OpenStack領域成熟的網絡功能平移到Kubernetes，來應對更加複雜的基礎環境和應用合規性要求。
目前Kube-OVN項目代碼已經在Github 上開源，項目地址爲：https://github.com/alauda/kub...。項目使用寬鬆的Apache 2.0 協議，歡迎更多技術開發者和愛好者前去試用和使用。

網絡插件那麼多，爲何還須要Kube-OVN？

網絡插件千千萬，爲何還要開發Kube-OVN？從當前Kubernetes網絡現狀來看，Kubernetes 網絡相關的組件很是分散。例如，CNI 負責基礎容器網絡，它自己只是個接口標準，社區和市場上都有不少各自的實現；集羣內的服務發現網絡須要依賴 kube-proxy，而 kube-proxy 又有 iptables 和 ipvs 兩種實現；集羣內的 DNS 須要依賴額外組件kube-dns 或coredns；集羣對外訪問的負載均衡器服務須要依賴各個雲廠商提供的Cloud-Provider；網絡策略的 NetworkPolicy 自己只是一個標準接口，社區中也有各自不一樣的實現。此外還有 ingress，Kubernetes提供的只是一個標準接口，社區中一樣有各自的實現。

分散的網絡組件致使容器網絡流量被分散到了不一樣的網絡組件上，一旦出現問題須要在多個組件間遊走逐個排查。在實際運維過程當中網絡問題一般是最難排查的，須要維護人員掌握全鏈路上全部組件的使用、原理以及排查方式。所以，若是有一個網絡方案可以將全部數據平面統一，那麼出現問題時只須要排查一個組件便可。

其次，現有網絡插件種類繁多，可是在落地時會發現，每一個網絡插件因爲覆蓋的功能集合不一樣，很難在全部場景使用同一套方案。爲了知足不一樣的客戶需求，不少廠商一度同時支持多種網絡方案，給自身帶來很大負擔。在落地過程當中，還發現不少傳統的網絡方案在容器網絡中是缺失的。一些高級功能是全部網絡插件都沒法知足的，好比：子網劃分、vlan 綁定、nat、qos、固定 IP、基於acl的網絡策略等等。

現有 Kubernetes網絡能力是否足夠？答案很明顯，若是真的已經作夠強大落地的時候就不會出現這麼多的問題。從更大格局來看，Kubernetes本質上是提供了一層虛擬化網絡。而虛擬化網絡並非一個新問題。在OpenStack社區，虛擬網絡已經有了長足的發展，方案成熟，OVS 基本已經成爲網絡虛擬化的標準。因而，靈雀雲開始把目光投向OVS 以及 OVS 的控制器OVN。

OVN 簡介

OVS 是一個單機的虛擬網絡交換機，同時支持 OpenFlow 能夠實現複雜的網絡流量編程，這也是網絡虛擬化的基礎。經過OVS 和 OpenFlow 能夠實現細粒度的流量控制。若是作個類比，OVS 至關於網絡虛擬化裏的 Docker。
OVS 只是個單機程序，想生成一個集羣規模的虛擬網絡就須要一個控制器，這就是 OVN。OVN 和 OVS 的關係就比如 Kubernetes 和 Docker 的關係。OVN 會將高層次的網絡抽象轉換成具體的網絡配置和流表，下發到各個節點的OVS上，實現集羣網絡的管理。
因爲 OVN 最初是爲 OpenStack 網絡功能設計的，提供了大量 Kubernetes 網絡目前不存在的功能：
L2/L3 網絡虛擬化包括：
• 分佈式交換機，分佈式路由器
• L2到L4的ACL
• 內部和外部負載均衡器
• QoS，NAT，分佈式DNS
• Gateway
• IPv4/IPv6 支持
此外 OVN 支持多平臺，能夠在Linux，Windows，KVM，XEN，Hyper-V 以及 DPDK 的環境下運行。
綜上能夠看出 OVN 能夠覆蓋 CNI, Kube-Proxy, LoadBalancer, NetworkPolicy, DNS 等在內的全部 Kubernetes 網絡功能，並在原有基礎上有所加強。將以前在OpenStack領域內成熟的網絡功能往 Kubernetes 平移，也就誕生了靈雀雲的開源項目 Kube-OVN.

Kube-OVN 重要功能及實現

目前大部分網絡插件的網絡拓撲都是一個大二層網絡，經過防火牆作隔離，這種形式很是相似公有云早期的經典網絡。Kube-OVN在設計網絡支出時同時把多租戶的場景考慮進來，方便以後更好的擴展高級功能，所以採用了不一樣的網絡拓撲。

Kube-OVN 網絡拓撲

在Kube-OVN的網絡拓撲裏，不一樣 Namespace 對應着不一樣的子網。子網是其中最爲重要的概念，以後的內置負載均衡器，防火牆，路由策略以及DNS的網絡功能都是和子網綁定的。咱們作到了同一臺機器的不一樣 pod 可使用不一樣的子網，多個子網之間使用一個虛擬路由器進行網絡的聯通。爲了知足Kubernetes中主機能夠和容器互通的網絡要求，Kube-OVN在每一個主機新增一塊虛擬網卡，並接入一個單獨的虛擬交換機和集羣的虛擬路由器相連，來實現主機和容器網絡的互通。
在容器訪問外部網絡的策略中，Kube-OVN設計了兩種方案：一種是分佈式 Gateway，每臺主機均可以做爲當前主機上 Pod 的出網節點，作到出網的分佈式。針對企業須要對流量進行審計，但願使用固定IP出網的場景，還作了和 namespace 綁定的 Gateway，能夠作到一個 namespace 下的 Pod 使用一個集中式的主機出網。在整個網絡拓撲中，除了集中式網關，交換機，路由器，防火牆，負載均衡器，DNS都是分佈在每一個節點上的，不存在網絡的單點。

Kube-OVN架構圖

在實現的過程當中，Kube-OVN對組件架構進行了大幅的簡化，整個流程中只須要一個全局Controller 和分佈在每臺機器上的 CNI 插件，就能夠組建網絡，總體安裝十分簡單。其中全局Controller 負責監聽 APIServer 事件，針對 Namespace，Pod，Service，Endpoint 等和網絡相關的資源變化對 OVN 進行操做。同時 Controller 會把操做 OVN 的結果，例如 IP ，Mac，網關，路由等信息回寫到對應資源的 annotation 中。而 CNI 插件則根據回寫的 annotation 信息操做本機的 OVS 以及主機網絡配置。經過這種架構Kube-OVN將 CNI 插件和、Controller 和 OVN 解耦，經過 Apiserver 傳遞所需的網絡信息，方便快速開發迭代。
Kube-OVN選擇使用最基礎的 annotation ，而不是 CRD、API Aggregation 或者 Operator，也是出於下降複雜度的考慮，使用戶和開發者都可以快速上手。
Kube-OVN主要具有五大主要功能：

1. Namespace 和子網的綁定，以及子網間訪問控制；
2. 靜態IP分配；
3. 動態QoS；
4. 分佈式和集中式網關；
5. 內嵌 LoadBalancer；

子網是Kube-OVN中最重要的概念，因爲子網和 namespace 關聯，所以只須要在 namespace 中設置對應的 annotation 就能夠完成子網的功能。Kube-OVN支持子網cidr，gateway，exclude_ips 以及 switch_name 的設置。同時支持基於子網的IP隔離，用戶能夠輕鬆實施基本的網絡隔離策略。在後臺實現上，Kube-OVN會監聽 namespace 的變化，並根據變化在 ovn 中建立並設置虛擬交換機，將其和集羣路由器關聯，設置對應的 acl，dns 和 lb。
靜態IP的使用能夠直接在 Pod 中加入對應的 annotation，Controller 在發現相關 annotation 時會跳過自動分配階段，直接使用用戶指定的 IP/Mac。對應多 Pod 的工做負載，例如 Deployment、DaemonSet，能夠指定一個 ip-pool，工做負載下的 Pod 會自動使用ip-pool中未使用的地址。

在QoS功能中，分別實現了 ingress 和 egress 的帶寬限制，用戶能夠在 Pod 運行時經過動態調整 annotation 來實現 QoS 的動態調整，而無需重啓 Pod。在後臺的實現中， OVN 自帶的 QoS 功能工做在 Tunnel 端口，沒法對同主機間 Pod 的互訪作 QoS 控制。所以Kube-OVN最終經過操做 OVS 的 ingress_policing_rate 和 port qos 字段來實現 QoS 的控制。
在網關設計中，OVN的網關功能有一些使用限制，須要單獨的網卡來作 overlay 和 underlay 的流量交換，使用起來比較複雜，爲了可以適應更普遍的網絡條件並簡化用戶使用，Kube-OVN對網關部分進行了調整。使用策略路由的方式根據網絡包的源 IP 選擇下一跳的機器，經過這種方式將流量導入所但願的邊界網關節點，而後在網關節點經過 SNAT 的方式對外進行訪問。這種方式用戶只須要在 namespace 中配置一個網關節點的 annotation 就能夠配置對應的流量規則。此外，Kube-OVN也支持非SNAT將容器IP直接暴露給外網的場景，這種狀況下只須要外部添加一條靜態路由指向容器網絡，就能夠實現 Pod IP 直接和外部互通。
內嵌的 LoadBalancer 使用 OVN 內置的 L2 LB，這樣集羣內部的服務發現功能能夠直接在 OVS 層面完成，不須要走到宿主機的 iptable 或者 ipvs 規則，能夠將 kube-porxy 的功能整合到 Kube-OVN 中。

開源計劃 & RoadMap

目前Kube-OVN已經在 github 上開源。OVN 安裝比較繁瑣，Kube-OVN特地作了安裝的簡化，如今只須要兩個 yaml 就能夠部署一個完整的 Kube-OVN。在使用方面也作了優化，經過直觀的 annotation 便可對網絡進行配置。此外還針對不使用任何 annotation的狀況內置了一套默認配置。用戶可使用默認的子網，默認的IP分配策略，默認的分佈式網關以及內嵌的負載均衡器，這些都不須要任何配置就能夠默認啓用。歡迎你們體驗試用，多給咱們提供反饋和意見。
關於Kube-OVN，近期靈雀雲將主要着力於實現三大目標：第一，集中式網關的高可用，消滅整個架構中最後一個單點；第二，內嵌 DNS，去除 Kube-DNS/CoreDNS 的依賴，將整個數據平面用 OVN 進行統一；第三，NetworkPolicy實現。

長期來看，Kube-OVN將來將實現對DPDK 和 Hardware Offload 的支持，解決 Overlay 網絡性能問題；將更多的 OVS 監控和鏈路追蹤工具引入 Kubernetes；將OpenStack社區的網絡功能向Kubernetes平移，打造更完整的網絡體系。