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

1.? 方案背景

1.1. Kubernetes Service介紹

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

Kubernetes Service主要特性和用途

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

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

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

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

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

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

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

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

盡管kube-proxy在大多數基礎場景中表現良好，但它也存在一些明顯的局限性：

1、場景簡單：kube-proxy主要適用于簡單的網絡拓撲結構，對于復雜的IaaS（Infrastructure as a Service）場景，如需要支持VPC（Virtual Private Cloud）網絡隔離、靈活的EIP（Elastic IP）使用等高級網絡功能時，顯得力不從心。

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

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

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

2. 方案介紹

2.1.?整體架構

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

馭云Service在馭云SDN的架構中實現，其中馭云SDN通過ovn/ovs機制將DPU&SmartNIC加入到同一個ovn集群，對網絡進行統一的虛擬化，整體物理架構圖如所示:

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

軟件整體架構如下：

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

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

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

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

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

2.2.?方案描述

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

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

集群內部互通（ClusterIP類型Service）

場景①：客戶端在集群VPC內，訪問同VPC下的后端服務：

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

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

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

集群外部訪問集群內（LoadBalancer類型Service）

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

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

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

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

本方案主要從控制面和數據面2各方面進行介紹。

2.2.1. 控制面

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

Service和Endpoint是Kubernetes內置資源。資源Service定義了構造一個Service的基本信息。

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

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

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

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

Service包含網絡配置的大多基本信息，Endpoint資源包含本次配置的所有后端；Networkprobe返回后端健康檢查結果，yusurService-controller會根據Networkprobe的返回結果調整Endpoint所包含的健康后端。

yscloud-controller則會根據Endpoint和Service的信息通過ovn繪制出整個網絡拓撲，打通網絡通路。

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

2.2.2. 數據面

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

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

2.2.2.1 同vpc下訪問資源

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

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

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

2.2.2.3.從集群外部訪問同一個vpc內資源

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

2.2.2.4.從集群外部訪問多個vpc內資源

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

3. 方案測試結果

3.1.?創(chuàng)建Service

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

使用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.?????? 卸載模式下，馭云訪問遠端Service能夠達到接近物理機的帶寬。

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

3.2.2 Pod的pps

pps單位為Mpps。

從下面數據得出以下結論：

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

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

3.2.3 Pod的延時

延時單位為us。

從上面測試數據得出以下結論：

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

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

3.2.4 RPS

單位為Requests/s。

從上面測試數據得出以下結論：

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

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

3.2.5 每條request的CPU指令數以及CPI

每條request的CPU指令數，單位為instructions/request。

CPI，單位為cycles/instruction。

從上面測試數據得出以下結論：

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

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

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

4. 優(yōu)勢總結

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

① 支持復雜網絡拓撲與高級功能

在復雜的網絡拓撲下實現K8s Service，支持VPC網絡隔離和EIP等高級網絡功能，大大增強了Kubernetes集群在IaaS環(huán)境中的網絡靈活性和安全性，滿足復雜場景下的網絡需求。

② 顯著提升K8s Service性能

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

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

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

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

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