基于DPU與SmartNIC的K8s Service解決方案

1.? 方案背景

1.1. Kubernetes Service介紹

Kubernetes Service是Kubernetes中的一個(gè)核心概念，它定義了一種抽象，用于表示一組提供相同功能的Pods（容器組）的邏輯集合，并提供了一種方式讓這些Pods能夠被系統(tǒng)內(nèi)的其他組件發(fā)現(xiàn)并訪問。簡單來說，Service提供了一種讓客戶端能夠穩(wěn)定地連接到后端Pods的機(jī)制，即使這些Pods會(huì)動(dòng)態(tài)地創(chuàng)建、銷毀或遷移。

Kubernetes Service主要特性和用途

服務(wù)發(fā)現(xiàn)：Service允許客戶端（如Pods中的應(yīng)用程序）通過穩(wěn)定的IP地址和端口號(hào)訪問后端Pods集合，而無需關(guān)心實(shí)際Pod的IP地址或端口號(hào)，因?yàn)檫@些信息可能會(huì)因?yàn)镻od的重啟或遷移而改變。

負(fù)載均衡：Kubernetes會(huì)自動(dòng)在Service后面創(chuàng)建的Pods之間分配進(jìn)入的流量，實(shí)現(xiàn)了簡單的負(fù)載均衡。這意味著當(dāng)多個(gè)Pods提供了相同的服務(wù)時(shí)，客戶端的請求可以被均衡地分發(fā)到這些Pods上。

支持DNS：Kubernetes支持基于DNS的服務(wù)發(fā)現(xiàn)，允許Pods通過服務(wù)名（而不是IP地址）來相互通信。這大大簡化了服務(wù)之間的調(diào)用和依賴關(guān)系的管理。

定義服務(wù)類型：Service可以有多種類型，最常見的是ClusterIP（默認(rèn)，僅集群內(nèi)部可訪問）、NodePort（通過集群中每個(gè)節(jié)點(diǎn)的靜態(tài)端口暴露服務(wù)）、LoadBalancer（在Cloud環(huán)境中，使用云提供商的負(fù)載均衡器暴露服務(wù)）和ExternalName（將服務(wù)映射到DNS名稱，而不是選擇Pods）。

在Kubernetes集群中，kube-proxy作為Service的代理組件，負(fù)責(zé)實(shí)現(xiàn)集群內(nèi)部及外部對Service的訪問。kube-proxy通過監(jiān)聽Kubernetes API Server中的Service和Endpoint資源變化，動(dòng)態(tài)地在每個(gè)節(jié)點(diǎn)上配置網(wǎng)絡(luò)規(guī)則，確保對Service的請求能夠被正確地路由到后端的Pod實(shí)例上。

在iptables 模式下，kube-proxy會(huì)在每個(gè)節(jié)點(diǎn)上通過iptables規(guī)則來實(shí)現(xiàn)請求的轉(zhuǎn)發(fā)。它會(huì)創(chuàng)建一系列的iptables規(guī)則，這些規(guī)則根據(jù)Service的IP和端口，將訪問Service的流量重定向到后端的Pod IP和端口上。這種方式簡單直接，但隨著Service和Pod數(shù)量的增加，iptables規(guī)則會(huì)急劇膨脹，影響性能。

作為iptables的改進(jìn)，ipvs（IP Virtual Server）模式提供了更高的性能和更好的擴(kuò)展性。ipvs使用更高效的哈希表來管理網(wǎng)絡(luò)規(guī)則，可以更快地查找和轉(zhuǎn)發(fā)流量。這使得在大規(guī)模集群中，Service的訪問性能得到顯著提升。

1.2. 問題與挑戰(zhàn)

盡管kube-proxy在大多數(shù)基礎(chǔ)場景中表現(xiàn)良好，但它也存在一些明顯的局限性：

1、場景簡單：kube-proxy主要適用于簡單的網(wǎng)絡(luò)拓?fù)?/a>結(jié)構(gòu)，對于復(fù)雜的IaaS（Infrastructure as a Service）場景，如需要支持VPC（Virtual Private Cloud）網(wǎng)絡(luò)隔離、靈活的EIP（Elastic IP）使用等高級(jí)網(wǎng)絡(luò)功能時(shí)，顯得力不從心。

