性能提升40%: 騰訊 TKE 用 eBPF 繞過 conntrack 優化 K8s Service-有解無憂

Kubernetes Service 用于實作集群中業務之間的互相呼叫和負載均衡，目前社區的實作主要有userspace，iptables和IPVS三種模式，IPVS模式的性能最好，但依然有優化的空間，該模式利用IPVS內核模塊實作DNAT，利用nf_conntrack/iptables實作SNAT，nf_conntrack是為通用目的設計的，其內部的狀態和流程都比較復雜，帶來很大的性能損耗，

騰訊云 TKE 團隊開發了新的IPVS-BPF模式，完全繞過nf_conntrack的處理邏輯，使用eBPF完成SNAT功能，對最常用的POD訪問ClusterIP場景，短連接性能提升40%，p99時延降低31%；NodePort場景提升更多，詳情見下表和性能測量章節，

'IPVS-BPF優化效果總覽4.png'

一、容器網路現狀

iptables模式

存在的問題：

1．可擴展性差，隨著service資料達到數千個，其控制面和資料面的性能都會急劇下降，原因在于iptables控制面的介面設計中，每添加一條規則，需要遍歷和修改所有的規則，使得其控制面性能是O(n2)，在資料面，規則是用鏈表組織的，使得其資料面的性能是O(n)，

2．LB調度演算法僅支持隨機轉發，

IPVS模式

IPVS 是專門為LB設計的，它用hash table管理service，對service的增刪查找都是O(1)的時間復雜度，不過IPVS內核模塊沒有SNAT功能，因此借用了iptables的SNAT功能，IPVS 針對報文做DNAT后，將連接資訊保存在nf_conntrack中，iptables據此接力做SNAT，該模式是目前Kubernetes網路性能最好的選擇，但是由于nf_conntrack的復雜性，帶來了很大的性能損耗，

二、IPVS-BPF方案介紹

eBPF 介紹

eBPF是Linux內核中軟體實作的虛擬機，用戶把eBPF程式編譯為eBPF指令，然后通過bpf()系統呼叫將eBPF指令加載到內核的特定掛載點，由特定的事件來觸發eBPF指令的執行，在掛載eBPF指令時內核會進行充分驗證，避免eBPF代碼影響內核的安全和穩定性，另外內核也會進行JIT編譯，把eBPF指令翻譯為本地指令，減少性能開銷，

內核在網路處理路徑上中預置了很多eBPF的掛載點，例如xdp, qdisc, tcp-bpf, socket等，eBPF程式可以加載到這些掛載點，并呼叫內核提供的特定API來修改和控制網路報文，eBPF程式可以通過map資料結構來保存和交換資料，

基于eBPF的IPVS-BPF優化方案

針對nf_conntrack帶來的性能問題，騰訊TKE團隊設計實作了IPVS-BPF，核心思想是繞過nf_conntrack，減少處理每個報文的指令數目，從而節約CPU，提高性能，其主要邏輯如下:

在IPVS內核模塊中引入開關，支持原生IPVS邏輯和IPVS-BPF邏輯的切換
在IPVS-BPF模式下，將IPVS hook點從LOCALIN前移到PREROUTING，使訪問service的請求繞過nf_conntrack
在IPVS新建連接和洗掉連接的代碼中，相應的增刪eBPF map中的session資訊
在qdisc掛載eBPF的SNAT代碼，根據eBPF map中的session資訊執行SNAT

此外，針對icmp, fragmentation均有專門處理，詳細背景和細節，會在后續的QCon在線會議上介紹，歡迎一起探討，

優化前后報文處理流程的對比

'bpf-process.png'

可以看到，報文處理流程得到了極大簡化，

為什么不直接采用全eBPF方式

很多讀者會問，為什么還要用IPVS模塊跟eBPF相結合，而不是直接使用eBPF把Service功能都實作了呢？

我們在設計之初也仔細研究了這個問題, 主要有以下幾點考慮：

nf_conntrack對CPU指令和時延的消耗，大于IPVS模塊，是轉發路徑的頭號性能殺手，而IPVS本身是為高性能而設計的，不是性能瓶頸所在
IPVS有接近20年的歷史，廣泛應用于生產環境，性能和成熟度都有保障
IPVS內部通過timer來維護session表的老化，而eBPF不支持timer, 只能通過用戶空間代碼來協同維護session表
IPVS支持豐富的調度策略，用eBPF來重寫這些調度策略，代碼量大不說，很多調度策略需要的回圈陳述句，eBPF也不支持

