從編譯到可執行，eBPF 加速容器網路的原理分析 | 龍蜥技術

編者按：eBPF(extended Berkeley Packet Filter) 是一種可以在 Linux 核心中執行使用者編寫的程式，而不需要修改核心程式碼或載入核心模組的技術。簡單說，eBPF 讓 Linux 核心變得可程式設計化了。本文整理自 龍蜥大講堂第 57 期，浪潮資訊 SE 王傳國從原理上分析了 eBPF 的載入工作過程，解釋了它如何保證系統執行穩定以及它能加速網路的原因。

01 eBPF 載入過程

我們知道，一般 eBPF 的載入過程，首先是寫 C 程式碼，然後用 llvm lang 編譯成 ELF 檔案，接著用 libelf 對 ELF 檔案進行解析，解析之後按照 libbpf 所需要的格式進行資料的整理、組織，再透過 BPF 的系統呼叫，可以將這些資料都載入到核心裡面，包括程式翻譯出來的 eBPF 指令集。

在核心裡面有校驗器負責對程式進行校驗，有 JIT 對程式進行翻譯解析。

1.1 重定位

BPF 基礎設施提供了一組有限的“穩定介面”， 使用 convert_ctx_access 對各種 CTX 進行轉換，在核心版本升級時保證穩定。

CO-RE 核心思想就是採用(BTF)非硬編碼的形式對成員在結構中的偏移位置進行描述，解決不同版本之間的差異。

需要重定位的元素：Map、函式呼叫、Helper函式呼叫、欄位、Extern 核心符號和kconfig。

1.2 安全性檢查：資料、指令、迴圈

數學計算除數不能為 0，指令呼叫範圍[0, prog->len)深度優先遍歷排除環。

1.3 eBPF 指令集

1.4 指標安全性檢查

確定指標型別、範圍糾正，識別不了的指標型別不允許引用。

範圍檢查，不同的指標型別有不同的檢查方法和範圍。

02 eBPF 加速容器網路

主要涉及的 eBPF 程式型別：XDP、tc、sock_ops。

它們加速網路效能的基本原理都是把資料直接從一端（網口/socket）的傳送佇列傳遞到另一端的接收或傳送佇列，繞過不需要的網路協議棧。

XDP 位於整個 Linux 核心網路軟體棧的底部，還未生成 skb，能夠非常早地識別並丟棄攻擊報文，具有很高的效能；但是在虛擬機器中有時候可能無法支援 XDP 程式的載入，例如虛擬機器網路卡的接收佇列太少。

在 tc 功能的 sch_handle_ingress、sch_handle_egress 新增 hook 點，分別是 tc ingress 和 tc egress，沒有 XDP 那麼多要求，基本上所有的 OS 中都能使用，繞過 netfilter 等非必要的核心網路協議棧路徑，能極大地提升網路效能，降低延遲。

技術概述：把資料從一端 socket 傳送佇列直接傳送到對端 socket 的接收佇列或傳送佇列。

sockops：掛載到cgroup，監控整個 cgroup 中所有 socket 的握手和揮手（主動|被動），記錄 tcp 連線。

sockmap：儲存資料特徵與 socket 控制程式碼的關係。寫資料時執行 bpf_map_update，修改對應 socket 的 sendmsg 函式指標。

sk_msg：使用 sockmap 對資料進行 redirect 判定。

經過我們的測試，如果用 Cilium 替換 calico，用 TCP Throughput 模式測，那麼 pod 間的通訊效能 tcp 吞吐量提升 58%、sockops 提升 153%、跨節點也能提升 24%。

如果用 TCP-RR 模式來測，那麼相比 calico 同節點能提升 28%、sockops 提升200.82%、跨節點提升 43%。

如果用 TCP_CRR 模式去測的話， calico 同節點能提升40%、sockops 提升 35% 、跨節點提升 55%。

Cilium 在提升效能的時候，它對於 CPU 的佔用降低了 10% 以上，因此我們測試的結果是 Cilium 的效能要明顯優於使用 iptables 的 calico。所以說目前我們打算使用 Cilium 最佳化我們的容器網路。

關於直播課件及影片回放獲取方式可移步龍蜥公眾號（OpenAnolis龍蜥）2023年1月4日相同推送檢視。

—— 完 ——