kube-proxy
我們知道，Kubernetes中Pod的生命是短暫了，它隨時可能被終止。即使使用了Deployment或者ReplicaSet保證Pod掛掉之后還會重啟，但也沒法保證重啟后Pod的IP不變。從服務的高可用性與連續性的角度出發，我們不可能把Pod的IP直接暴露成service端口。因此我們需要一個更加可靠的“前端”去代理Pod，這就是k8s中的Service。引用官方文檔的定義就是：
Service 定義了這樣一種抽象：邏輯上的一組 Pod，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 Pod 能夠被 Service 訪問到。
也可以說，Service作為“前端”提供穩定的服務端口，Pod作為“后端”提供服務實現。Service會監控自己組內的Pod的運行狀態，剔除終止的Pod，添加新增的Pod。配合k8s的服務發現機制，我們再也不用擔心IP改變，Pod終止等問題了。kube-proxy則是實現Service的關鍵組件，到目前為止共有3種實現模式：userspace、iptables 或者 IPVS。其中userspace 模式非常陳舊、緩慢，已經不推薦使用。
IP Tables模式
iptables 是一個 Linux 內核功能，是一個高效的防火墻，并提供了大量的數據包處理和過濾方面的能力。它可以在核心數據包處理管線上用 Hook 掛接一系列的規則。在K8S中，kube-proxy 會把請求的代理轉發規則全部寫入iptable中，砍掉了kube-proxy轉發的部分，整個過程發生在內核空間，提高了轉發性能，但是iptable的規則是基于鏈表實現的，規則數量隨著Service數量的增加線性增加，查找時間復雜度為O（n），也就是說，當Service數量到達一定量級時，CPU消耗和延遲將顯著增加。
IP VS模式
IPVS 是一個用于負載均衡的 Linux 內核功能。IPVS 模式下，kube-proxy 使用 IPVS 負載均衡代替了 iptable。IPVS 的設計就是用來為大量服務進行負載均衡的，它有一套優化過的 API，使用優化的查找算法，而不是簡單的從列表中查找規則。這樣一來，kube-proxy 在 IPVS 模式下，其連接過程的復雜度為 O(1)。換句話說，多數情況下，他的連接處理效率是和集群規模無關的。另外作為一個獨立的負載均衡器，IPVS 包含了多種不同的負載均衡算法，例如輪詢、最短期望延遲、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機平等的選擇算法。IPVS 的一個潛在缺點就是，IPVS 處理數據包的路徑和通常情況下 iptables 過濾器的路徑是不同的。
通過下圖，可以簡單的看出Client pod 、kube proxy 、Pod之間的關系。Service的虛擬Ip會寫到ip tables/ip vs中，被轉發到真正的Pod地址。
IP Tables & IP VS 網絡扭轉
流程簡述如下：
- kube-proxy DNAT + SNAT 用自己的 IP 替換源 IP ，用 Pod IP 替換掉目的 IP
- 數據包轉發到目標 Pod
- Pod 將 Ingress Node 視為源，并作出響應
- 源 / 目的地址在 Ingress Node 替換為客戶端地址(目的) ，服務地址(Ingress Node)
性能對比
總結下IPVS & IPTables
1.在小規模的集群中，兩者在CPU和響應時間上，差別不大，無論是keep alive 還是non keep alive 。
2.在大規模集群中，兩者會慢慢在響應時間以及CPU上都會出現區別，不過在使用keep alive的情況下，區別還是主要來源于CPU的使用。
3.ipvs 基于散列表，復雜度 O(1)，iptables 基于鏈表，復雜度 O(n)
4.ipvs 支持多種負載均衡調度算法；iptables 只有由 statistic 模塊的 DNAT 支持概率輪詢。
PS：要注意，在微服務的情況下，調用鏈會非常長，兩者影響效果會更顯著一些。
eBPF
什么是eBPF?
Linux內核一直是實現監視/可觀察性，網絡和安全性的理想場所。不幸的是，這通常是不切實際的，因為它需要更改內核源代碼或加載內核模塊，并導致彼此堆疊的抽象層。 eBPF是一項革命性的技術，可以在Linux內核中運行沙盒程序，而無需更改內核源代碼或加載內核模塊。通過使Linux內核可編程，基礎架構軟件可以利用現有的層，從而使它們更加智能和功能豐富，而無需繼續為系統增加額外的復雜性層。
eBPF導致了網絡，安全性，應用程序配置/跟蹤和性能故障排除等領域的新一代工具的開發，這些工具不再依賴現有的內核功能，而是在不影響執行效率或安全性的情況下主動重新編程運行時行為。對于云原生領域，Cilium 已經使用eBPF 實現了無kube-proxy的容器網絡。利用eBPF解決iptables帶來的性能問題。
通過的 eBPF 實現，可以保留原始源 IP，并且可以選擇執行直接服務器返回 (DSR)。即返回流量可以選擇最優路徑，而無需通過原始入口節點環回，如下圖：
簡述流程如下:
- BPF program 將數據發送給 K8s service； 做負載均衡決策并將數據包發送給目的 pod 節點
- BPF program 程序將 DNAT 轉換成 Pod 的IP
- Pod 看到客戶端真正的 IP
- Pod 做出響應； BPF 反向 DNAT
- 如果網絡準許，數據包直接返回。否則將通過 Ingress Node （ingress controller Pod 所在服務器）
性能
網絡吞吐
測試環境：兩臺物理節點，一個發包，一個收包，收到的包做 Service loadbalancing 轉發給后端 Pods。
可以看出：
- Cilium XDP eBPF 模式能處理接收到的全部 10Mpps（packets per second）。
- Cilium tc eBPF 模式能處理 3.5Mpps。
- kube-proxy iptables 只能處理 2.3Mpps，因為它的 hook 點在收發包路徑上更后面的位置。
- kube-proxy ipvs 模式這里表現更差，它相比 iptables 的優勢要在 backend 數量很多的時候才能體現出來。
CPU 利用率
測試生成了 1Mpps、2Mpps 和 4Mpps 流量，空閑 CPU 占比（可以被應用使用的 CPU）結果如下：
結論與上面吞吐類似。
- XDP 性能最好，是因為 XDP BPF 在驅動層執行，不需要將包 push 到內核協議棧。
- kube-proxy 不管是 iptables 還是 ipvs 模式，都在處理軟中斷（softirq）上消耗了大量 CPU。
eBPF簡化服務網格
首先看下Service Mesh
這是一張經典的service mesh圖，在eBPF之前，kubernetes服務網格解決方案是要求我們在每一個應用pod上添加一個代理Sidecar容器，如：Envoy/Linkerd-proxy。
例：即使在一個非常小的環境中，比如說有20個服務，每個服務運行5個pod，分在3個節點上，你也有100個代理容器。無論代理的實現多么小和有效，這種純粹的重復都會浪費資源。每個代理使用的內存與它需要能夠通信的服務數量有關。
問題：
為什么我們需要所有這些 sidecar？這種模式允許代理容器與 pod 中的應用容器共享一個網絡命名空間。網絡命名空間是 Linux 內核的結構，它允許容器和 pod 擁有自己獨立的網絡堆棧，將容器化的應用程序相互隔離。這使得應用之間互不相干，這就是為什么你可以讓盡可能多的 pod 在 80 端口上運行一個 web 應用 —— 網絡命名空間意味著它們各自擁有自己的 80 端口。代理必須共享相同的網絡命名空間，這樣它就可以攔截和處理進出應用容器的流量。
eBPF的sidecar less proxy model
基于eBPF的Cilium項目，最近將這種“無 sidecar”模式帶到了服務網格的世界。除了傳統的 sidecar 模型，Cilium 還支持每個節點使用一個 Envoy 代理實例運行服務網格的數據平面。使用上面的例子，這就把代理實例的數量從 100 個減少到只有 3 個。
支持eBPF的網絡允許數據包走捷徑，繞過內核部分網絡對戰，這可以使kubernetes網絡的性能得到更加顯著的改善，如下圖：
在服務網格的情況，代理在傳統網絡中作為sidecar運行，數據包到達應用程序的路徑相當曲折：入棧數據包必須穿越主機TPC/IP棧，通過虛擬以太網連接到達pod的網絡命名空間。從那里，數據包必須穿過pod的網絡對戰到達代理，代理講數據包通過回環接口轉發到應用程序，考慮到流量必須在連接的兩端流經代理，于非服務網格流量相比，這將導致延遲的顯著增加。
而基于eBPF的kubernetes CNI實現，如Cilium，可以使用eBPF程序，明智的勾住內核中的特定點，沿著更加直接的路線重定向數據包。因為Cilium知道所有的kubernetes斷點和服務的身份。當數據包到達主機時，Cilium 可以將其直接分配到它所要去的代理或 Pod 端點。
總結
通過以上的內容，我想大家對kube-proxy和基于eBPF的CNI插件Cilium已經有了一些了解。可以看到在云原生領域，Cilium 已經使用eBPF 實現了無kube-proxy的容器網絡。利用eBPF解決iptables帶來的性能問題。另外以上也只是介紹了eBPF的網絡方面，其實eBPF在跟蹤、安全、負載均衡、故障分析等領域都是eBPF的主戰場，而且還有更多更多的可能性正在被發掘。
