[轉]Kube-OVN:基於 OVN 的開源 Kubernetes 網絡實踐

 

原文:https://www.infoq.cn/article/2Pr39j0jJcbWpu7K*prP/

-----------------------------

今天,許多企業開始運行 Kubernetes 集羣,並從中受益。但我們仍然不得不承認,Kubernetes 底層實現非常複雜,這其中一個最複雜,就是網絡相關的部件。

 

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 基本已經成爲網絡虛擬化的標準。

 

什麼是 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 提供了大量目前 Kubernetes 不具備的網絡功能,並在原有基礎上進行增強。通過將 OpenStack 領域成熟的網絡功能平移到 Kubernetes,來應對更加複雜的基礎環境和應用合規性要求。

 

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 負責監聽 API Server 事件,針對 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 中。

 

下一步開源計劃

目前 Kube-OVN 已經在 github 上開源。OVN 安裝比較繁瑣,Kube-OVN 特意做了安裝的簡化,現在只需要兩個 yaml 就可以部署一個完整的 Kube-OVN。在使用方面也做了優化,通過直觀的 annotation 即可對網絡進行配置。此外還針對不使用任何 annotation 的情況內置了一套默認配置。用戶可以使用默認的子網,默認的 IP 分配策略,默認的分佈式網關以及內嵌的負載均衡器,這些都不需要任何配置就可以默認啓用。歡迎大家體驗試用,多提反饋和意見。

 

近期 Kube-OVN 開源項目將主要着力於實現三大目標:第一,集中式網關的高可用,消滅整個架構中最後一個單點;第二,內嵌 DNS,去除 Kube-DNS/CoreDNS 的依賴,將整個數據平面用 OVN 進行統一;第三,NetworkPolicy 實現。

 

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

 

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章