QPS最高提升91% | 騰訊云TKE基于Cilium eBPF提升k8s Service性能

前言

Kubernetes已經(jīng)成為容器管理領(lǐng)域的事實標準，而網(wǎng)絡(luò)系統(tǒng)是Kubernetes核心部分，隨著越來越多的業(yè)務(wù)部署在Kubernetes，對容器網(wǎng)絡(luò)也提出了一些新的需求

1.怎么提升網(wǎng)絡(luò)的可觀測性，serverless類產(chǎn)品該需求尤為突出

2.怎么盡可能減少容器引入的網(wǎng)絡(luò)性能損耗

上述需求沖擊了iptables，IPVS等傳統(tǒng)防火墻，負載均衡器技術(shù)。也促使我們思考容器網(wǎng)絡(luò)訪問鏈路能否不依賴于節(jié)點，進而縮短容器訪問鏈路，提升網(wǎng)絡(luò)性能

eBPF是一項革命性技術(shù)，它可以以一種安全的方式在內(nèi)核中許多hook點執(zhí)行程序，該項技術(shù)可編程能力強，并且也無需維護內(nèi)核模塊，可維護性好，該項技術(shù)為滿足上述需求提供了可能。Cilium[1]則是基于eBPF技術(shù)的容器網(wǎng)絡(luò)開源項目，提供了網(wǎng)絡(luò)互通，服務(wù)負載均衡，安全和可觀測性等解決方案

由此，騰訊云容器服務(wù)TKE基于Cilium和eBPF實現(xiàn)了獨立網(wǎng)卡模式下的高性能ClusterIP Service方案。TKE致力于提供更高性能、更安全和更易用的容器網(wǎng)絡(luò)，也因此會不斷關(guān)注Cilium等前沿的容器網(wǎng)絡(luò)技術(shù)方案，后續(xù)會推出更多更完善的Cilium產(chǎn)品化能力。

獨立網(wǎng)卡Service方案

TKE于去年推出了新一代容器網(wǎng)絡(luò)方案，該方案實現(xiàn)了一個Pod獨占一張彈性網(wǎng)卡，不再經(jīng)過節(jié)點網(wǎng)絡(luò)協(xié)議棧（default namespace）。而當前的kube-proxy實現(xiàn)ClusterIP的方案都依賴于在節(jié)點側(cè)的網(wǎng)絡(luò)協(xié)議棧里設(shè)置相應(yīng)的iptables規(guī)則，也因此該方案對于獨立網(wǎng)卡方案不再適用。

其中一個解決方案便是Cilium，Cilium提供了基于eBPF的地址轉(zhuǎn)換能力，從而可支持ClusterIP Service。但其原生方案僅支持veth pair和ipvlan l3的數(shù)據(jù)面，并不支持Pod完全不經(jīng)過節(jié)點網(wǎng)絡(luò)協(xié)議棧的數(shù)據(jù)面，因此不能原生解決獨立網(wǎng)卡ClusterIP的訪問問題。

TKE由此對Cilium加以改造，使其支持了除原生支持的veth和ipvlan l3的第三種數(shù)據(jù)面方案，如圖（假設(shè)pod訪問Service IP為172.16.0.2），數(shù)據(jù)面上，將原本掛載到節(jié)點側(cè)的veth上的bpf程序，掛載到pod內(nèi)的獨立網(wǎng)卡（同時也是彈性網(wǎng)卡）上，使得Pod的網(wǎng)絡(luò)報文在發(fā)出的時候做DNAT（目的地址轉(zhuǎn)換），而回報文在網(wǎng)卡接收的時候做反向DNAT，從而支持ClusterIP的訪問。該數(shù)據(jù)面方案可作為一個通用方案適配Ipvlan l2、SRIOV等數(shù)據(jù)面場景。

而控制面上，將Cilium與TKE的VPC-CNI模式（含共享網(wǎng)卡模式和獨立網(wǎng)卡模式）深度集成，用戶無需對業(yè)務(wù)代碼邏輯做任何修改，即可使用Cilium的功能特性。

性能對比

本文使用wrk工具對Cilium的產(chǎn)品化解決方案進行了性能壓測，測試保證Client Pod和Server Pod分布在不同節(jié)點。