2、性能瓶頸：由于kube-proxy的報(bào)文轉(zhuǎn)發(fā)完全依賴于軟件實(shí)現(xiàn)（無論是iptables還是ipvs），這意味著它無法利用現(xiàn)代硬件（如DPU、SmartNIC）進(jìn)行網(wǎng)絡(luò)加速，在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)的情況下，這種軟件實(shí)現(xiàn)的性能瓶頸尤為明顯。

3、資源消耗：基于軟件實(shí)現(xiàn)的Kubernetes Service，在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)的情況下會(huì)導(dǎo)致CPU資源消耗過高，從而影響整體系統(tǒng)的穩(wěn)定性和性能。

與kube-proxy相似，許多開源的容器網(wǎng)絡(luò)接口（CNI）插件，如使用Open vSwitch（OVS）的kube-ovn、Antrea等，通常依賴于自己的數(shù)據(jù)面處理機(jī)制來轉(zhuǎn)發(fā)Service網(wǎng)絡(luò)流量，在沒有硬件加速的情況下，也面臨類似的性能瓶頸和資源消耗問題。

2. 方案介紹

2.1.?整體架構(gòu)

本方案基于DPU&SmartNIC實(shí)現(xiàn)了Kubernetes Service的解決方案，簡稱“馭云Service”。

馭云Service在馭云SDN的架構(gòu)中實(shí)現(xiàn)，其中馭云SDN通過ovn/ovs機(jī)制將DPU&SmartNIC加入到同一個(gè)ovn集群，對網(wǎng)絡(luò)進(jìn)行統(tǒng)一的虛擬化，整體物理架構(gòu)圖如所示:

在Pod/裸機(jī)/VM接入DPU卡或SmartNIC卡后，用戶的請求由Service處理后送往對應(yīng)的Pod/裸機(jī)/VM。

軟件整體架構(gòu)如下：

如圖所示，馭云Service基于馭云SDN，上圖各個(gè)組件中均會(huì)參與處理Service的邏輯，下面分別進(jìn)行介紹：

ycloud-controller，是SDN系統(tǒng)的控制平面，處理Service的主要邏輯，將用戶創(chuàng)建的Service數(shù)據(jù)通過ovn轉(zhuǎn)換成實(shí)際的網(wǎng)絡(luò)拓?fù)洹?/p>

yusurService-controller，處理用戶創(chuàng)建的YusurService資源，翻譯成內(nèi)置Service資源給ycloud-controller使用。

ycloud-cni，該組件作為一個(gè)DaemonSet運(yùn)行在每個(gè)節(jié)點(diǎn)上，是SDN的CNI接口，同時(shí)也會(huì)負(fù)責(zé)各個(gè)節(jié)點(diǎn)上Service的一些處理邏輯。

注：馭云SDN參見《基于DPU&SmartNIC的云原生SDN解決方案》

2.2.?方案描述

在馭云SDN的概念中，所有后端資源，無論是Pod、VM還是裸金屬服務(wù)器，都屬于某一個(gè)VPC（虛擬私有云）。VPC實(shí)現(xiàn)了邏輯隔離的網(wǎng)絡(luò)空間，這意味著不同VPC內(nèi)的網(wǎng)絡(luò)流量不會(huì)相互干擾，這提供了重要的安全邊界，同時(shí)也便于多租戶環(huán)境中的資源管理和隔離。然而，這種隔離也帶來了一個(gè)挑戰(zhàn)：如何允許不同VPC之間或者外部網(wǎng)絡(luò)訪問這些VPC內(nèi)的資源。

Service需要解決的就是從不同地方經(jīng)過Service訪問到這些VPC內(nèi)的資源，并且根據(jù)策略進(jìn)行請求的負(fù)載均衡。在馭云Service中，具體包含以下場景：

集群內(nèi)部互通（ClusterIP類型Service）

場景①：客戶端在集群VPC內(nèi)，訪問同VPC下的后端服務(wù)：

