隨著G行應(yīng)用上全棧云越來(lái)越多，云上應(yīng)用的需求也越發(fā)變得多樣，對(duì)網(wǎng)絡(luò)、安全、可觀測(cè)性等各類需求也逐漸從傳統(tǒng)面向"點(diǎn)、線"的場(chǎng)景轉(zhuǎn)向了"面、分布式"的場(chǎng)景，對(duì)云上很多領(lǐng)域而言，eBPF這種新技術(shù)能提供簡(jiǎn)單、便捷、快速的手段來(lái)實(shí)現(xiàn)各類工具、服務(wù)。本文對(duì)eBPF的概念、主要使用場(chǎng)景、使用方式進(jìn)行了簡(jiǎn)單介紹，并結(jié)合全棧云實(shí)際運(yùn)維場(chǎng)景對(duì)eBPF技術(shù)進(jìn)行了實(shí)踐，拋磚引玉。

一、eBPF基本概念

傳統(tǒng)BPF工作方式: 基于事件驅(qū)動(dòng)的框架，用戶使用BPF虛擬機(jī)指令集（RISC精簡(jiǎn)指令集）定義過(guò)濾規(guī)則，然后傳遞給kernel再進(jìn)行JIT即時(shí)編譯成CPU原生指令，在事件被觸發(fā)時(shí)執(zhí)行。通過(guò)這種在kernel層實(shí)行過(guò)濾的方式，降低用戶層定義的過(guò)濾成本，提升包過(guò)濾性能。傳統(tǒng)的tcpdump就是這種過(guò)濾方式。

eBPF是在研究軟件定義網(wǎng)絡(luò)方案時(shí)擴(kuò)展出來(lái)的技術(shù)，使BPF擴(kuò)展成為了一個(gè)更通用的虛擬機(jī)，仍然是基于事件驅(qū)動(dòng)的框架。eBPF patch在2014年3月開(kāi)始合入kernel主分支中，JIT組件在2014年發(fā)布的Linux 3.15版本中被合入，應(yīng)用層控制BPF程序的bpf系統(tǒng)調(diào)用在Linux 3.18中被合入，接下來(lái)的Linux 4.x版本系列中添加了eBPF支持kprobes,uprobes,tracepoints和perf_events等事件類型。

eBPF相比傳統(tǒng)BPF技術(shù)，寄存器從32位擴(kuò)展到64位，寄存器數(shù)量也擴(kuò)展到10個(gè)以上，擴(kuò)展了map技術(shù)實(shí)現(xiàn)內(nèi)核態(tài)與用戶態(tài)共享存儲(chǔ)空間用于高效讀取數(shù)據(jù)，并從包過(guò)濾事件類型擴(kuò)展到動(dòng)態(tài)插樁內(nèi)核函數(shù)、靜態(tài)插樁內(nèi)核函數(shù)、用戶函數(shù)插樁、性能監(jiān)控、安全等領(lǐng)域。當(dāng)前BPF名稱默認(rèn)即指eBPF。

二、eBPF內(nèi)部工作機(jī)制示意圖

圖1 eBPF工作示意圖

主要過(guò)程：

• 用戶編寫eBPF代碼，并使用LLVM、GCC等把代碼編譯成eBPF字節(jié)碼；
• 用戶態(tài)程序或工具通過(guò)bpf系統(tǒng)調(diào)用加載eBPF字節(jié)碼到kernel中；
• 內(nèi)核驗(yàn)證器驗(yàn)證字節(jié)碼是否合規(guī)、安全，確保不會(huì)造成kernel異常，驗(yàn)證通過(guò)后，內(nèi)核中的JIT即時(shí)編譯器把字節(jié)碼翻譯成CPU原生指令并加載到對(duì)應(yīng)的事件接口；

當(dāng)內(nèi)核中對(duì)應(yīng)事件被觸發(fā)時(shí)，執(zhí)行被加載的CPU原生指令，分析數(shù)據(jù)放入map共享區(qū)供用戶態(tài)程序使用。

三、eBPF重要應(yīng)用場(chǎng)景

1. eBPF定義網(wǎng)絡(luò)

