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

前言

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

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

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

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

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

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

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

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

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

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

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

性能對比

本文使用wrk工具對Cilium的產品化解決方案進行了性能壓測，測試保證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的場景。

產品化過程中的相關問題

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

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

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

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

Cilium加載bpf程序的名字缺失

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

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

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

用法

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

總結與展望

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

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

參考資料

[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] 騰訊云容器服務TKE推出新一代零損耗容器網(wǎng)絡