在這種情況下，客戶端可以直接通過Service的ClusterIP訪問后端服務(wù)。ClusterIP是一種虛擬IP地址，由Kubernetes為Service分配，只在集群內(nèi)部可見。流量在VPC內(nèi)直接轉(zhuǎn)發(fā)，無需經(jīng)過額外的網(wǎng)關(guān)或負(fù)載均衡器。

場景②：客戶端在集群節(jié)點(diǎn)上，訪問默認(rèn)VPC下的一組后端服務(wù)：

當(dāng)客戶端運(yùn)行在集群節(jié)點(diǎn)上時(shí)，它同樣可以通過ClusterIP訪問服務(wù)。Kubernetes的網(wǎng)絡(luò)策略確保流量在節(jié)點(diǎn)和后端服務(wù)之間正確路由。這種訪問方式同樣限于集群內(nèi)部，不需要EIP。

集群外部訪問集群內(nèi)（LoadBalancer類型Service）

場景③：客戶端在集群外部，通過EIP訪問一個(gè)VPC下的一組后端服務(wù)：

在此場景下，客戶端通過云外訪問集群內(nèi)的服務(wù)。LoadBalancer類型Service會(huì)分配一個(gè)EIP，此時(shí)外部流量通過EIP被路由到集群內(nèi)部的Service。

場景④：客戶端在集群外部，通過EIP訪問多個(gè)VPC下的一組后端服務(wù)：

當(dāng)客戶端需要訪問跨多個(gè)VPC的服務(wù)時(shí)，情況變得復(fù)雜。在這種情況下，當(dāng)外部流量通過EIP進(jìn)入集群內(nèi)Service時(shí)，Servcie會(huì)同時(shí)充當(dāng)網(wǎng)關(guān)，將流量正確地路由到目標(biāo)VPC。

本方案主要從控制面和數(shù)據(jù)面2各方面進(jìn)行介紹。

2.2.1. 控制面

在控制層，我們對原生Service進(jìn)行了封裝，在Kubernetes基礎(chǔ)上擴(kuò)展了對Service的管理能力，整體控制面結(jié)構(gòu)如下圖所示：

Service和Endpoint是Kubernetes內(nèi)置資源。資源Service定義了構(gòu)造一個(gè)Service的基本信息。

由于內(nèi)置資源無法滿足我們需要功能，包括網(wǎng)絡(luò)訪問場景，和多種后端，于是馭云Service增加了YusurService與NetworkProbe兩種自定義資源定義（CRDs）：

YusurService: 一種擴(kuò)展的Service概念，允許定義更廣泛的后端資源，包括Pod、VM、BM（裸金屬服務(wù)器）、VNicIP（虛擬網(wǎng)絡(luò)接口IP）。通過使用選擇器（selectors），可以靈活地匹配不同類型的后端資源，而不僅僅是Pod。支持定義多種網(wǎng)絡(luò)場景，靈活的指定eip和clusterIP等。

NetworkProbe: 用于健康檢查的新CRD，為每個(gè)后端資源生成相應(yīng)的探針，實(shí)時(shí)監(jiān)控其健康狀態(tài)。這可以確保負(fù)載均衡器只將請求轉(zhuǎn)發(fā)給健康的實(shí)例。

用戶只需要和YusurService進(jìn)行交互，yusurService-controller會(huì)根據(jù)YusurService的信息創(chuàng)建Networkprobe，Endpoint和Service這3種資源。

Service包含網(wǎng)絡(luò)配置的大多基本信息，Endpoint資源包含本次配置的所有后端；Networkprobe返回后端健康檢查結(jié)果，yusurService-controller會(huì)根據(jù)Networkprobe的返回結(jié)果調(diào)整Endpoint所包含的健康后端。

yscloud-controller則會(huì)根據(jù)Endpoint和Service的信息通過ovn繪制出整個(gè)網(wǎng)絡(luò)拓?fù)洌蛲ňW(wǎng)絡(luò)通路。

