eBPF技術(shù)應(yīng)用云原生網(wǎng)絡(luò)實(shí)踐系列之基于socket的service?|?龍蜥技術(shù)

時(shí)間：2021-10-13 14:07:43

關(guān)鍵字： service socket

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]相關(guān)閱讀：《eBPF技術(shù)應(yīng)用云原生網(wǎng)絡(luò)實(shí)踐系列之kubernetes網(wǎng)絡(luò)》背景介紹Kubernetes中的網(wǎng)絡(luò)功能，主要包括POD網(wǎng)絡(luò)，service網(wǎng)絡(luò)和網(wǎng)絡(luò)策略組成。其中POD網(wǎng)絡(luò)和網(wǎng)絡(luò)策略，都是規(guī)定了模型，沒有提供默認(rèn)實(shí)現(xiàn)。而service網(wǎng)絡(luò)作為Kubernetes的特色...

相關(guān)閱讀：《eBPF技術(shù)應(yīng)用云原生網(wǎng)絡(luò)實(shí)踐系列之kubernetes網(wǎng)絡(luò)》

背景介紹

Kubernetes 中的網(wǎng)絡(luò)功能，主要包括 POD 網(wǎng)絡(luò)，service 網(wǎng)絡(luò)和網(wǎng)絡(luò)策略組成。其中 POD 網(wǎng)絡(luò)和網(wǎng)絡(luò)策略，都是規(guī)定了模型，沒有提供默認(rèn)實(shí)現(xiàn)。而 service 網(wǎng)絡(luò)作為 Kubernetes 的特色部分，官方版本持續(xù)演進(jìn)了多種實(shí)現(xiàn)：

service 實(shí)現(xiàn)	說明
userspace 代理模式	kube-proxy 負(fù)責(zé) list/watch，規(guī)則設(shè)置，用戶態(tài)轉(zhuǎn)發(fā)。
iptables 代理模式	kube-proxy 負(fù)責(zé) list/watch，規(guī)則設(shè)置。IPtables 相關(guān)內(nèi)核模塊負(fù)責(zé)轉(zhuǎn)發(fā)。
IPVS 代理模式	kube-proxy 負(fù)責(zé) list/watch，規(guī)則設(shè)置。IPVS 相關(guān)內(nèi)核模塊負(fù)責(zé)轉(zhuǎn)發(fā)。

在 Kubernetes 中先后出現(xiàn)的幾種 Service 實(shí)現(xiàn)中，整體都是為了提供更高的性能和擴(kuò)展性。

Service 網(wǎng)絡(luò)，本質(zhì)上是一個(gè)分布式的服務(wù)器負(fù)載均衡，通過 daemonset 方式部署的 kube-proxy，監(jiān)聽 endpoint 和 service 資源，并在 node 本地生成轉(zhuǎn)發(fā)表項(xiàng)。目前在生產(chǎn)環(huán)境中主要是 iptables 和 IPVS 方式，原理如下：

在本文中，介紹使用 socket eBPF 在 socket 層面完成負(fù)載均衡的邏輯，消除了逐報(bào)文 NAT 轉(zhuǎn)換處理，進(jìn)一步提升 Service 網(wǎng)絡(luò)的轉(zhuǎn)發(fā)性能。

基于 socket eBPF 的數(shù)據(jù)面實(shí)現(xiàn)

socket eBPF 數(shù)據(jù)面簡(jiǎn)介

無論 kube-proxy 采用 IPVS 還是 tc eBPF 服務(wù)網(wǎng)絡(luò)加速模式，每個(gè)從 pod 發(fā)出網(wǎng)絡(luò)請(qǐng)求都必然經(jīng)過 IPVS 或者 tc eBPF，即 PODServicePOD，隨著流量的增加必然會(huì)有性能開銷, 那么是否可以直接在連接中將 service的clusterIP 的地址直接換成對(duì)應(yīng)的 pod ip?；?Kube-proxy IPVS 實(shí)現(xiàn)的 service 網(wǎng)絡(luò)服務(wù)，是基于逐報(bào)處理 session 的方式來實(shí)現(xiàn)。