我們的目標是實作代碼量可控，能落地的優化方案，基于以上考慮，我們選擇了復用IPVS模塊，繞過nf_conntrack，用eBPF完成SNAT的方案，最終資料面代碼量為：500+行BPF代碼， 1000+行IPVS模塊改動（大部分為輔助SNAT map管理的新增代碼），

三、性能測量

本章節通過量化分析的方法，用perf工具讀取CPU性能計數器，從微觀的角度解釋宏觀的性能資料，本文采用的壓測程式是wrk和iperf，

測驗環境

復現該測驗需要注意兩點：

不同的集群和機器，即使機型都一樣，也可能因為各自母機和機架的拓撲不同，造成性能資料有背景差異，為了減少這類差異帶來的誤差，我們對比IPVS模式和IPVS-BPF模式時，是使用同一個集群，同樣一組后端Pod, 并且使用同一個LB節點，先在IPVS模式下測出IPVS性能資料，然后把LB節點切換到IPVS-BPF模式, 再測出IPVS-BPF模式的性能資料，(注：切換模式是通過后臺把控制面從kube-proxy切換為kube-proxy-bpf來實作的，產品功能上并不支持這樣在線切換)
本測驗的目標是測量LB上軟體模塊優化對于訪問service性能的影響，不能讓客戶端和RS目標服務器的帶寬與CPU成為瓶頸，所以被壓測的LB節點采用1核機型，不運行后端Pod實體；而運行后端服務的節點采用8核機型

NodePort

'nodeport-testbed.png'

為了采集CPI等指標，這里LB節點(紅色部分)采用黑石裸金屬機器，但通過hotplug只打開一個核，關閉其余核，

ClusterIP

'clusterip-testbed.png'

這里LB節點(左邊的Node)采用SA2 1核1G機型，

測量結果

'nodeport短連接cps.png'

'clusterip短連接cps.png'

IPVS-BPF模式相對IPVS模式，Nodeport短連接性能提高了64%，clusterIP短連接性能提高了40%，

NodePort優化效果更明顯，是因為NodePort需要SNAT，而我們的eBPF SNAT比iptables SNAT更高效，所以性能提升更多，

'nodeport-iperf.png'

如上圖所示，iperf帶寬測驗中IPVS-BPF模式相對IPVS mode性能提升了22%，

'nodeport-latency.png'

上圖中，wrk測驗表明nodePort service 短連接p99延遲降低了47%.

'clusterip-latency.png'

上圖中，wrl測驗表明clusterIP service短連接的p99延遲降低了31%，

指令數和CPI

'nodeport-inst-per-req.png'

上圖中從Perf工具看，平均每個請求耗費的CPU指令數, IPVS-BPF模式下降了38%，這也是性能提升的最主要原因，

'nodeport-cpi.png'

IPVS-BPF 模式下CPI略有增加，大概16%，

測驗總結

Service型別	短連接cps	短連接p99延遲	長連接吞吐
clusterIP	+40%	-31%	無，見下文
nodePort	+64%	-47%	+22%

如上表，IPVS-BPF模式相對原生IPVS模式，Nodeport處理短連接性能提升了64%，p99延遲降低了47%，處理長連接帶寬提升了22%；ClusterIP處理短連接吞吐量提升了40%, p99延遲降低了31%，

測驗ClusterIP長連接吞吐時，iperf本身消耗了99% 的CPU，使得優化效果不容易直接測量，另外我們還發現IPVS-BPF模式下CPI有增加，值得進一步研究，

四、其他優化，特性限制和后續作業

在開發IPVS-BPF方案程序中，順便解決或優化了一些其他問題

conn_reuse_mode = 1時新建性能低以及no route to host問題

這個問題是當client發起大量新建TCP連接時，新的連接被轉發到terminating的pod上，導致持續丟包，此問題在IPVS conn_reuse_mode=1的情況下不會有，但是conn_reuse_mode=1時，有另外的新建連接性能急劇下降的bug, 故一般都設定成了conn_reuse_mode=0，我們在TencentOS內核中徹底修復了該問題，代碼在ef8004f8, 8ec35911, 07a6e5ff63同時也正在向內核社區提交修復，
DNS決議偶爾5s延時

iptables SNAT分配lport到呼叫插入nf_conntrack，這中間是采用樂觀鎖機制，這中間如果發生競爭，相同的lport和五元組同時插入nf_conntrack會導致丟包，在IPVS-BPF模式下，SNAT選擇lport的程序和插入hash table的程序在同一個回圈中，回圈次數最大為5次，從而減少了該問題的概率，
externalIp優化造成clb健康檢查失敗問題

詳情見： https://github.com/kubernetes/kubernetes/issues/79783#issuecomment-509007864