在與Linux Kernel解耦的同時(shí)，通過(guò)eBPF可編程性及高效處理可以在Linux內(nèi)核包處理上下文中動(dòng)態(tài)添加處理邏輯，包括過(guò)濾、流量控制、轉(zhuǎn)發(fā)、執(zhí)行路徑優(yōu)化、協(xié)議解析等幾乎任意操作，同時(shí)以近似于本地編譯的內(nèi)核代碼效率執(zhí)行。比如Linux內(nèi)核XDP（快速數(shù)據(jù)路徑）框架，通過(guò)在框架中掛載eBPF程序后，可實(shí)現(xiàn)三層路由轉(zhuǎn)發(fā)、四層負(fù)載均衡、分布式防火墻、訪問(wèn)控制ACL等功能定制，可以編寫eBPF程序掛載到網(wǎng)卡驅(qū)動(dòng)層直接處理網(wǎng)絡(luò)流量，繞過(guò)Linux Kernel，進(jìn)而可以使用專用的網(wǎng)絡(luò)處理器（NPU）進(jìn)行網(wǎng)絡(luò)流量處理，釋放CPU資源。開(kāi)源社區(qū)比較典型的有facebook開(kāi)源的Katran四層負(fù)載均衡器等。騰訊使用Cilium作為TKE底層引擎，阿里云使用eBPF技術(shù)實(shí)現(xiàn)CNI網(wǎng)卡。G行全棧云使用的DeepFlow流量采集和分析技術(shù)也使用了eBPF技術(shù)。

2. eBPF定義安全

除了早期基于bpf技術(shù)實(shí)現(xiàn)的內(nèi)核運(yùn)行時(shí)安全計(jì)算模型Seccomp和LSM Linux安全模塊之外，業(yè)界有很多基于eBPF技術(shù)來(lái)高效靈活實(shí)現(xiàn)網(wǎng)絡(luò)安全策略，比如Flacon異常行為檢測(cè)工具；容器網(wǎng)絡(luò)領(lǐng)域的開(kāi)源項(xiàng)目Cilium，重度使用eBPF技術(shù)來(lái)實(shí)現(xiàn)云原生場(chǎng)景下的三層/四層/七層網(wǎng)絡(luò)安全策略等，在不更改應(yīng)用程序代碼或容器配置的情況下能夠發(fā)布和更新 Cilium 安全策略；用于Linux的運(yùn)行時(shí)安全和取證工具Tracee，使用Linux eBPF 技術(shù)在運(yùn)行時(shí)跟蹤系統(tǒng)和應(yīng)用程序，收集事件并分析檢測(cè)可疑行為模式。

3. eBPF可觀測(cè)性和實(shí)時(shí)跟蹤

Netflix公司基于eBPF實(shí)現(xiàn)生產(chǎn)環(huán)境tracing， AWS公司使用eBPF作為RPC觀測(cè)工具，國(guó)內(nèi)互聯(lián)網(wǎng)巨頭字節(jié)跳動(dòng)使用eBPF技術(shù)實(shí)現(xiàn)主機(jī)可觀測(cè)性和ACL訪問(wèn)控制等。