利用 socket eBPF，可以在不用直接處理報(bào)文和 NAT 轉(zhuǎn)換的前提下，實(shí)現(xiàn)了負(fù)載均衡邏輯。Service 網(wǎng)絡(luò)在同步上優(yōu)化成 PODPOD，從而使Service 網(wǎng)絡(luò)性能基本等同于 POD 網(wǎng)絡(luò)。軟件結(jié)構(gòu)如下：

在 Linux 內(nèi)核中，利用 BPF_PROG_TYPE_CGROUP_SOCK 類型的 eBPF hook 可以針對(duì) socket 系統(tǒng)調(diào)用掛接 hook，插入必要的 EBPF 程序。

通過 attach 到特定的 cgroup 的文件描述符，可以控制 hook 接口的作用范圍。
利用 sock eBPF hook，我們可以在 socket 層面劫持特定的 socket 接口，來完成完成負(fù)載均衡邏輯。
POD-SVC-POD 的轉(zhuǎn)發(fā)行為轉(zhuǎn)換成 POD-POD 的轉(zhuǎn)發(fā)行為。

當(dāng)前 Linux 內(nèi)核中不斷完善相關(guān)的 hook，支持更多的 bpf_attach_type，部分距離如下：BPF_CGROUP_INET_SOCK_CREATEBPF_CGROUP_INET4_BINDBPF_CGROUP_INET4_CONNECTBPF_CGROUP_UDP4_SENDMSGBPF_CGROUP_UDP4_RECVMSGBPF_CGROUP_GETSOCKOPTBPF_CGROUP_INET4_GETPEERNAMEBPF_CGROUP_INET_SOCK_RELEASE

TCP 工作流程

TCP 由于是有基于連接的，所以實(shí)現(xiàn)非常簡(jiǎn)明，只需要 hook connect 系統(tǒng)調(diào)用即可，如下所示：connect 系統(tǒng)調(diào)用劫持邏輯：1. 從 connect 調(diào)用上下文中取 dip dport，查找 svc 表。找不到則不處理返回。

2. 查找親和性會(huì)話，如果找到，得到 backend_id，轉(zhuǎn) 4。否則轉(zhuǎn) 3。

3. 隨機(jī)調(diào)度，分配一個(gè) backend。

4. 根據(jù) backend_id，查 be 表，得到 be 的 IP 端口。

5. 更新親和性信息。

6. 修改 connect 調(diào)用上下文中的 dip dport 為 be 的 ip port。

7. 完成。

在 socket 層面就完成了端口轉(zhuǎn)換，對(duì)于 TCP 的 clusterip 訪問，基本上可以等同于 POD 之間東西向的通信，將 clusterip 的開銷降到最低。

不需要逐包的 dnat 行為。
不需要逐包的查找 svc 的行為。

UDP 工作流程

UDP 由于是無連接的，實(shí)現(xiàn)要復(fù)雜一些，如下圖所示：nat_sk 表的定義參見：LB4_REVERSE_NAT_SK_MAP

劫持 connect 和 sendmsg 系統(tǒng)調(diào)用：1. 從系統(tǒng)調(diào)用調(diào)用上下文中取 dip dport，查找 svc 表。找不到則不處理返回。

2. 查找親和性會(huì)話，如果找到，得到 backend_id，轉(zhuǎn) 4，否則轉(zhuǎn) 3。

3. 隨機(jī)調(diào)度，分配一個(gè) backend。

4. 根據(jù) backend_id，查 be 表，得到 be 的 IP 端口。

5. 更新親和性的相關(guān)表。

6. 更新 nat_sk 表，key 為 be 的 ip port，value 為 svc的vip vport。

7. 修改系統(tǒng)調(diào)用上下文中的 dip dport 為 be 的 ip port。

8. 完成。劫持 recvmsg 系統(tǒng)調(diào)用1. 從系統(tǒng)調(diào)用上下文中遠(yuǎn)端 IP port，查找 NAT_SK 表，找不到則不處理返回。

