kube-proxy是任何 Kubernetes 部署中的關鍵組件。它的作用是將流向服務（通過集群 IP 和節點端口）的流量負載均衡到正確的后端pod。kube-proxy可以運行在三種模式之一，每種模式都使用不同的數據平面技術來實現：userspace、iptables 或 IPVS。

userspace 模式非常舊且慢，絕對不推薦！但是，應該如何權衡選擇 iptables 還是 IPVS 模式呢？在本文中，我們將比較這兩種模式，在實際的微服務環境中衡量它們的性能，并解釋在何種情況下你可能會選擇其中一種。

首先，我們將簡要介紹這兩種模式的背景，然后深入測試和結果……

背景：iptables 代理模式

iptables 是一個 Linux 內核功能，旨在成為一個高效的防火墻，具有足夠的靈活性來處理各種常見的數據包操作和過濾需求。它允許將靈活的規則序列附加到內核數據包處理管道中的各個鉤子上。在 iptables 模式下，kube-proxy將規則附加到 “NAT pre-routing” 鉤子上，以實現其 NAT 和負載均衡功能。這種方式可行，簡單，使用成熟的內核功能，并且與其他使用 iptables 進行過濾的程序（例如 Calico）能夠很好地兼容。

然而，kube-proxy 編程 iptables 規則的方式意味著它名義上是一個 O(n) 風格的算法，其中 n 大致與集群規模成正比（更準確地說，是與服務的數量和每個服務背后的后端 pod 數量成正比）。

背景：IPVS 代理模式

IPVS 是一個專門為負載均衡設計的 Linux 內核功能。在 IPVS 模式下，kube-proxy通過編程 IPVS 負載均衡器來代替使用 iptables。它同樣使用成熟的內核功能，且 IPVS 專為負載均衡大量服務而設計；它擁有優化的 API 和查找例程，而不是一系列順序規則。

結果是，在 IPVS 模式下，kube-proxy 的連接處理具有名義上的 O(1) 計算復雜度。換句話說，在大多數情況下，它的連接處理性能將保持恒定，而不受集群規模的影響。

此外，作為一個專用的負載均衡器，IPVS 擁有多種不同的調度算法，如輪詢、最短期望延遲、最少連接數和各種哈希方法。相比之下，iptables 中的 kube-proxy 使用的是隨機的等成本選擇算法。

IPVS 的一個潛在缺點是，通過 IPVS 處理的數據包在 iptables 過濾鉤子中的路徑與正常情況下的數據包非常不同。如果計劃將 IPVS 與其他使用 iptables 的程序一起使用，則需要研究它們是否能夠預期地協同工作。（別擔心，Calico 早在很久以前就已經與 IPVS kube-proxy 兼容了！）

性能比較

好的，從名義上來說，kube-proxy在 iptables 模式下的連接處理是 O(n) 復雜度，而在 IPVS 模式下是 O(1) 復雜度。但在實際微服務環境中，這意味著什么呢？

在大多數情況下，涉及應用程序和微服務時，kube-proxy性能有兩個關鍵屬性可能是您關心的：

1. 對往返響應時間的影響：當一個微服務向另一個微服務發出 API 調用時，平均而言第一個微服務發送請求并從第二個微服務接收響應需要多長時間？
2. 對總 CPU 使用率的影響：在運行微服務時，包括用戶空間和內核/系統使用在內的主機總 CPU 使用率是多少？這包括了支持微服務所需的所有進程，包括 kube-proxy。

為了說明這一點，我們在一個專用節點上運行了一個“客戶端”微服務 pod，每秒生成 1000 個請求，發送到由 10 個“服務器”微服務 pod 支持的 Kubernetes 服務。然后，我們在 iptables 和 IPVS 模式下，在客戶端節點上測量了性能，使用了各種數量的 Kubernetes 服務，每個服務有 10 個 pod 支持，最多達到 10,000 個服務（即 100,000 個服務后端）。對于微服務，我們使用golang編寫的簡單測試工具作為我們的客戶端微服務，并使用標準NGINX作為服務器微服務的后端pods。

往返響應時間

在考慮往返響應時間時，理解連接和請求之間的區別非常重要。通常，大多數微服務將使用持久連接或“keepalive”連接，這意味著每個連接會在多個請求之間重復使用，而不是每個請求都需要新建一個連接。這一點很重要，因為大多數新連接都需要在網絡上進行三次握手（這需要時間），并且在 Linux 網絡棧內進行更多處理（這也需要一點時間和 CPU 資源）。

為了說明這些差異，我們在有和沒有 keepalive 連接的情況下進行了測試。對于 keepalive 連接，我們使用了 NGINX 的默認配置，該配置會將每個連接保持活躍狀態以供最多 100 個請求重復使用。請參見下圖，注意響應時間越低越好。

圖表顯示了兩個關鍵點：

1. 在超過 1,000 個服務（10,000 個后端 pod）之前，iptables 和 IPVS 之間的平均往返響應時間差異微不足道。
2. 平均往返響應時間的差異僅在不使用 keepalive 連接時才明顯。也就是說，當每個請求都使用新連接時，差異才會顯現。

