前言

Kubernetes 已經成為容器管理領域的事實標準，而網路系統是 Kubernetes 核心部分，隨著越來越多的業務部署在 Kubernetes，對容器網路也提出了一些新的需求

怎麼提升網路的可觀測性，serverless 類產品該需求尤為突出
怎麼儘可能減少容器引入的網路效能損耗

上述需求衝擊了 iptables，IPVS 等傳統防火牆，負載均衡器技術。也促使我們思考容器網路訪問鏈路能否不依賴於節點，進而縮短容器訪問鏈路，提升網路效能

eBPF 是一項革命性技術，它可以以一種安全的方式在核心中許多 hook 點執行程式，該項技術可程式設計能力強，並且也無需維護核心模組，可維護性好，該項技術為滿足上述需求提供了可能。則是基於 eBPF 技術的容器網路開源專案，提供了網路互通，服務負載均衡，安全和可觀測性等解決方案

由此，騰訊雲容器服務 TKE 基於 Cilium 和 eBPF 實現了獨立網路卡模式下的高效能 ClusterIP Service 方案。TKE 致力於提供更高效能、更安全和更易用的容器網路，也因此會不斷關注 Cilium 等前沿的容器網路技術方案，後續會推出更多更完善的 Cilium 產品化能力。

獨立網路卡 Service 方案

TKE 於去年推出了新一代容器網路方案，該方案實現了一個 Pod 獨佔一張彈性網路卡，不再經過節點網路協議棧（default namespace）。而當前的 kube-proxy 實現 ClusterIP 的方案都依賴於在節點側的網路協議棧裡設定相應的 iptables 規則，也因此該方案對於獨立網路卡方案不再適用。

其中一個解決方案便是 Cilium，Cilium 提供了基於 eBPF 的地址轉換能力，從而可支援 ClusterIP Service。但其原生方案僅支援 veth pair 和 ipvlan l3 的資料面，並不支援 Pod 完全不經過節點網路協議棧的資料面，因此不能原生解決獨立網路卡 ClusterIP 的訪問問題。

TKE 由此對 Cilium 加以改造，使其支援了除原生支援的 veth 和 ipvlan l3 的第三種資料面方案，如圖（假設 pod 訪問 Service IP 為 172.16.0.2），資料面上，將原本掛載到節點側的 veth 上的 bpf 程式，掛載到 pod 內的獨立網路卡（同時也是彈性網路卡）上，使得 Pod 的網路報文在發出的時候做 DNAT（目的地址轉換），而回報文在網路卡接收的時候做反向 DNAT，從而支援 ClusterIP 的訪問。該資料面方案 可作為一個通用方案適配 Ipvlan l2、SRIOV 等資料面場景。

而控制面上，將 Cilium 與 TKE 的 VPC-CNI 模式（含共享網路卡模式和獨立網路卡模式）深度整合，使用者無需對業務程式碼邏輯做任何修改，即可使用 Cilium 的功能特性。

效能對比

本文使用 wrk 工具對 Cilium 的產品化解決方案進行了效能壓測，測試保證 Client Pod 和 Server Pod 分佈在不同節點。

測試環境： TKE 叢集，4 個 CVM節點，配置為 Server S5.2XLARGE8，Client S5.SMALL2。

測試資料表明， 基於 Cilium 的獨立網路卡 ClusterIP 訪問方案效能最好。在短連線場景下，其 QPS 相比共享網路卡的 iptables 和 ipvs 方案提升48%和74%，相比全域性路由的 iptables 和 ipvs 方案提升了62%和91%。在長連線場景下，其 QPS 相比共享網路卡的 iptables 和 ipvs 方案提升了33%和57%，而相比全域性路由的 iptables 和 ipvs 方案提升了49%和66%。iptables 的效能較 ipvs 效能較好是因為測試環境中 Service 數量還不夠多，ipvs 的優勢在於大量 Service 的場景。

產品化過程中的相關問題

TKE 團隊在實現 Cilium 產品化解決方案過程中，也發現了 Cilium 專案中一些問題，相應的解決方案和 Cilium 支援新資料面方案將於近日以 pr 的形式整理提交給 Cilium 社群。

獨立網路卡方案下的 ClusterIP 自訪問不通

以上方案其實不能完全解決 ClusterIP 訪問問題，存在一類特殊的場景會訪問不通。這類場景就是 Pod 訪問的 ClusterIP，其後端包括其自身。這類場景下，獨立網路卡的 Pod 發出的網路報文會直接到達 IAAS 層，不符合預期。

由於獨立網路卡 Pod 內，其實只有兩個網路裝置：迴環裝置（lo）和彈性網路卡，因此一個簡單的思路就是在出報文之前，對自訪問流量，透過 bpf_redirect 呼叫將報文直接轉發（redirect）到迴環（lo）裝置。基於此，TKE 團隊修改了 cilium 的相關 bpf 程式碼，提供了一個解決方案。經過測試，該方案可以解決獨立網路卡方案下的 ClusterIP 自訪問問題。

Cilium 載入 bpf 程式的名字缺失

Cilium 專案的可除錯性存在一個問題，其 bpf 程式開發得比較早，底層用了很多老的工具集，例如 tc，來載入 bpf 程式碼。

老的 tc 基於老的核心版本(<4.15)設計的，它在載入 bpf 程式時，將 bpf 程式的名字忽略了，導致 Cilium 載入的 bpf 程式都是無名字的。這影響了對程式碼的理解，追蹤和除錯。

對此 TKE 團隊結合較新的核心對 tc 工具進行了修正，使得它載入 bpf 程式時，會正確的傳入名字。透過這名字，可以搞清楚實際執行的 bpf 函式具體是哪一個，從而提高 Cilium 的可除錯性。

用法

申請 Cilium 支援 ClusterIP 產品化內測開通後，建立 TKE 叢集時高階設定中開啟 ClusterIP 增強 即可：

總結與展望

本文介紹了 TKE 團隊實現的基於 Cilium 和 eBPF 的獨立網路卡模式下高效能 ClusterIP service 方案，該方案相比當前基於 iptables 和 ipvs 的傳統網路方案大量的提升了效能（33%-91%）。

顯然，Cilium 提供的能力還不止於此，其基於 eBPF 這項革命性的技術，還提供了安全、可觀測性、QoS 等方面的能力，而提供更高效能、更安全和更易用的容器網路正是 TKE 的服務目標，因此，後續 TKE 將會積極參與 Cilium 社群，與社群一道共同推出更強大、更完善的容器網路能力。

QPS 最高提升 91% | 騰訊雲 TKE 基於 Cilium eBPF 提升 k8s Service 效能

前言