2. 找到，取出其中的 IP port，用來查找 svc 表，找不到，則刪除 nat_sk 對(duì)應(yīng)表項(xiàng)，返回。

3. 使用 nat_sk 中找到的 ip port，設(shè)置系統(tǒng)調(diào)用上下文中遠(yuǎn)端的 IP port。

4. 完成。關(guān)于地址修正問題
基于 socket eBPF 實(shí)現(xiàn)的 clusterIP，在上述基本轉(zhuǎn)發(fā)原理之外，還有一些特殊的細(xì)節(jié)需要考慮,其中一個(gè)需要特殊考慮就是 peer address 的問題。和 IPVS之類的實(shí)現(xiàn)不同，在 socket eBPF 的 clusterIP 上，client 是和直接和 backend 通信的，中間的 service 被旁路了。回顧一下轉(zhuǎn)發(fā)路徑如下：

此時(shí)，如果 client 上的 APP 調(diào)用 getpeername 之類的接口查詢 peer address，這個(gè)時(shí)候獲取到的地址和 connect 發(fā)起的地址是不一致的，如果 app對(duì)于 peeraddr 有判斷或者特殊用途，可能會(huì)有意外情況。

針對(duì)這種情況，我們同樣可以通過 eBPF 在 socket 層面來修正：1、在guest kernel 上新增 bpf_attach_type，可以對(duì) getpeername 和 getsockname 增加 hook 處理。

2、發(fā)起連接的時(shí)候，在相應(yīng)的 socket hook 處理中，定義 map 記錄響應(yīng)的VIP:VPort 和 RSIP:RSPort 的對(duì)用關(guān)系。3、當(dāng) APP 要調(diào)用 getpeername/getsockname 接口的時(shí)候，利用 eBPF 程序修正返回的數(shù)據(jù)：修改上下文中的遠(yuǎn)端的 IP port為vip vport。

總結(jié)

和TC-EBPF/IPVS性能對(duì)比

測(cè)試環(huán)境：4vcpu 8G mem 的安全容器實(shí)例，單 client 單 clusterip 12 backend。socket BPF：基于 socket ebpf 的 service 實(shí)現(xiàn)。tc eBPF：基于 cls-bpf 的 service 實(shí)現(xiàn)，目前已經(jīng)在 ack 服務(wù)中應(yīng)用。IPVS-raw：去掉所有安全組規(guī)則和 veth 之類開銷，只有 IPVS 轉(zhuǎn)發(fā)邏輯的 service 實(shí)現(xiàn)。socket BPF 在所有性能指標(biāo)上，均有不同程度提升。大量并發(fā)的短連接，基本上吞吐提升 15%，時(shí)延降低 20%。轉(zhuǎn)發(fā)性能比較（QPS）90%轉(zhuǎn)發(fā)延時(shí)比較（ms）
繼續(xù)演進(jìn)
eBPF does to Linux what JavaScript does to HTML.-- Brendan Gregg基于 socket eBPF 實(shí)現(xiàn)的 service，大大簡(jiǎn)化了負(fù)載均衡的邏輯實(shí)現(xiàn)，充分體現(xiàn)了 eBPF 靈活、小巧的特點(diǎn)。eBPF 的這些特點(diǎn)也很契合云原生場(chǎng)景，目前，該技術(shù)已在阿里云展開實(shí)踐，加速了 kubernetes 服務(wù)網(wǎng)絡(luò)。我們會(huì)繼續(xù)探索和完善更多的 eBPF 的應(yīng)用案例，比如 IPv6、network policy 等。

——完——加入龍蜥社群
加入微信群：添加社區(qū)助理-龍蜥社區(qū)小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發(fā)者/用戶加入龍蜥社區(qū)（OpenAnolis）交流，共同推進(jìn)龍蜥社區(qū)的發(fā)展，一起打造一個(gè)活躍的、健康的開源操作系統(tǒng)生態(tài)！