作者
劉旭，騰訊云高級工程師，專注容器云原生領域，有多年大規模 Kubernetes 集群管理及微服務治理經驗，現負責騰訊云服務網格 TCM 資料面產品架構設計和研發作業，
引言
目前以 Istio[1] 為代表的服務網格普遍使用 Sidecar 架構，并使用 iptables 將流量劫持到 Sidecar 代理，優點是對應用程式無侵入，但是 Sidecar 代理會增加請求時延和資源占用，
性能一直是用戶十分關心的一個點，也是用戶評估是否使用服務網格產品的關鍵因素，騰訊云 TCM 團隊一直致力于優化服務網格性能，上周我們在 KubeCon 分享了使用 eBPF 代替 iptables 優化服務網格資料面性能的方案，
iptables 實作流量劫持
首先看一下當前社區使用的基于 iptables 的流量劫持方案，下圖是一個 Pod 的創建程序，sidecar injector 會向 Pod 中注入兩個容器，istio-init 和 istio-proxy
-
istio-init 是一個 init container，負責創建流量劫持相關的 iptables 規則，在創建完成后會退出
-
istio-proxy 中運行著 envoy，負責代理 Pod 的網路流量，iptables 會將請求劫持到 istio-proxy 處理
下圖展示了 iptables 完成流量劫持的整個程序，這里簡單說明下，感興趣的同學可以查看[2]
-
Inbound iptables 將入流量重定向到 15006 埠，也就是 envoy 的 VirtualInboundListener，envoy 會根據請求的原始目的地址轉發到應用程式的指定埠
-
Outbound iptables 將出流量重定向到 15001 埠，也就是 envoy 的 VirtualOutboundListener，envoy 會根據請求的原始目的地址以及 Host URL 等資訊路由到指定后端
eBPF 實作流量劫持
eBPF(extended Berkeley Packet Filter) 是一種可以在 Linux 內核中運行用戶撰寫的程式，而不需要修改內核代碼或加載內核模塊的技術，目前被廣泛用于網路、安全、監控等領域，在 Kubernetes 社區最早也是最有影響的基于 eBPF 專案是 Cilium[4]，Cilium 使用 eBPF 代替 iptables 優化 Service 性能，
Inbound
首先來看一下對入流量的劫持，對入流量的劫持主要使用 eBPF 程式 hook bind 系統呼叫完成，
eBPF 程式會劫持 bind 系統呼叫并修改地址，例如應用程式 bind 0.0.0.0:80 會被修改為 127.0.0.1:80，應用程式還有可能 bind ipv6 的地址，所以這里有兩個 eBPF 程式分別處理 ipv4 和 ipv6 的 bind，
和 iptables 不同，iptables 可以針對每個 netns 單獨設定規則，eBPF 程式 attach 到指定 hook 點后，會對整個系統都生效，例如 attach 到 bind 系統呼叫后，所有 Pod 內以及節點上行程呼叫 bind 都會觸發 eBPF 程式，我們需要區分哪些呼叫是來自需要由 eBPF 完成流量劫持的 Pod，
在 K8s 中，除了 hostnetwork 的情況，每個 Pod 都有獨立的 netns，而每個 netns 都有唯一的 cookie，因此我們將需要使用 eBPF 完成流量劫持的 Pod 對應的 netns cookie 保存在 cookie_map 中，eBPF 程式通過判斷當前 socket 的 netns cookie 是否在 cookie_map 中來決定是否修改 bind 地址，
修改應用程式的 bind 地址后，還需要下發 pod_ip:80 listener 配置到 envoy，pod_ip:80 listener 會將請求轉發到 127.0.0.1:80 也就是應用程式監聽的地址，這樣就實作了對入流量的劫持，但是這里有一個問題，由于 istio 使用 istio-proxy 用戶啟動 envoy，默認情況下非 root 用戶不能 bind 1024 以下的特權埠，我們通過 istio-init 修改內核引數 sysctl net.ipv4.ip_unprivileged_port_start=0 解決了這個問題，
對比 iptables 和 eBPF 對入流量的劫持，iptables 方案每個包都需要 conntrack 處理，而 eBPF 方案只有在應用程式呼叫 bind 時執行一次，之后不會再執行，減少了性能開銷，
Outbound
再來看一下對出流量的劫持，對出流量的劫持比較復雜，根據協議分為 TCP 和 UDP 兩種情況，
TCP 流量劫持
對 TCP 的出流量劫持程序：
-
_coonect4通過劫持 connect 系統呼叫將目的地址修改為127.0.0.1:15001，也就是 envoy 的 VirtualOutboundListerer，同時將連接的原始目的地址保存在sk_storage_map -
在 TCP 連接建立完成后，
sockops會讀取sk_storage_map中的資料，并以四元組（源IP、目的IP、源埠、目的埠）為 key 將原始目的地址保存在origin_dst_map -
_getsockopt通過劫持 getsockopt 系統呼叫，讀取origin_dst_map中的資料將原始目的地址回傳給 envoy
UDP 流量劫持
istio 在 1.8 版本支持了智能 DNS 代理[5]，開啟后 iptables 會將 DNS 請求劫持到 Sidecar 處理，我們也需要用 eBPF 實作相同邏輯，對于 TCP DNS 的劫持和上面類似，對 UDP DNS 的劫持見下圖
對 UDP 的出流量劫持程序：
_connect4和_sendmsg4都是負責修改 UDP 的目的地址為 127.0.0.1:15053 并保存原始的目的地址到sk_storage_map，因為 Linux 提供兩種發送 UDP 資料的方式- 先呼叫 connect 再呼叫 send，這種情況由
_connect4處理 - 直接呼叫 sendto，這種情況由
_sendmsg4處理
- 先呼叫 connect 再呼叫 send，這種情況由
recvmsg4通過讀取sk_storage_map將回包的源地址改為原始的目的地址，這是因為有些應用程式，例如 nslookup 會校驗回包的源地址，
對于 TCP 和 connected UDP，iptables 方案每個包都需要 conntrack 處理，而eBPF 方案的開銷是一次性的，只需要在 socket 建立時執行一次，降低了性能開銷，
Sockmap
使用 sockmap 優化服務網格性能的方案最早由 cilium 提出，我們的方案也參考了 cilium，這里借用 cilium 的兩張圖來說明下優化效果
優化前 Sidecar 代理與應用程式間的網路通信都需要經過 TCP/IP 協議堆疊處理
優化后 Sidecar 代理與應用程式間的網路通信繞過了 TCP/IP 協議堆疊，如果兩個 Pod 在同一節點上，兩個 Pod 間的網路通信也可以被優化，這里簡單說明下 sockmap 的優化原理，感興趣的同學可以查看[6][7]，
sock_hash是一個存盤 socket 資訊的 eBPF map，key 是四元組（源IP、目的IP、源埠、目的埠）_sockops負責監聽 socket 事件，并將 socket 資訊保存在sock_hash_sk_msg會攔截 sendmsg 系統呼叫，然后到sock_hash中查找對端 socket，如果找到會呼叫bpf_msg_redirect_hash直接將資料發送給對端 socket
問題
但是用四元組做為 key 可能會存在沖突的問題，例如在同一節點上的兩個 Pod 中，envoy 使用同一源埠 50000 請求應用程式的 80 埠，
為了解決這個問題，我們在 key 中添加了 netns cookie，同時對于非 localhost 的請求將 cookie 設定為 0，這樣既保證了 key 不會沖突，又可以加速同一節點上兩個 Pod 間的網路通信，
但是之前版本的內核不支持在 sockops 和 sk_msg 這兩種 eBPF 程式中獲取 netns cookie 資訊，因此我們提交了兩個 patch [8 ][9]到內核社區，目前已合入 5.15 版本，
架構
整個方案的架構如圖所示，istio-ebpf 以 DaemonSet 的形式運行在節點上，負責 load/attach eBPF 程式和創建 eBPF map，istio-init 容器仍然保留，但是不再創建 iptables 規則，而是更新 eBPF map，istio-init 會將 Pod 的 netns cookie 保存在 cookie_map 中，同時我們也修改了 istiod，istiod 會根據 Pod 的流量劫持模式（iptables/eBPF)下發不同的 xDS 配置，
性能對比
測驗環境：Ubuntu 21.04 5.15.7
- 同等條件下，使用 eBPF 可減少 20% 的 System CPU 占用
- 同等條件下，使用 eBPF 可提高 20% QPS
- 同等條件下，使用 eBPF 可降低請求時延
總結
服務網格的 Sidecar 架構不可避免的會增加請求時延和資源占用，我們通過使用 eBPF 代替 iptables 實作流量劫持，同時使用 sockmap 加速 Sidecar 代理和應用程式間的網路通信，在一定程度上降低了請求時延和資源開銷，由于內核版本等限制這一方案預計會在明年初上線，TCM 團隊將持續探索新的性能優化方向，
Reference
[1] https://istio.io
[2] https://jimmysong.io/blog/sidecar-injection-iptables-and-traffic-routing
[3] https://ebpf.io
[4] https://cilium.io
[5] https://istio.io/latest/blog/2020/dns-proxy
[6] https://arthurchiao.art/blog/socket-acceleration-with-ebpf-zh
[7] https://github.com/cilium/cilium/tree/v1.11.0/bpf/sockops
[8] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=6cf1770d
[9] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fab60e29f
關于我們
更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~
福利：
①公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~
②公眾號后臺回復【系列】，可獲得《15個系列100+篇超實用云原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列，
③公眾號后臺回復【白皮書】，可獲得《騰訊云容器安全白皮書》&《降本之源-云原生成本管理白皮書v1.0》
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/382184.html
標籤：其他