在 上篇文章 用了整篇的內(nèi)容來描述網(wǎng)絡(luò)數(shù)據(jù)包在 Kube.NETes 網(wǎng)絡(luò)中的軌跡,文章末尾,我們提出了一種假設(shè):同一個(gè)內(nèi)核空間中的兩個(gè) socket 可以直接傳輸數(shù)據(jù),是不是就可以省掉內(nèi)核網(wǎng)絡(luò)協(xié)議棧處理帶來的延遲?
不論是同 pod 中的兩個(gè)不同容器,或者同節(jié)點(diǎn)的兩個(gè) pod 間的網(wǎng)絡(luò)通信,實(shí)際上都發(fā)生在同一個(gè)內(nèi)核空間中,互為對(duì)端的兩個(gè) socket 也都位于同一個(gè)內(nèi)存中。而在上篇文章的開頭也總結(jié)了數(shù)據(jù)包的傳輸軌跡實(shí)際上是 socket 的尋址過程,可以進(jìn)一步將問題展開:同一節(jié)點(diǎn)上的兩個(gè) socket 間的通信,如果可以 快速定位到對(duì)端的 socket -- 找到其在內(nèi)存中的地址,我們就可以省掉網(wǎng)絡(luò)協(xié)議棧處理帶來的延遲。
互為對(duì)端的兩個(gè) socket 也就是建立起連接的客戶端 socket 和服務(wù)端 socket,他們可以通過 IP 地址和端口進(jìn)行關(guān)聯(lián)。客戶端 socket 的本地地址和端口,是服務(wù)端 socket 的遠(yuǎn)端地址和端口;客戶端 socket 的遠(yuǎn)端地址和端口,則是服務(wù)端 socket 的本地地址和端口。
當(dāng)客戶端和服務(wù)端的完成連接的建立之后,如果可以使用本地地址 + 端口和遠(yuǎn)端地址 + 端口端口的組合 指向socket 的話,僅需調(diào)換本地和遠(yuǎn)端的地址 + 端口,即可定位到對(duì)端的 socket,然后將數(shù)據(jù)直接寫到對(duì)端 socket(實(shí)際是寫入 socket 的接收隊(duì)列 RXQ,這里不做展開),就可以避開內(nèi)核網(wǎng)絡(luò)棧(包括 netfilter/iptables)以及 NIC 的處理。
如何實(shí)現(xiàn)?看標(biāo)題應(yīng)該也猜出來了,這里借助 eBPF 技術(shù)。
eBPF 是什么?
linux 內(nèi)核一直是實(shí)現(xiàn)監(jiān)控/可觀測(cè)性、網(wǎng)絡(luò)和安全功能的理想地方。不過很多情況下這并非易事,因?yàn)檫@些工作需要修改內(nèi)核源碼或加載內(nèi)核模塊, 最終實(shí)現(xiàn)形式是在已有的層層抽象之上疊加新的抽象。eBPF 是一項(xiàng)革命性技術(shù),它能在內(nèi)核中運(yùn)行沙箱程序(sandbox programs), 而無需修改內(nèi)核源碼或者加載內(nèi)核模塊。
將 Linux 內(nèi)核變成可編程之后,就能基于現(xiàn)有的(而非增加新的)抽象層來打造更加智能、 功能更加豐富的基礎(chǔ)設(shè)施軟件,而不會(huì)增加系統(tǒng)的復(fù)雜度,也不會(huì)犧牲執(zhí)行效率和安全性。
應(yīng)用場景
下面截取了 eBPF.io[1] 網(wǎng)站的介紹。
在 網(wǎng)絡(luò) 方面,在不離開內(nèi)核空間的情況下使用 eBPF 可以加快數(shù)據(jù)包處理速度。添加額外的協(xié)議解析器并輕松編寫任何轉(zhuǎn)發(fā)邏輯以滿足不斷變化的需求。
在 可觀測(cè)性 方面,使用 eBPF 可以自定義指標(biāo)的收集和內(nèi)核聚合,以及從眾多來源生成可見性事件和數(shù)據(jù)結(jié)構(gòu),而無需導(dǎo)出樣本。
在 鏈路跟蹤與分析 方面,將 eBPF 程序附加到跟蹤點(diǎn)以及內(nèi)核和用戶應(yīng)用程序探測(cè)點(diǎn),可以提供強(qiáng)大的檢查能力和獨(dú)特的洞察力來解決系統(tǒng)性能問題。
在 安全 方面,將查看和理解所有系統(tǒng)調(diào)用與所有網(wǎng)絡(luò)的數(shù)據(jù)包和套接字級(jí)別視圖相結(jié)合,來創(chuàng)建在更多上下文中運(yùn)行并具有更好控制級(jí)別的安全系統(tǒng)。
事件驅(qū)動(dòng)
eBPF 程序是事件驅(qū)動(dòng)的,當(dāng)內(nèi)核或應(yīng)用程序通過某個(gè) hook(鉤子) 點(diǎn)時(shí)運(yùn)行。預(yù)定義的鉤子類型包括系統(tǒng)調(diào)用、函數(shù)進(jìn)入/退出、內(nèi)核跟蹤點(diǎn)、網(wǎng)絡(luò)事件等。
Linux 的內(nèi)核在系統(tǒng)調(diào)用和網(wǎng)絡(luò)棧上提供了一組 BPF 鉤子,通過這些鉤子可以觸發(fā) BPF 程序的執(zhí)行,下面就介紹常見的幾種鉤子。
- XDP:這是網(wǎng)絡(luò)驅(qū)動(dòng)中接收網(wǎng)絡(luò)包時(shí)就可以觸發(fā) BPF 程序的鉤子,也是最早的點(diǎn)。由于此時(shí)還沒有進(jìn)入內(nèi)核網(wǎng)絡(luò)協(xié)議棧,也未執(zhí)行高成本的操作,比如為網(wǎng)絡(luò)包分配 `sk_buff`[2],所以它非常適合運(yùn)行刪除惡意或意外流量的過濾程序,以及其他常見的 DDoS 保護(hù)機(jī)制。
- Traffic Control Ingress/Egress:附加到流量控制(traffic control,簡稱 tc)ingress 鉤子上的 BPF 程序,可以被附加到網(wǎng)絡(luò)接口上。這種鉤子在網(wǎng)絡(luò)棧的 L3 之前執(zhí)行,并可以訪問網(wǎng)絡(luò)包的大部分元數(shù)據(jù)??梢蕴幚硗?jié)點(diǎn)的操作,比如應(yīng)用 L3/L4 的端點(diǎn)策略、轉(zhuǎn)發(fā)流量到端點(diǎn)。CNI 通常使用虛擬機(jī)以太接口對(duì) veth將容器連接到主機(jī)的網(wǎng)絡(luò)命名空間。使用附加到主機(jī)端 veth 的 tc ingress 鉤子,可以監(jiān)控離開容器的所有流量(當(dāng)然也可以附加到容器的 eth0 接口上)。也可以用于處理跨節(jié)點(diǎn)的操作。同時(shí)將另一個(gè) BPF 程序附加到 tc egress 鉤子,Cilium 可以監(jiān)控所有進(jìn)出節(jié)點(diǎn)的流量并執(zhí)行策略。
上面兩種屬于網(wǎng)絡(luò)事件類型的鉤子,下面介紹同樣是網(wǎng)絡(luò)相關(guān)的,套接字的系統(tǒng)調(diào)用。
- Socket operations:套接字操作鉤子附加到特定的 cgroup 并在套接字的操作上運(yùn)行。比如將 BPF 套接字操作程序附加到 cgroup/sock_ops,使用它來監(jiān)控 socket 的狀態(tài)變化(從 `bpf_sock_ops`[3] 獲取信息),特別是 ESTABLISHED 狀態(tài)。當(dāng)套接字狀態(tài)變?yōu)?ESTABLISHED 時(shí),如果 TCP 套接字的對(duì)端也在當(dāng)前節(jié)點(diǎn)(也可能是本地代理),然后進(jìn)行信息的存儲(chǔ)。或者將程序附加到 cgroup/connect4 操作,可以在使用 ipv4 地址初始化連接時(shí)執(zhí)行程序,對(duì)地址和端口進(jìn)行修改。
- Socket send:這個(gè)鉤子在套接字執(zhí)行的每個(gè)發(fā)送操作上運(yùn)行。此時(shí)鉤子可以檢查消息并丟棄消息、將消息發(fā)送到內(nèi)核網(wǎng)絡(luò)協(xié)議棧,或者將消息重定向到另一個(gè)套接字。這里,我們可以使用其完成 socket 的快速尋址。
Map
eBPF 程序的一個(gè)重要方面是共享收集的信息和存儲(chǔ)狀態(tài)的能力。為此,eBPF 程序可以利用 eBPF Map 的概念存儲(chǔ)和檢索數(shù)據(jù)。eBPF Map 可以從 eBPF 程序訪問,也可以通過系統(tǒng)調(diào)用從用戶空間中的應(yīng)用程序訪問。
Map 有多種類型:哈希表、數(shù)組、LRU(最近最少使用)哈希表、環(huán)形緩沖區(qū)、堆棧調(diào)用跟蹤等等。
比如上面附加到 socket 套接字上用來在每次發(fā)送消息時(shí)執(zhí)行的程序,實(shí)際上是附加在 socket 哈希表上,socket 就是鍵值對(duì)中的值。
輔助函數(shù)
eBPF 程序不能調(diào)用任意內(nèi)核函數(shù)。如果這樣做會(huì)將 eBPF 程序綁定到特定的內(nèi)核版本,并會(huì)使程序的兼容性復(fù)雜化。相反,eBPF 程序可以對(duì)輔助函數(shù)進(jìn)行函數(shù)調(diào)用,輔助函數(shù)是內(nèi)核提供的眾所周知且穩(wěn)定的 API。
這些 輔助函數(shù)[4] 提供了不同的功能:
- 生成隨機(jī)數(shù)
- 獲取當(dāng)前時(shí)間和日期
- 訪問 eBPF Map
- 獲取進(jìn)程/cgroup 上下文
- 操縱網(wǎng)絡(luò)數(shù)據(jù)包和轉(zhuǎn)發(fā)邏輯
實(shí)現(xiàn)
講完 eBPF 的內(nèi)容,對(duì)實(shí)現(xiàn)應(yīng)該會(huì)有一個(gè)大概的思路了。這里我們需要兩個(gè) eBPF 程序分別維護(hù) socket map 和將消息直通對(duì)端的 socket。這里感謝 Idan Zach 的示例代碼 ebpf-sockops[5],我將代碼做了 簡單的修改[6],讓可讀性更好一點(diǎn)。
原來代碼用使用了 16777343 表示地址 127.0.0.1?,4135 表示端口 10000,二者是網(wǎng)絡(luò) 字節(jié)序列轉(zhuǎn)換后的值。
socket map 維護(hù):sockops
附加到 sock_ops? 的程序:監(jiān)控 socket 狀態(tài),當(dāng)狀態(tài)為 BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB? 或者 BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB? 時(shí),使用輔助函數(shù) bpf_sock_hash_update?[^1] 將 socket 作為 value 保存到 socket map 中,key
__section("sockops")
int bpf_sockmap(struct bpf_sock_ops *skops)
{
__u32 family, op;
family = skops->family;
op = skops->op;
//printk("<<< op %d, port = %d --> %dn", op, skops->local_port, skops->remote_port);
switch (op) {
case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB:
if (family == AF_INET6)
bpf_sock_ops_ipv6(skops);
else if (family == AF_INET)
bpf_sock_ops_ipv4(skops);
break;
default:
break;
}
return 0;
}
// 127.0.0.1
static const __u32 lo_ip = 127 + (1 << 24);
static inline void bpf_sock_ops_ipv4(struct bpf_sock_ops *skops)
{
struct sock_key key = {};
sk_extract4_key(skops, &key);
if (key.dip4 == loopback_ip || key.sip4 == loopback_ip ) {
if (key.dport == bpf_htons(SERVER_PORT) || key.sport == bpf_htons(SERVER_PORT)) {
int ret = sock_hash_update(skops, &sock_ops_map, &key, BPF_NOEXIST);
printk("<<< ipv4 op = %d, port %d --> %dn", skops->op, key.sport, key.dport);
if (ret != 0)
printk("*** FAILED %d ***n", ret);
}
}
}
消息直通:sk_msg
附加到 socket map 的程序:在每次發(fā)送消息時(shí)觸發(fā)該程序,使用當(dāng)前 socket 的遠(yuǎn)端地址 + 端口和本地地址 + 端口作為 key 從 map 中定位對(duì)端的 socket。如果定位成功,說明客戶端和服務(wù)端位于同一節(jié)點(diǎn)上,使用輔助函數(shù) bpf_msg_redirect_hash[^2] 將數(shù)據(jù)直接寫入到對(duì)端 socket。
這里沒有直接使用 bpf_msg_redirect_hash?,而是通過自定義的 msg_redirect_hash 來訪問。因?yàn)榍罢邿o法直接訪問,否則校驗(yàn)會(huì)不通過。
__section("sk_msg")
int bpf_redir(struct sk_msg_md *msg)
{
__u64 flags = BPF_F_INGRESS;
struct sock_key key = {};
sk_msg_extract4_key(msg, &key);
// See whether the source or destination IP is local host
if (key.dip4 == loopback_ip || key.sip4 == loopback_ip ) {
// See whether the source or destination port is 10000
if (key.dport == bpf_htons(SERVER_PORT) || key.sport == bpf_htons(SERVER_PORT)) {
//int len1 = (__u64)msg->data_end - (__u64)msg->data;
//printk("<<< redir_proxy port %d --> %d (%d)n", key.sport, key.dport, len1);
msg_redirect_hash(msg, &sock_ops_map, &key, flags);
}
}
return SK_PASS;
}
測(cè)試
環(huán)境
- Ubuntu 20.04
- Kernel 5.15.0-1034
安裝依賴。
sudo apt update && sudo apt install make clang llvm gcc-multilib linux-tools-$(uname -r) linux-cloud-tools-$(uname -r) linux-tools-generic
克隆代碼。
git clone https://github.com/addozhang/ebpf-sockops
cd ebpf-sockops
編譯并加載 BPF 程序。
sudo ./load.sh
安裝 iperf3。
sudo apt install iperf3
啟動(dòng) iperf3 服務(wù)端。
iperf3 -s -p 10000
運(yùn)行 iperf3 客戶端。
iperf3 -c 127.0.0.1 -t 10 -l 64k -p 10000
運(yùn)行 trace.sh 腳本查看打印的日志,可以看到 4 條日志:創(chuàng)建了 2 個(gè)連接。
./trace.sh
iperf3-7744 [001] d...1 838.985683: bpf_trace_printk: <<< ipv4 op = 4, port 45189 --> 4135
iperf3-7744 [001] d.s11 838.985733: bpf_trace_printk: <<< ipv4 op = 5, port 4135 --> 45189
iperf3-7744 [001] d...1 838.986033: bpf_trace_printk: <<< ipv4 op = 4, port 45701 --> 4135
iperf3-7744 [001] d.s11 838.986078: bpf_trace_printk: <<< ipv4 op = 5, port 4135 --> 45701
如何確定跳過了內(nèi)核網(wǎng)絡(luò)棧了,使用 tcpdump 抓包看一下。從抓包的結(jié)果來看,只有握手和揮手的流量,后續(xù)消息的發(fā)送完全跳過了內(nèi)核網(wǎng)絡(luò)棧。
sudo tcpdump -i lo port 10000 -vvv
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
13:23:31.761317 IP (tos 0x0, ttl 64, id 50214, offset 0, flags [DF], proto TCP (6), length 60)
localhost.34224 > localhost.webmin: Flags [S], cksum 0xfe30 (incorrect -> 0x5ca1), seq 2753408235, win 65495, options [mss 65495,sackOK,TS val 166914980 ecr 0,nop,wscale 7], length 0
13:23:31.761333 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
localhost.webmin > localhost.34224: Flags [S.], cksum 0xfe30 (incorrect -> 0x169a), seq 3960628312, ack 2753408236, win 65483, options [mss 65495,sackOK,TS val 166914980 ecr 166914980,nop,wscale 7], length 0
13:23:31.761385 IP (tos 0x0, ttl 64, id 50215, offset 0, flags [DF], proto TCP (6), length 52)
localhost.34224 > localhost.webmin: Flags [.], cksum 0xfe28 (incorrect -> 0x3d56), seq 1, ack 1, win 512, options [nop,nop,TS val 166914980 ecr 166914980], length 0
13:23:31.761678 IP (tos 0x0, ttl 64, id 59057, offset 0, flags [DF], proto TCP (6), length 60)
localhost.34226 > localhost.webmin: Flags [S], cksum 0xfe30 (incorrect -> 0x4eb8), seq 3068504073, win 65495, options [mss 65495,sackOK,TS val 166914981 ecr 0,nop,wscale 7], length 0
13:23:31.761689 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
localhost.webmin > localhost.34226: Flags [S.], cksum 0xfe30 (incorrect -> 0x195d), seq 874449823, ack 3068504074, win 65483, options [mss 65495,sackOK,TS val 166914981 ecr 166914981,nop,wscale 7], length 0
13:23:31.761734 IP (tos 0x0, ttl 64, id 59058, offset 0, flags [DF], proto TCP (6), length 52)
localhost.34226 > localhost.webmin: Flags [.], cksum 0xfe28 (incorrect -> 0x4019), seq 1, ack 1, win 512, options [nop,nop,TS val 166914981 ecr 166914981], length 0
13:23:41.762819 IP (tos 0x0, ttl 64, id 43056, offset 0, flags [DF], proto TCP (6), length 52) localhost.webmin > localhost.34226: Flags [F.], cksum 0xfe28 (incorrect -> 0x1907), seq 1, ack 1, win 512, options [nop,nop,TS val 166924982 ecr 166914981], length 0
13:23:41.763334 IP (tos 0x0, ttl 64, id 59059, offset 0, flags [DF], proto TCP (6), length 52)
localhost.34226 > localhost.webmin: Flags [F.], cksum 0xfe28 (incorrect -> 0xf1f4), seq 1, ack 2, win 512, options [nop,nop,TS val 166924982 ecr 166924982], length 0
13:23:41.763348 IP (tos 0x0, ttl 64, id 43057, offset 0, flags [DF], proto TCP (6), length 52)
localhost.webmin > localhost.34226: Flags [.], cksum 0xfe28 (incorrect -> 0xf1f4), seq 2, ack 2, win 512, options [nop,nop,TS val 166924982 ecr 166924982], length 0
13:23:41.763588 IP (tos 0x0, ttl 64, id 50216, offset 0, flags [DF], proto TCP (6), length 52)
localhost.34224 > localhost.webmin: Flags [F.], cksum 0xfe28 (incorrect -> 0x1643), seq 1, ack 1, win 512, options [nop,nop,TS val 166924982 ecr 166914980], length 0
13:23:41.763940 IP (tos 0x0, ttl 64, id 14090, offset 0, flags [DF], proto TCP (6), length 52)
localhost.webmin > localhost.34224: Flags [F.], cksum 0xfe28 (incorrect -> 0xef2e), seq 1, ack 2, win 512, options [nop,nop,TS val 166924983 ecr 166924982], length 0
13:23:41.763952 IP (tos 0x0, ttl 64, id 50217, offset 0, flags [DF], proto TCP (6), length 52)
localhost.34224 > localhost.webmin: Flags [.], cksum 0xfe28 (incorrect -> 0xef2d), seq 2, ack 2, win 512, options [nop,nop,TS val 166924983 ecr 166924983], length 0
總結(jié)
通過 eBPF 的引入,我們縮短了同節(jié)點(diǎn)通信數(shù)據(jù)包的 datapath,跳過了內(nèi)核網(wǎng)絡(luò)棧直接連接兩個(gè)對(duì)端的 socket。
這種設(shè)計(jì)適用于同 pod 兩個(gè)應(yīng)用的通信以及同節(jié)點(diǎn)上兩個(gè) pod 的通信。
[^1]: 該輔助函數(shù)將引用的 socket 添加或者更新到 sockethash map 中,程序的輸入 bpf_sock_ops? 作為鍵值對(duì)的值。詳細(xì)信息可參考 https://man7.org/linux/man-pages/man7/bpf-helpers.7.html 中的 bpf_sock_hash_update。
[^2]: 該輔助函數(shù)將 msg 轉(zhuǎn)發(fā)到 socket map 中 key
參考資料
[1] eBPF.io: https://ebpf.io
[2] sk_buff?: https://atbug.com/tracing-network-packets-in-kubernetes/#sk_buff
[3] bpf_sock_ops?: https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L6377
[4] 輔助函數(shù): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
[5] Idan Zach 的示例代碼 ebpf-sockops: https://github.com/zachidan/ebpf-sockops
[6] 簡單的修改: https://github.com/zachidan/ebpf-sockops/pull/3/commits/be09ac4fffa64f4a74afa630ba608fd09c10fe2a