通過這樣的架構(gòu)，系統(tǒng)不僅提供了高級(jí)別的抽象來簡化Service管理和后端資源的健康監(jiān)控，還實(shí)現(xiàn)了跨VPC的負(fù)載均衡，增強(qiáng)了Kubernetes集群的網(wǎng)絡(luò)功能。

2.2.2. 數(shù)據(jù)面

Service的數(shù)據(jù)面依賴OVN和OpenVswitch，根據(jù)不同的訪問場景，在不同的地方配置Load_Balancer，Load_Balancer是OVN的邏輯概念，可以應(yīng)用在OVN的邏輯交換機(jī)或者邏輯路由器上面，它將在對應(yīng)的地方上配置DNAT的規(guī)則，將訪問VIP的報(bào)文轉(zhuǎn)到合適的后端上去。

下文分別針對控制面中所描述的4種Service使用場景進(jìn)行說明。

2.2.2.1 同vpc下訪問資源

當(dāng)創(chuàng)建了Service之后，LoadBalancer的網(wǎng)絡(luò)策略會(huì)確保應(yīng)用在vpc1內(nèi)的所有Subnet上。當(dāng)subnet3上的client訪問10.0.0.100時(shí)，其請求將首先被subnet3上的LoadBalancer接收。LoadBalancer會(huì)基于其算法（例如輪詢、最少連接數(shù)等）選擇一個(gè)后端Pod，并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址。數(shù)據(jù)包隨后會(huì)通過vpc1被轉(zhuǎn)發(fā)到選定的Pod所在的Subnet，例如subnet1，最后轉(zhuǎn)發(fā)至Pod1。

2.2.2.2.?從集群節(jié)點(diǎn)上訪問vpc內(nèi)資源

當(dāng)集群節(jié)點(diǎn)上的client訪問10.0.0.100時(shí)，報(bào)文經(jīng)過node-interface進(jìn)入subnet0，經(jīng)過LoadBalancer將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址后，通過ovn-cluster到對應(yīng)subnet，完成一次轉(zhuǎn)發(fā)。

2.2.2.3.從集群外部訪問同一個(gè)vpc內(nèi)資源

當(dāng)創(chuàng)建了Service之后，LoadBalancer的網(wǎng)絡(luò)策略會(huì)應(yīng)用在vpc1上，當(dāng)client訪問200.0.0.100時(shí)，其請求將首先被這個(gè)EIP子網(wǎng)所屬的eipGateway接收。eipGateway會(huì)將報(bào)文路由到Servic所屬的VPC，vpc1內(nèi)，此時(shí)LoadBalancer規(guī)則會(huì)基于其算法（例如輪詢、最少連接數(shù)等）選擇一個(gè)后端Pod，并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址。數(shù)據(jù)包隨后會(huì)通過vpc1被轉(zhuǎn)發(fā)到選定的Pod，完成一次轉(zhuǎn)發(fā)。

2.2.2.4.從集群外部訪問多個(gè)vpc內(nèi)資源

當(dāng)創(chuàng)建了Service之后，控制器會(huì)創(chuàng)建一個(gè)service-gateway的邏輯路由器，LoadBalancer的網(wǎng)絡(luò)策略會(huì)應(yīng)用在該路由器上，當(dāng)client訪問200.0.0.100時(shí)，其請求將首先被這個(gè)eip子網(wǎng)所屬的eipGateway接收。eipGateway會(huì)將報(bào)文路由到service-gateway上，此時(shí)LoadBalancer規(guī)則會(huì)基于其算法（例如輪詢、最少連接數(shù)等）選擇一個(gè)后端Pod，并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址，源地址轉(zhuǎn)換為所選service-gateway的系統(tǒng)IP地址。數(shù)據(jù)包隨后會(huì)被轉(zhuǎn)發(fā)到選定的Pod的vpc上，然后vpc將數(shù)據(jù)包送到Pod，完成一次轉(zhuǎn)發(fā)。

3. 方案測試結(jié)果

3.1.?創(chuàng)建Service

創(chuàng)建一個(gè)帶有特定選擇器和端口映射的Service YAML文件ysvc1.yaml，如下：

使用kubectl apply -f ysvc1.yaml命令創(chuàng)建Service。