網(wǎng)絡(luò)包全鏈路排查開(kāi)源工具pwru（package where r u）是基于 eBPF 開(kāi)發(fā)的網(wǎng)絡(luò)數(shù)據(jù)包排查工具，提供了完整的細(xì)粒度網(wǎng)絡(luò)數(shù)據(jù)包排查方案 (kernel版本需大于5.5）。

四、 eBPF主要使用方式

1. 使用C語(yǔ)言、Go語(yǔ)言等編程語(yǔ)言編寫原始eBPF程序，實(shí)現(xiàn)邏輯控制、觀測(cè)跟蹤等功能，具體可參考社區(qū)教程。

2. 使用高階封裝工具 BCC編寫eBPF觀測(cè)跟蹤程序。為了降低BPF程序開(kāi)發(fā)門檻，社區(qū)發(fā)起了BCC項(xiàng)目，提供簡(jiǎn)單易用的編寫、加載和運(yùn)行eBPF程序的一個(gè)框架，并可以通過(guò)Python、Lua等腳本語(yǔ)言來(lái)編寫。除此之外還提供了很多現(xiàn)成的用于對(duì)內(nèi)核、CPU、內(nèi)存、調(diào)度、網(wǎng)段等子系統(tǒng)的觀測(cè)跟蹤，參考https://github.com/iovisor/bcc。

3. 使用高階封裝工具bpftrace編寫eBPF觀測(cè)跟蹤程序。通過(guò)命令行就能實(shí)現(xiàn)eBPF性能觀測(cè)工具，更加簡(jiǎn)化eBPF使用，用于追蹤、調(diào)試Linux kernel、了解kernel運(yùn)行機(jī)制非常有用，缺點(diǎn)是不能調(diào)用內(nèi)核函數(shù)或者自定義函數(shù)（此類場(chǎng)景需要使用BCC或C、GO語(yǔ)言開(kāi)發(fā)），可參考https://github.com/iovisor/bpftrace

五、 G行全棧云Caas環(huán)境下eBPF技術(shù)初體驗(yàn)案例一：全棧云hyper主機(jī)ping延時(shí)高

在全棧云某些hyper物理機(jī)上，發(fā)現(xiàn)ping 127.0.0.1延時(shí)高（圖2）

圖2 ping延時(shí)高

通過(guò)perf性能分析工具分別對(duì)正常ping、有ping延時(shí)進(jìn)程分別進(jìn)行trace采樣，制作成火焰圖，分析出耗時(shí)部分。

正常ping（圖3）：

圖3 正常ping火焰圖

異常ping（延時(shí)大，圖4）：

圖4 異常ping火焰圖

在火焰圖里可以看到，相比正常ping，延時(shí)高ping過(guò)程在try_to_wakeup_up()調(diào)用過(guò)程中耗費(fèi)較大。

為了進(jìn)一步搞清ping延時(shí)過(guò)程中try_to_wakeup_up具體是什么情況，編寫bpftrace kprobe類型程序掛載到try_to_wakeup_up內(nèi)核函數(shù)：

#include <linux/sched.h>
kprobe:try_to_wake_up
/ pid == $1 /  
{
   $task = ((struct task_struct *) arg0);
   $pid = $task->pid;
   printf("from %s -> wakeup comm %s pid %d\n", comm, $task->comm, $pid);
 }

用bpftrace執(zhí)行此eBPF程序，監(jiān)控ping進(jìn)程被try_to_wakeup_up的詳細(xì)過(guò)程（圖5）:

圖5 eBPF tracing數(shù)據(jù)

從圖中我們可以看到，在ping的過(guò)程中，try_to_wakeup_up頻繁喚醒isc-socket進(jìn)程，經(jīng)分析，此為dhcpd相關(guān)進(jìn)程，是IaaS層分布式虛擬路由dvr master與client之間的處理邏輯。把dhcpd相關(guān)進(jìn)程遷移到別的機(jī)器后，本機(jī)器上的ping 127.0.0.1延時(shí)恢復(fù)正常。

    從以上案例可以看出，eBPF具備強(qiáng)大的可觀測(cè)性和實(shí)時(shí)跟蹤能力，可以很容易根據(jù)場(chǎng)景定制出合適的trace能力，對(duì)于觀測(cè)定位kernel、進(jìn)程的運(yùn)行邏輯十分便利。

案例二：觀測(cè)收發(fā)包主要過(guò)程耗時(shí)

在全棧云CaaS環(huán)境下，各業(yè)務(wù)以pod的形式運(yùn)行在自己的namespace中，如果不同pod之間通信偶爾抖動(dòng)變慢，如何判斷是網(wǎng)卡、協(xié)議棧、應(yīng)用層等哪個(gè)環(huán)節(jié)出現(xiàn)了問(wèn)題？傳統(tǒng)的tcpdump抓包工具（底層基于了classic bpf庫(kù)）抓包位置在軟中斷從網(wǎng)卡隊(duì)列（ring buffer）中讀取數(shù)據(jù)后發(fā)送給協(xié)議棧的時(shí)候，只能從tcpdump看到sequence數(shù)據(jù)包在網(wǎng)卡接口處收發(fā)的時(shí)間，在正常情況下無(wú)法直觀看到更深層次的延時(shí)原因，比如是內(nèi)核處理延時(shí)還是用戶態(tài)延時(shí)？

如果我們知道veth驅(qū)動(dòng)收發(fā)包關(guān)鍵kernel函數(shù)，以及協(xié)議棧處理與veth驅(qū)動(dòng)的銜接點(diǎn)，就可以編寫eBPF程序掛載到這些關(guān)鍵函數(shù)入口或出口處，在可通過(guò)kprobe或者tracepoint在協(xié)議棧各層的關(guān)鍵函數(shù)中添加hook點(diǎn)，當(dāng)數(shù)據(jù)包經(jīng)過(guò)該函數(shù)時(shí)，打印出seq、network namespace、時(shí)間戳等關(guān)鍵信息，幫助我們快速定位或者縮小問(wèn)題范圍。

本文模擬node節(jié)點(diǎn)某塊虛擬網(wǎng)卡延時(shí)（圖6），此時(shí)node節(jié)點(diǎn)上與pod節(jié)點(diǎn)（與延時(shí)虛擬網(wǎng)卡配對(duì)）如何判斷是網(wǎng)卡慢還是協(xié)議棧處理慢？

圖6 測(cè)試環(huán)境

首先需要分析出此場(chǎng)景下eBPF程序合適的kernel掛載點(diǎn)，基于bpftrace工具編寫eBPF程序并進(jìn)行觀測(cè)跟蹤體驗(yàn)：

1. veth發(fā)送關(guān)鍵內(nèi)核函數(shù)：

__dev_queue_xmit（將數(shù)據(jù)發(fā)送到驅(qū)動(dòng)層）

在該掛載點(diǎn)，獲取tcp四元組信息，獲取tcp sequence，并使用全局變量保存接收時(shí)間（納秒）@rcvpkg[$seq] = nsecs;

2. veth接收關(guān)鍵內(nèi)核函數(shù)：

__netif_receive_skb（將報(bào)文收到協(xié)議棧）

tcp_rcv_state_process（tcp狀態(tài)機(jī)處理函數(shù)）

tcp_rcv_established（tcp establish過(guò)程處理）

選取上面3個(gè)示例掛載點(diǎn)，獲取tcp四元組信息，獲取tcp sequence與當(dāng)前時(shí)間，減去__dev_queue_xmit記錄的起始時(shí)間，就可以得到發(fā)送到接收、協(xié)議棧主要處理函數(shù)耗時(shí)，對(duì)于超過(guò)一定時(shí)間的可以進(jìn)行告警打印。

if( ($seq) == @sequence ){
    $delta = ((nsecs - @rcvpkg[$seq]) / 1000000) % 1000;
    if( $delta >= $1 ){
       time("\n%H:%M:%S   ");
       printf("%-19u %-5s %d,%s,%s,%-10d ", $nsid, $netif, pid, comm, func, cpu);
       printf("flags:%s, seq:%-u, ack:%u, win:%-25u ", $pkgflag, $seq, $ack, $win);
       printf("%s:%-15d  %s:%-15d %d ms\n", $srcip, $sport, $dstip, $dport, (nsecs / 1000000) % 1000);
       printf("Slow pkg: duratinotallow=%u ms, seq=%-u\n", $delta, $seq);
     }
}

模擬網(wǎng)絡(luò)延時(shí)：

tc qdisc add dev vnice9657d91c32 root netem delay 10ms

tc qdisc add dev vnicb8898168feb root netem delay 20ms

在node節(jié)點(diǎn)上執(zhí)行eBPF程序：

bpftrace netpod.bt 5 > tt

在node節(jié)點(diǎn)上執(zhí)行測(cè)試命令：

curl 30.254.10.7:8099;

nsenter -n  -t 20720  telnet 30.254.10.6 22627

eBPF捕獲數(shù)據(jù)如下，可以看出tc設(shè)置的延時(shí)是在xmit發(fā)送時(shí)候產(chǎn)生的，接收方及tcp協(xié)議棧處理耗時(shí)正常（圖7-1,圖7-2）。

圖7-1 eBPF tracing網(wǎng)絡(luò)延時(shí)數(shù)據(jù)

圖7-2 eBPF tracing網(wǎng)絡(luò)延時(shí)數(shù)據(jù)

六、eBPF演進(jìn)趨勢(shì)展望

eBPF技術(shù)像是一個(gè)任意門，可以隨意穿梭到你想去的地方進(jìn)行探索甚至改造，在云時(shí)代大顯身手。Linux kernel面臨不斷增長(zhǎng)的復(fù)雜度、性能、可擴(kuò)展、向后兼容性等需求，需要保持kernel漸進(jìn)式發(fā)展，更多新功能、新特性無(wú)法及時(shí)合并到kernel中。eBPF的內(nèi)核可編程性，既能保證安全，又能在不改變kernel代碼的情況下實(shí)現(xiàn)新功能、新特性的快速應(yīng)用，可為kernel的發(fā)展提供tick-tock迭代新方案，可以想象未來(lái)kernel的發(fā)展極有可能在eBPF技術(shù)基礎(chǔ)上實(shí)現(xiàn)軟件定義kernel。對(duì)于全棧云平臺(tái)而言，可以跟進(jìn)eBPF技術(shù)發(fā)展，研究eBPF適用的應(yīng)用場(chǎng)景，更好支持云上應(yīng)用。