對于 iptables 和 IPVS 模式，kube-proxy 的響應時間開銷與建立連接有關，而不是與連接上的數據包或請求數量有關。這是因為 Linux 使用連接跟蹤（conntrack），能夠非常高效地將數據包匹配到現有連接。如果數據包在 conntrack 中被匹配到，就不需要通過 kube-proxy 的 iptables 或 IPVS 規則來決定如何處理它。

值得注意的是，在這個例子中，“服務器”微服務使用的是 NGINX pod 提供一個小的靜態響應體。許多微服務需要做的工作遠不止這些，這將導致相應更高的響應時間，這意味著 kube-proxy 處理的時間差在這種圖表中將占據更小的百分比。

最后有一個奇怪現象需要解釋：為什么在 10,000 個服務時，非 keepalive 連接的響應時間在 IPVS 模式下變得更慢，即使 IPVS 中新連接的處理復雜度是 O(1)？要真正深入了解這一點，我們需要進行更多的挖掘，但其中一個因素是整個系統由于主機上增加的 CPU 使用而變得更慢。這也引出了下一個話題。

總CPU使用率

為了說明總 CPU 使用率，下面的圖表集中在不使用持久/keepalive 連接的最壞情況下，此時 kube-proxy 連接處理的開銷影響最大。

圖表顯示了兩個關鍵點：

1. 在超過 1,000 個服務（10,000 個后端 pod）之前，iptables 和 IPVS 之間的 CPU 使用率差異相對不顯著。
2. 在 10,000 個服務（100,000 個后端 pod）時，iptables 的 CPU 增加約為一個內核的 35%，而 IPVS 增加約為一個內核的 8%。

有兩個主要因素影響這種 CPU 使用模式。
第一個因素是，默認情況下，kube-proxy 每 30 秒重新編程一次內核中的所有服務。這解釋了為什么即使 IPVS 的新連接處理名義上是 O(1) 復雜度，IPVS 模式下的 CPU 也會略有增加。此外，較早版本內核中重新編程 iptables 的 API 速度比現在慢得多。因此，如果您在 iptables 模式下使用舊版內核，CPU 增長將比圖表中顯示的更高。

第二個因素是 kube-proxy 使用 iptables 或 IPVS 處理新連接所需的時間。對于 iptables，這在名義上是 O(n) 復雜度。在大量服務的情況下，這對 CPU 使用有顯著影響。例如，在 10,000 個服務（100,000 個后端 pod）時，iptables 每個新連接執行約 20,000 條規則。不過，請記住，在這個圖表中，我們展示的是每個請求都使用新連接的最壞情況。如果我們使用 NGINX 默認的每個連接 100 次 keepalive 請求，那么 kube-proxy 的 iptables 規則執行頻率將減少 100 倍，從而大大降低使用 iptables 而非 IPVS 的 CPU 影響，接近一個內核的 2%。

值得注意的是，在這個例子中，“客戶端”微服務簡單地丟棄了從“服務器”微服務接收到的每個響應。一個實際的微服務需要做的工作遠不止這些，這將增加圖表中的基礎 CPU 使用率，但不會改變與服務數量相關的 CPU 增加的絕對值。

結論

在顯著超過 1,000 個服務的規模下，kube-proxy 的 IPVS 模式可以提供一些不錯的性能提升。具體效果可能有所不同，但一般來說，對于使用持久“keepalive”連接風格的微服務，且運行在現代內核上的情況下，這些性能提升可能相對有限。對于不使用持久連接的微服務，或者在較舊內核上運行時，切換到 IPVS 模式可能會帶來顯著的收益。

除了性能方面的考慮外，如果您需要比 kube-proxy 的 iptables 模式的隨機負載均衡更復雜的負載均衡調度算法，也應該考慮使用 IPVS 模式。

如果您不確定 IPVS 是否會對您有利，那么堅持使用 kube-proxy 的 iptables 模式。它已經經過大量的生產環境驗證，盡管并不完美，但可以說它作為默認選擇是有原因的。

比較 kube-proxy 和 Calico 對 iptables 的使用

在本文中，我們看到 kube-proxy 使用 iptables 在非常大規模時會導致性能影響。我有時會被問到，為什么 Calico 沒有遇到同樣的挑戰。答案是 Calico 對 iptables 的使用與 kube-proxy 有顯著不同。kube-proxy 使用了一條非常長的規則鏈，其長度大致與集群規模成正比，而 Calico 使用的是非常短且優化的規則鏈，并廣泛使用 ipsets，其查找時間復雜度為 O(1)，不受其大小影響。
為了更好地理解這一點，下面的圖表顯示了在集群中的節點平均托管 30 個 pod，且集群中的每個 pod 平均適用 3 個網絡策略的情況下，每個連接由 kube-proxy 和 Calico 執行的 iptables 規則的平均數量。

即使在完全擴展的集群中運行，擁有 10,000 個服務和 100,000 個后端 pod 時，Calico 每個連接執行的 iptables 規則數量大致與 kube-proxy 在擁有 20 個服務和 200 個后端 pod 時執行的規則數量相同。換句話說，Calico 對 iptables 的使用是可擴展的！