背景介紹
Kubernetes 中的網絡功能，主要包括 POD 網絡，service 網絡和網絡政策組成。其中 POD 網絡和網絡政策，都是規定了模型，沒有提供預設實作。而 service 網絡作為 Kubernetes 的特色部分，官方版本持續演進了多種實作：
<col>
service 實作
說明
userspace 代理模式
kube-proxy 負責 list/watch，規則設定，使用者态轉發。
iptables 代理模式
kube-proxy 負責 list/watch，規則設定。IPtables 相關核心子產品負責轉發。
IPVS 代理模式
kube-proxy 負責 list/watch，規則設定。IPVS 相關核心子產品負責轉發。
在 Kubernetes 中先後出現的幾種 Service 實作中，整體都是為了提供更高的性能和擴充性。
Service 網絡，本質上是一個分布式的伺服器負載均衡，通過 daemonset 方式部署的 kube-proxy，監聽 endpoint 和 service 資源，并在 node 本地生成轉發表項。目前在生産環境中主要是 iptables 和 IPVS 方式，原理如下：
在本文中，介紹使用 socket eBPF 在 socket 層面完成負載均衡的邏輯，消除了逐封包 NAT 轉換處理，進一步提升 Service 網絡的轉發性能。
基于 socket eBPF 的資料面實作
socket eBPF 資料面簡介
無論 kube-proxy 采用 IPVS 還是 tc eBPF 服務網絡加速模式，每個從 pod 發出網絡請求都必然經過 IPVS 或者 tc eBPF，即 POD <--> Service <--> POD，随着流量的增加必然會有性能開銷, 那麼是否可以直接在連接配接中将 service的clusterIP 的位址直接換成對應的 pod ip。基于 Kube-proxy+IPVS 實作的 service 網絡服務，是基于逐報處理 +session 的方式來實作。
利用 socket eBPF，可以在不用直接處理封包和 NAT 轉換的前提下，實作了負載均衡邏輯。Service 網絡在同步上優化成 POD <--> POD，進而使Service 網絡性能基本等同于 POD 網絡。軟體結構如下：
在 Linux 核心中，利用 BPF_PROG_TYPE_CGROUP_SOCK 類型的 eBPF hook 可以針對 socket 系統調用挂接 hook，插入必要的 EBPF 程式。
通過 attach 到特定的 cgroup 的檔案描述符，可以控制 hook 接口的作用範圍。
利用 sock eBPF hook，我們可以在 socket 層面劫持特定的 socket 接口，來完成完成負載均衡邏輯。
POD-SVC-POD 的轉發行為轉換成 POD-POD 的轉發行為。
目前 Linux 核心中不斷完善相關的 hook，支援更多的 bpf_attach_type，部分距離如下：
BPF_CGROUP_INET_SOCK_CREATE
BPF_CGROUP_INET4_BIND
BPF_CGROUP_INET4_CONNECT
BPF_CGROUP_UDP4_SENDMSG
BPF_CGROUP_UDP4_RECVMSG
BPF_CGROUP_GETSOCKOPT
BPF_CGROUP_INET4_GETPEERNAME
BPF_CGROUP_INET_SOCK_RELEASE
TCP 由于是有基于連接配接的，是以實作非常簡明，隻需要 hook connect 系統調用即可，如下所示：
connect 系統調用劫持邏輯：
1. 從 connect 調用上下文中取 dip+dport，查找 svc 表。找不到則不處理傳回。
2. 查找親和性會話，如果找到，得到 backend_id，轉 4。否則轉 3。
3. 随機排程，配置設定一個 backend。
4. 根據 backend_id，查 be 表，得到 be 的 IP+ 端口。
5. 更新親和性資訊。
6. 修改 connect 調用上下文中的 dip+dport 為 be 的 ip+port。
7. 完成。
在 socket 層面就完成了端口轉換，對于 TCP 的 clusterip 通路，基本上可以等同于 POD 之間東西向的通信，将 clusterip 的開銷降到最低。
不需要逐包的 dnat 行為。
不需要逐包的查找 svc 的行為。
UDP 由于是無連接配接的，實作要複雜一些，如下圖所示：
nat_sk 表的定義參見：LB4_REVERSE_NAT_SK_MAP
劫持 connect 和 sendmsg 系統調用：
1. 從系統調用調用上下文中取 dip+dport，查找 svc 表。找不到則不處理傳回。
2. 查找親和性會話，如果找到，得到 backend_id，轉 4，否則轉 3。
4. 根據 backend_id，查 be 表，得到 be 的 IP+端口。
5. 更新親和性的相關表。
6. 更新 nat_sk 表，key 為 be 的 ip+port，value 為 svc的vip+vport。
7. 修改系統調用上下文中的 dip+dport 為 be 的 ip + port。
8. 完成。
劫持 recvmsg 系統調用
1. 從系統調用上下文中遠端 IP+port，查找 NAT_SK 表，找不到則不處理傳回。
2. 找到，取出其中的 IP+port，用來查找 svc 表，找不到，則删除 nat_sk 對應表項，傳回。
3. 使用 nat_sk 中找到的 ip+port，設定系統調用上下文中遠端的 IP+port。
4. 完成。
關于位址修正問題
基于 socket eBPF 實作的 clusterIP，在上述基本轉發原理之外，還有一些特殊的細節需要考慮,其中一個需要特殊考慮就是 peer address 的問題。和 IPVS之類的實作不同，在 socket eBPF 的 clusterIP 上，client 是和直接和 backend 通信的，中間的 service 被旁路了。回顧一下轉發路徑如下：
此時，如果 client 上的 APP 調用 getpeername 之類的接口查詢 peer address，這個時候擷取到的位址和 connect 發起的位址是不一緻的，如果 app對于 peeraddr 有判斷或者特殊用途，可能會有意外情況。
針對這種情況，我們同樣可以通過 eBPF 在 socket 層面來修正：
1、在guest kernel 上新增 bpf_attach_type，可以對 getpeername 和 getsockname 增加 hook 處理。
2、發起連接配接的時候，在相應的 socket hook 進行中，定義 map 記錄響應的VIP:VPort 和 RSIP:RSPort 的對用關系。
3、當 APP 要調用 getpeername/getsockname 接口的時候，利用 eBPF 程式修正傳回的資料：修改上下文中的遠端的 IP+port為vip+vport。
總結
測試環境：4vcpu + 8G mem 的安全容器執行個體，單 client + 單 clusterip + 12 backend。
socket BPF：基于 socket ebpf 的 service 實作。
tc eBPF：基于 cls-bpf 的 service 實作，目前已經在 ack 服務中應用。
IPVS-raw：去掉所有安全組規則和 veth 之類開銷，隻有 IPVS 轉發邏輯的 service 實作。
socket BPF 在所有性能名額上，均有不同程度提升。
大量并發的短連接配接，基本上吞吐提升 15%，時延降低 20%。
轉發性能比較（QPS）
90%轉發延時比較（ms）
繼續演進
eBPF does to Linux what JavaScript does to HTML.
-- Brendan Gregg
基于 socket eBPF 實作的 service，大大簡化了負載均衡的邏輯實作，充分展現了 eBPF 靈活、小巧的特點。eBPF 的這些特點也很契合雲原生場景，目前，該技術已在阿裡雲展開實踐，加速了 kubernetes 服務網絡。我們會繼續探索和完善更多的 eBPF 的應用案例，比如 IPv6、network policy 等。
關于龍蜥社群
龍蜥社群(OpenAnolis)是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于2020年9月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。
短期目标是開發龍蜥作業系統(Anolis OS)作為CentOS替代版，重新建構一個相容國際Linux主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。