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

1.? 方案背景

1.1. Kubernetes Service介紹

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

Kubernetes Service主要特性和用途

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

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

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

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

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

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

作為iptables的改進，ipvs（IP Virtual Server）模式提供了更高的性能和更好的擴展性。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ò)拓撲結(jié)構(gòu)，對于復(fù)雜的IaaS（Infrastructure as a Service）場景，如需要支持VPC（Virtual Private Cloud）網(wǎng)絡(luò)隔離、靈活的EIP（Elastic IP）使用等高級網(wǎng)絡(luò)功能時，顯得力不從心。

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

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

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

2. 方案介紹

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

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

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

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

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

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

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

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

ycloud-cni，該組件作為一個DaemonSet運行在每個節(jié)點上，是SDN的CNI接口，同時也會負責(zé)各個節(jié)點上Service的一些處理邏輯。

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

2.2.?方案描述

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

Service需要解決的就是從不同地方經(jīng)過Service訪問到這些VPC內(nèi)的資源，并且根據(jù)策略進行請求的負載均衡。在馭云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)或負載均衡器。

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

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

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

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

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

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

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

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

2.2.1. 控制面

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

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

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

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

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

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

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

yscloud-controller則會根據(jù)Endpoint和Service的信息通過ovn繪制出整個網(wǎng)絡(luò)拓撲，打通網(wǎng)絡(luò)通路。

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

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

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

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

2.2.2.1 同vpc下訪問資源

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

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

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

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

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

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

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

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

3.1.?創(chuàng)建Service

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

apiVersion: iaas.yusur.io/v1 kind: YusurService metadata: name: ysvc1 spec: type: ClusterIP scope: vpc vpc: vpc1 ports: - port: 5001 name: iperf protocol: TCP targetPort: 5001 selector: svc: svc1-ep

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

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

訪問Service clusterIP，訪問成功。

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

3.2.?性能對比

3.2.1 Pod的帶寬

帶寬單位Gbits/s。

	測試用例	馭云卸載方案	未卸載方案
1	物理節(jié)點之間基準測試	163	166
2	物理節(jié)點訪問后端在遠端的Service	152	130
3	Pod訪問后端在遠端的Service	151	138

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

1.?????? 卸載模式下，馭云訪問遠端Service能夠達到接近物理機的帶寬。

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

3.2.2 Pod的pps

pps單位為Mpps。

	測試用例	馭云卸載方案	未卸載方案
1	物理節(jié)點之間基準測試	45	45
2	物理節(jié)點訪問后端在遠端的Service	25.5	12.1
3	Pod訪問后端在遠端的Service	24.5	12.2

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

1.?????? 卸載模式下，馭云訪問遠端Service能夠達到接近物理機的60%pps。

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

3.2.3 Pod的延時

延時單位為us。

	測試用例	馭云卸載方案	未卸載方案
1	物理節(jié)點之間基準測試	32	32
2	物理節(jié)點訪問后端在遠端的Service	33	48
3	Pod訪問后端在遠端的Service	33	44

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

1.?????? 卸載模式下，馭云訪問遠端Service能夠達到接近物理機的延遲。

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

3.2.4 RPS

單位為Requests/s。

	測試用例	馭云卸載方案	未卸載方案
1	物理節(jié)點之間基準測試	15999
2	Pod跨節(jié)點訪問Service	15139	11040

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

1.?????? 卸載模式下，馭云訪問遠端Service能夠達到接近物理機的rps。

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

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

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

	測試用例	馭云卸載方案	未卸載方案
	Pod跨節(jié)點訪問Service	122,613	171,405

CPI，單位為cycles/instruction。

	測試用例	馭云卸載方案	未卸載方案
	Pod跨節(jié)點訪問Service	1.94	1.69

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

1.?????? 一個請求消耗的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ù)雜的網(wǎng)絡(luò)拓撲下實現(xiàn)K8s Service，支持VPC網(wǎng)絡(luò)隔離和EIP等高級網(wǎng)絡(luò)功能，大大增強了Kubernetes集群在IaaS環(huán)境中的網(wǎng)絡(luò)靈活性和安全性，滿足復(fù)雜場景下的網(wǎng)絡(luò)需求。

② 顯著提升K8s Service性能

根據(jù)測試數(shù)據(jù)，本方案在帶寬上性能提升了20%左右，pps上性能提升了2倍以上，延遲降低了20%以上。DPU和SmartNIC內(nèi)置了強大的網(wǎng)絡(luò)處理引擎，能夠直接在硬件上完成報文的解析、轉(zhuǎn)發(fā)和路由決策等任務(wù)，這種硬件加速機制使得在高負載跨節(jié)點轉(zhuǎn)發(fā)時，仍能保持低延遲和高吞吐量，顯著提升了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)鍵的計算任務(wù)，這不僅降低了CPU的資源消耗，還提升了整體系統(tǒng)的穩(wěn)定性和性能。

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

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