Kube-OVN:基于OVN的开源Kubernetes网络实践
戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦!
技術(shù)頭條:干貨、簡潔、多維全面。更多云計(jì)算精華知識盡在眼前,get要點(diǎn)、solve難題,統(tǒng)統(tǒng)不在話下!
??
今天,許多企業(yè)開始運(yùn)行Kubernetes集群,并從中受益。但我們?nèi)匀徊坏貌怀姓J(rèn),Kubernetes底層實(shí)現(xiàn)非常復(fù)雜,這其中一個最復(fù)雜,就是網(wǎng)絡(luò)相關(guān)的部件。
Kube-OVN開源網(wǎng)絡(luò)插件誕生初衷
從當(dāng)前Kubernetes網(wǎng)絡(luò)現(xiàn)狀來看,Kubernetes 網(wǎng)絡(luò)相關(guān)的組件非常分散。比如,CNI 負(fù)責(zé)基礎(chǔ)容器網(wǎng)絡(luò),它本身只是個接口標(biāo)準(zhǔn),社區(qū)和市場上都有很多各自的實(shí)現(xiàn);集群內(nèi)的服務(wù)發(fā)現(xiàn)網(wǎng)絡(luò)需要依賴 kube-proxy,而 kube-proxy 又有 iptables 和 ipvs 兩種實(shí)現(xiàn);集群內(nèi)的 DNS 需要依賴額外組件kube-dns 或coredns;集群對外訪問的負(fù)載均衡器服務(wù)需要依賴各個云廠商提供的Cloud-Provider;網(wǎng)絡(luò)策略的 NetworkPolicy 本身只是一個標(biāo)準(zhǔn)接口,社區(qū)中也有各自不同的實(shí)現(xiàn)。此外還有 ingress,Kubernetes提供的只是一個標(biāo)準(zhǔn)接口,社區(qū)中同樣有各自的實(shí)現(xiàn)。
分散的網(wǎng)絡(luò)組件導(dǎo)致容器網(wǎng)絡(luò)流量被分散到了不同的網(wǎng)絡(luò)組件上,一旦出現(xiàn)問題需要在多個組件間游走逐個排查。在實(shí)際運(yùn)維過程中網(wǎng)絡(luò)問題通常是最難排查的,需要維護(hù)人員掌握全鏈路上所有組件的使用、原理以及排查方式。因此,如果有一個網(wǎng)絡(luò)方案能夠?qū)⑺袛?shù)據(jù)平面統(tǒng)一,那么出現(xiàn)問題時只需要排查一個組件即可。
其次,現(xiàn)有網(wǎng)絡(luò)插件種類繁多,但是在落地時會發(fā)現(xiàn),每個網(wǎng)絡(luò)插件由于覆蓋的功能集合不同,很難在所有場景使用同一套方案。為了滿足不同的客戶需求,很多廠商一度同時支持多種網(wǎng)絡(luò)方案,給自身帶來很大負(fù)擔(dān)。在落地過程中,還發(fā)現(xiàn)很多傳統(tǒng)的網(wǎng)絡(luò)方案在容器網(wǎng)絡(luò)中是缺失的。一些高級功能是所有網(wǎng)絡(luò)插件都無法滿足的,比如:子網(wǎng)劃分、vlan 綁定、nat、qos、固定 IP、基于acl的網(wǎng)絡(luò)策略等等。
現(xiàn)有 Kubernetes網(wǎng)絡(luò)能力是否足夠?答案很明顯,如果真的已經(jīng)足夠強(qiáng)大,落地的時候就不會出現(xiàn)這么多的問題。從更大的格局來看,Kubernetes本質(zhì)上是提供了一層虛擬化網(wǎng)絡(luò)。而虛擬化網(wǎng)絡(luò)并不是一個新問題。在OpenStack社區(qū),虛擬網(wǎng)絡(luò)已經(jīng)有了長足的發(fā)展,方案比較成熟,OVS?基本已經(jīng)成為網(wǎng)絡(luò)虛擬化的標(biāo)準(zhǔn)。
什么是OVN?
OVS 是一個單機(jī)的虛擬網(wǎng)絡(luò)交換機(jī),同時支持 OpenFlow,可以實(shí)現(xiàn)復(fù)雜的網(wǎng)絡(luò)流量編程,這也是網(wǎng)絡(luò)虛擬化的基礎(chǔ)。通過OVS 和 OpenFlow 可以實(shí)現(xiàn)細(xì)粒度的流量控制。如果做個類比,OVS 相當(dāng)于網(wǎng)絡(luò)虛擬化里的 Docker。
OVS 只是個單機(jī)程序,想生成一個集群規(guī)模的虛擬網(wǎng)絡(luò)就需要一個控制器,這就是 OVN。OVN 和 OVS 的關(guān)系就好比 Kubernetes 和 Docker 的關(guān)系。OVN 會將高層次的網(wǎng)絡(luò)抽象轉(zhuǎn)換成具體的網(wǎng)絡(luò)配置和流表,下發(fā)到各個節(jié)點(diǎn)的OVS上,實(shí)現(xiàn)集群網(wǎng)絡(luò)的管理。
由于 OVN 最初是為 OpenStack 網(wǎng)絡(luò)功能設(shè)計(jì)的,提供了大量 Kubernetes 網(wǎng)絡(luò)目前不存在的功能:
L2/L3 網(wǎng)絡(luò)虛擬化包括:
·?分布式交換機(jī),分布式路由器
·?L2到L4的ACL
·?內(nèi)部和外部負(fù)載均衡器
·?QoS,NAT,分布式DNS
·?Gateway
·?IPv4/IPv6 支持
此外 OVN 支持多平臺,可以在Linux,Windows,KVM,XEN,Hyper-V 以及 DPDK 的環(huán)境下運(yùn)行。
從上面可以看出,?OVN 可以覆蓋 CNI, Kube-Proxy, LoadBalancer, NetworkPolicy, DNS 等在內(nèi)的所有 Kubernetes 網(wǎng)絡(luò)功能,并在原有基礎(chǔ)上都有所增強(qiáng)。那么,何不嘗試把之前在OpenStack領(lǐng)域內(nèi)成熟的網(wǎng)絡(luò)功能平移到?Kubernetes 上呢,于是就誕生了這個開源項(xiàng)目 Kube-OVN。Kube-OVN提供了大量目前Kubernetes不具備的網(wǎng)絡(luò)功能,并在原有基礎(chǔ)上進(jìn)行增強(qiáng)。通過將OpenStack領(lǐng)域成熟的網(wǎng)絡(luò)功能平移到Kubernetes,來應(yīng)對更加復(fù)雜的基礎(chǔ)環(huán)境和應(yīng)用合規(guī)性要求。
Kube-OVN 重要功能及實(shí)現(xiàn)
目前大部分網(wǎng)絡(luò)插件的網(wǎng)絡(luò)拓?fù)涠际且粋€大二層網(wǎng)絡(luò),通過防火墻做隔離,這種形式非常類似公有云早期的經(jīng)典網(wǎng)絡(luò)。Kube-OVN在設(shè)計(jì)網(wǎng)絡(luò)支出時,同時把多租戶的場景考慮進(jìn)來,方便之后更好的擴(kuò)展高級功能,因此采用了不同的網(wǎng)絡(luò)拓?fù)洹?/span>
?
Kube-OVN?網(wǎng)絡(luò)拓?fù)?/span>
在Kube-OVN的網(wǎng)絡(luò)拓?fù)淅?#xff0c;不同 Namespace 對應(yīng)著不同的子網(wǎng)。子網(wǎng)是其中最為重要的概念,之后的內(nèi)置負(fù)載均衡器,防火墻,路由策略以及DNS的網(wǎng)絡(luò)功能都是和子網(wǎng)綁定的。我們做到了同一臺機(jī)器的不同 pod 可以使用不同的子網(wǎng),多個子網(wǎng)之間使用一個虛擬路由器進(jìn)行網(wǎng)絡(luò)的聯(lián)通。為了滿足Kubernetes中主機(jī)可以和容器互通的網(wǎng)絡(luò)要求,Kube-OVN在每個主機(jī)新增一塊虛擬網(wǎng)卡,并接入一個單獨(dú)的虛擬交換機(jī)和集群的虛擬路由器相連,來實(shí)現(xiàn)主機(jī)和容器網(wǎng)絡(luò)的互通。
在容器訪問外部網(wǎng)絡(luò)的策略中,Kube-OVN設(shè)計(jì)了兩種方案:一種是分布式 Gateway,每臺主機(jī)都可以作為當(dāng)前主機(jī)上 Pod 的出網(wǎng)節(jié)點(diǎn),做到出網(wǎng)的分布式。針對企業(yè)需要對流量進(jìn)行審計(jì),希望使用固定IP出網(wǎng)的場景,還做了和 namespace 綁定的 Gateway,可以做到一個 namespace 下的 Pod 使用一個集中式的主機(jī)出網(wǎng)。在整個網(wǎng)絡(luò)拓?fù)渲?#xff0c;除了集中式網(wǎng)關(guān),交換機(jī),路由器,防火墻,負(fù)載均衡器,DNS都是分布在每個節(jié)點(diǎn)上的,不存在網(wǎng)絡(luò)的單點(diǎn)。
Kube-OVN架構(gòu)圖
在實(shí)現(xiàn)的過程中,Kube-OVN對組件架構(gòu)進(jìn)行了大幅的簡化,整個流程中只需要一個全局Controller 和分布在每臺機(jī)器上的 CNI 插件,就可以組建網(wǎng)絡(luò),整體安裝十分簡單。其中全局Controller 負(fù)責(zé)監(jiān)聽 API Server 事件,針對 Namespace,Pod,Service,Endpoint 等和網(wǎng)絡(luò)相關(guān)的資源變化對 OVN 進(jìn)行操作。同時 Controller 會把操作 OVN 的結(jié)果,例如 IP ,Mac,網(wǎng)關(guān),路由等信息回寫到對應(yīng)資源的 annotation 中,而 CNI 插件則根據(jù)回寫的 annotation 信息操作本機(jī)的 OVS 以及主機(jī)網(wǎng)絡(luò)配置。通過這種架構(gòu)Kube-OVN將 CNI 插件和、Controller 和?OVN 解耦,通過 Apiserver 傳遞所需的網(wǎng)絡(luò)信息,方便快速開發(fā)迭代。
Kube-OVN選擇使用最基礎(chǔ)的 annotation ,而不是 CRD、API Aggregation 或者 Operator,也是出于降低復(fù)雜度的考慮,使用戶和開發(fā)者都能夠快速上手。
Kube-OVN主要具備五大主要功能:
1.?Namespace 和子網(wǎng)的綁定,以及子網(wǎng)間訪問控制;
2.?靜態(tài)IP分配;
3.?動態(tài)QoS;
4.?分布式和集中式網(wǎng)關(guān);
5.?內(nèi)嵌 LoadBalancer;
子網(wǎng)是Kube-OVN中最重要的概念,由于子網(wǎng)和 namespace 關(guān)聯(lián),因此只需要在 namespace 中設(shè)置對應(yīng)的 annotation 就可以完成子網(wǎng)的功能。Kube-OVN支持子網(wǎng)cidr,gateway,exclude_ips 以及 switch_name 的設(shè)置。同時支持基于子網(wǎng)的IP隔離,用戶可以輕松實(shí)施基本的網(wǎng)絡(luò)隔離策略。在后臺實(shí)現(xiàn)上,Kube-OVN會監(jiān)聽 namespace 的變化,并根據(jù)變化在?ovn 中創(chuàng)建并設(shè)置虛擬交換機(jī),將其和集群路由器關(guān)聯(lián),設(shè)置對應(yīng)的 acl,dns 和 lb。
靜態(tài)IP的使用可以直接在 Pod 中加入對應(yīng)的 annotation,Controller 在發(fā)現(xiàn)相關(guān) annotation 時會跳過自動分配階段,直接使用用戶指定的 IP/Mac。對應(yīng)多 Pod 的工作負(fù)載,例如 Deployment、DaemonSet,可以指定一個 ip-pool,工作負(fù)載下的 Pod 會自動使用ip-pool中未使用的地址。
在QoS功能中,分別實(shí)現(xiàn)了 ingress 和 egress 的帶寬限制,用戶可以在?Pod 運(yùn)行時通過動態(tài)調(diào)整 annotation 來實(shí)現(xiàn) QoS 的動態(tài)調(diào)整,而無需重啟 Pod。在后臺的實(shí)現(xiàn)中,?OVN 自帶的 QoS 功能工作在 Tunnel 端口,無法對同主機(jī)間 Pod 的互訪做 QoS 控制。因此Kube-OVN最終通過操作 OVS 的 ingress_policing_rate 和 port qos 字段來實(shí)現(xiàn) QoS 的控制。
在網(wǎng)關(guān)設(shè)計(jì)中,OVN的網(wǎng)關(guān)功能有一些使用限制,需要單獨(dú)的網(wǎng)卡來做 overlay 和 underlay 的流量交換,使用起來比較復(fù)雜,為了能夠適應(yīng)更廣泛的網(wǎng)絡(luò)條件并簡化用戶使用,Kube-OVN對網(wǎng)關(guān)部分進(jìn)行了調(diào)整。使用策略路由的方式根據(jù)網(wǎng)絡(luò)包的源 IP 選擇下一跳的機(jī)器,通過這種方式將流量導(dǎo)入所希望的邊界網(wǎng)關(guān)節(jié)點(diǎn),然后在網(wǎng)關(guān)節(jié)點(diǎn)通過 SNAT 的方式對外進(jìn)行訪問。這種方式用戶只需要在 namespace 中配置一個網(wǎng)關(guān)節(jié)點(diǎn)的 annotation 就可以配置對應(yīng)的流量規(guī)則。此外,Kube-OVN也支持非SNAT將容器IP直接暴露給外網(wǎng)的場景,這種情況下只需要外部添加一條靜態(tài)路由指向容器網(wǎng)絡(luò),就可以實(shí)現(xiàn) Pod IP 直接和外部互通。
內(nèi)嵌的 LoadBalancer 使用 OVN 內(nèi)置的 L2 LB,這樣集群內(nèi)部的服務(wù)發(fā)現(xiàn)功能可以直接在 OVS 層面完成,不需要走到宿主機(jī)的 iptable 或者 ipvs 規(guī)則,可以將 kube-porxy 的功能整合到 Kube-OVN 中。
下一步開源計(jì)劃
目前Kube-OVN已經(jīng)在 github 上開源。OVN 安裝比較繁瑣,Kube-OVN特意做了安裝的簡化,現(xiàn)在只需要兩個 yaml 就可以部署一個完整的 Kube-OVN。在使用方面也做了優(yōu)化,通過直觀的 annotation 即可對網(wǎng)絡(luò)進(jìn)行配置。此外還針對不使用任何 annotation的情況內(nèi)置了一套默認(rèn)配置。用戶可以使用默認(rèn)的子網(wǎng),默認(rèn)的IP分配策略,默認(rèn)的分布式網(wǎng)關(guān)以及內(nèi)嵌的負(fù)載均衡器,這些都不需要任何配置就可以默認(rèn)啟用。歡迎大家體驗(yàn)試用,多提反饋和意見。
近期Kube-OVN開源項(xiàng)目將主要著力于實(shí)現(xiàn)三大目標(biāo):第一,集中式網(wǎng)關(guān)的高可用,消滅整個架構(gòu)中最后一個單點(diǎn);第二,內(nèi)嵌 DNS,去除 Kube-DNS/CoreDNS 的依賴,將整個數(shù)據(jù)平面用 OVN 進(jìn)行統(tǒng)一;第三,NetworkPolicy實(shí)現(xiàn)。
長期來看,未來將實(shí)現(xiàn)對DPDK 和 Hardware Offload 的支持,解決 Overlay 網(wǎng)絡(luò)性能問題;將更多的 OVS 監(jiān)控和鏈路追蹤工具引入 Kubernetes;將OpenStack社區(qū)的網(wǎng)絡(luò)功能向Kubernetes平移,打造更完整的網(wǎng)絡(luò)體系。
目前Kube-OVN項(xiàng)目代碼已經(jīng)在Github 上開源,項(xiàng)目地址為:https://github.com/alauda/kube-ovn。項(xiàng)目使用寬松的Apache 2.0 協(xié)議,歡迎更多技術(shù)開發(fā)者和愛好者前去試用和使用。
?
福利
掃描添加小編微信,備注“姓名+公司職位”,加入【云計(jì)算學(xué)習(xí)交流群】,和志同道合的朋友們共同打卡學(xué)習(xí)!
推薦閱讀:
騰訊面試:一條SQL語句執(zhí)行得很慢的原因有哪些?
程序員專屬小情話,哎呦,不錯哦!| 程序員有話說
普通家庭走出信息學(xué)才子,抱病參賽奪世界信奧亞軍 | 人物志
Rust今天4歲啦, 為什么越來越多的知名項(xiàng)目用Rust來開發(fā)?
商湯“變法”:推中小學(xué)AI教材,mini自駕車,要打造AI時代的「清明上河圖」
轉(zhuǎn)行AI成為技術(shù)大牛,你需要理解這兩項(xiàng)技術(shù)!
真香,朕在看了!
總結(jié)
以上是生活随笔為你收集整理的Kube-OVN:基于OVN的开源Kubernetes网络实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Boost:reference wrap
- 下一篇: 怎么在电脑上删u盘歌曲 电脑上如何删除U