使用kubectl get ysvc ysvc1檢查Service，如下：

訪問Service clusterIP，訪問成功。

圖中的netns為service后端同vpc下的一個(gè)pod，10.233.46.185為service的clusterIP，5001是service暴露的端口。

3.2.?性能對比

3.2.1 Pod的帶寬

帶寬單位Gbits/s。

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.?????? 卸載模式下，馭云訪問遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的帶寬。

2.?????? 卸載模式比非卸載在帶寬上性能提升了20%左右。

3.2.2 Pod的pps

pps單位為Mpps。

從下面數(shù)據(jù)得出以下結(jié)論：

1.?????? 卸載模式下，馭云訪問遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的60%pps。

2.?????? 卸載模式比非卸載在pps上性能提升了2倍以上。

3.2.3 Pod的延時(shí)

延時(shí)單位為us。

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.?????? 卸載模式下，馭云訪問遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的延遲。

2.?????? 卸載模式比非卸載在延遲上降低了20%以上。

3.2.4 RPS

單位為Requests/s。

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.?????? 卸載模式下，馭云訪問遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的rps。

2.?????? 卸載模式比非卸載在rps上提升了40%左右。

3.2.5 每條request的CPU指令數(shù)以及CPI

每條request的CPU指令數(shù)，單位為instructions/request。

CPI，單位為cycles/instruction。

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.?????? 一個(gè)請求消耗的CPU指令數(shù)量，卸載模式比非卸載模式降低30%左右。

2.?????? 在CPI方面，卸載模式比非卸載模式增大了15%左右。

3.?????? 綜合消耗的CPU指令數(shù)量來看，對CPU的消耗減少了25%左右。

4. 優(yōu)勢總結(jié)

基于DPU和SmartNIC的K8s Service解決方案展現(xiàn)出顯著的優(yōu)勢，具體總結(jié)如下：

① 支持復(fù)雜網(wǎng)絡(luò)拓?fù)渑c高級(jí)功能

在復(fù)雜的網(wǎng)絡(luò)拓?fù)湎聦?shí)現(xiàn)K8s Service，支持VPC網(wǎng)絡(luò)隔離和EIP等高級(jí)網(wǎng)絡(luò)功能，大大增強(qiáng)了Kubernetes集群在IaaS環(huán)境中的網(wǎng)絡(luò)靈活性和安全性，滿足復(fù)雜場景下的網(wǎng)絡(luò)需求。

② 顯著提升K8s Service性能

根據(jù)測試數(shù)據(jù)，本方案在帶寬上性能提升了20%左右，pps上性能提升了2倍以上，延遲降低了20%以上。DPU和SmartNIC內(nèi)置了強(qiáng)大的網(wǎng)絡(luò)處理引擎，能夠直接在硬件上完成報(bào)文的解析、轉(zhuǎn)發(fā)和路由決策等任務(wù)，這種硬件加速機(jī)制使得在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)時(shí)，仍能保持低延遲和高吞吐量，顯著提升了Kubernetes Service的性能。

③ 降低資源消耗與優(yōu)化系統(tǒng)性能

根據(jù)測試數(shù)據(jù)，本方案對CPU的消耗減少了25%左右。由于DPU和SmartNIC承擔(dān)了大部分的網(wǎng)絡(luò)處理工作，CPU從繁重的網(wǎng)絡(luò)轉(zhuǎn)發(fā)任務(wù)中解放出來，可以專注于執(zhí)行其他更關(guān)鍵的計(jì)算任務(wù)，這不僅降低了CPU的資源消耗，還提升了整體系統(tǒng)的穩(wěn)定性和性能。

綜上所述，基于DPU和SmartNIC的K8s Service解決方案在應(yīng)對復(fù)雜網(wǎng)絡(luò)拓?fù)洹⑿阅芷款i和資源消耗等方面具有明顯的優(yōu)勢，能夠顯著提升Kubernetes集群在復(fù)雜IaaS環(huán)境中的網(wǎng)絡(luò)性能和整體穩(wěn)定性。

本方案來自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專家組成，不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，還對行業(yè)趨勢具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時(shí)降低運(yùn)營成本。