測試環(huán)境：TKE集群，4個CVM節(jié)點，配置為Server S5.2XLARGE8，Client S5.SMALL2。

測試數(shù)據(jù)表明，基于Cilium的獨立網(wǎng)卡ClusterIP訪問方案性能最好。在短連接場景下，其QPS相比共享網(wǎng)卡的iptables和ipvs方案提升48%和74%，相比全局路由的iptables和ipvs方案提升了62%和91%。在長連接場景下，其QPS相比共享網(wǎng)卡的iptables和ipvs方案提升了33%和57%，而相比全局路由的iptables和ipvs方案提升了49%和66%。iptables的性能較ipvs性能較好是因為測試環(huán)境中Service數(shù)量還不夠多，ipvs的優(yōu)勢在于大量Service的場景。

產(chǎn)品化過程中的相關(guān)問題

TKE團隊在實現(xiàn)Cilium產(chǎn)品化解決方案過程中，也發(fā)現(xiàn)了Cilium項目中一些問題，相應(yīng)的解決方案和Cilium支持新數(shù)據(jù)面方案將于近日以pr的形式整理提交給Cilium社區(qū)。

獨立網(wǎng)卡方案下的ClusterIP自訪問不通

以上方案其實不能完全解決ClusterIP訪問問題，存在一類特殊的場景會訪問不通。這類場景就是Pod訪問的ClusterIP，其后端包括其自身。這類場景下，獨立網(wǎng)卡的Pod發(fā)出的網(wǎng)絡(luò)報文會直接到達IaaS層，不符合預(yù)期。

由于獨立網(wǎng)卡Pod內(nèi)，其實只有兩個網(wǎng)絡(luò)設(shè)備：回環(huán)設(shè)備（lo）和彈性網(wǎng)卡，因此一個簡單的思路就是在出報文之前，對自訪問流量，通過bpf_redirect調(diào)用將報文直接轉(zhuǎn)發(fā)（redirect）到回環(huán)（lo）設(shè)備?；诖耍琓KE團隊修改了cilium的相關(guān)bpf代碼，提供了一個解決方案。經(jīng)過測試，該方案可以解決獨立網(wǎng)卡方案下的ClusterIP自訪問問題。

Cilium加載bpf程序的名字缺失

Cilium項目的可調(diào)試性存在一個問題，其bpf程序開發(fā)得比較早，底層用了很多老的工具集，例如tc，來加載bpf代碼。

老的tc基于老的內(nèi)核版本(<4.15)設(shè)計的，它在加載bpf程序時，將bpf程序的名字忽略了，導(dǎo)致Cilium加載的bpf程序都是無名字的。這影響了對代碼的理解，追蹤和調(diào)試。

對此TKE團隊結(jié)合較新的內(nèi)核對tc工具進行了修正，使得它加載bpf程序時，會正確的傳入名字。通過這名字，可以搞清楚實際運行的bpf函數(shù)具體是哪一個，從而提高Cilium的可調(diào)試性。

用法

申請Cilium支持ClusterIP產(chǎn)品化內(nèi)測開通后，創(chuàng)建TKE集群時高級設(shè)置中打開ClusterIP增強即可：

總結(jié)與展望

本文介紹了TKE團隊實現(xiàn)的基于Cilium和eBPF的獨立網(wǎng)卡模式下高性能ClusterIP service方案，該方案相比當前基于iptables和ipvs的傳統(tǒng)網(wǎng)絡(luò)方案大量的提升了性能（33%-91%）。

顯然，Cilium提供的能力還不止于此，其基于eBPF這項革命性的技術(shù)，還提供了安全、可觀測性、QoS等方面的能力，而提供更高性能、更安全和更易用的容器網(wǎng)絡(luò)正是TKE的服務(wù)目標，因此，后續(xù)TKE將會積極參與Cilium社區(qū)，與社區(qū)一道共同推出更強大、更完善的容器網(wǎng)絡(luò)能力。

參考資料

[1] Cilium項目官網(wǎng):【https://cilium.io/】

[2] eBPF介紹和參考指南:【https://docs.cilium.io/en/v1.10/bpf/】

[3] Kubernetes Service:【https://kubernetes.io/docs/concepts/services-networking/service/】

[4] 騰訊云容器服務(wù)TKE推出新一代零損耗容器網(wǎng)絡(luò)