kube-proxy是任何 Kubernetes 部署中的關(guān)鍵組件。它的作用是將流向服務(wù)（通過(guò)集群 IP 和節(jié)點(diǎn)端口）的流量負(fù)載均衡到正確的后端pod。kube-proxy可以運(yùn)行在三種模式之一，每種模式都使用不同的數(shù)據(jù)平面技術(shù)來(lái)實(shí)現(xiàn)：userspace、iptables 或 IPVS。

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

首先，我們將簡(jiǎn)要介紹這兩種模式的背景，然后深入測(cè)試和結(jié)果……

背景：iptables 代理模式

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

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

背景：IPVS 代理模式

IPVS 是一個(gè)專(zhuān)門(mén)為負(fù)載均衡設(shè)計(jì)的 Linux 內(nèi)核功能。在 IPVS 模式下，kube-proxy通過(guò)編程 IPVS 負(fù)載均衡器來(lái)代替使用 iptables。它同樣使用成熟的內(nèi)核功能，且 IPVS 專(zhuān)為負(fù)載均衡大量服務(wù)而設(shè)計(jì)；它擁有優(yōu)化的 API 和查找例程，而不是一系列順序規(guī)則。

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

此外，作為一個(gè)專(zhuān)用的負(fù)載均衡器，IPVS 擁有多種不同的調(diào)度算法，如輪詢(xún)、最短期望延遲、最少連接數(shù)和各種哈希方法。相比之下，iptables 中的 kube-proxy 使用的是隨機(jī)的等成本選擇算法。

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

性能比較

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

在大多數(shù)情況下，涉及應(yīng)用程序和微服務(wù)時(shí)，kube-proxy性能有兩個(gè)關(guān)鍵屬性可能是您關(guān)心的：

• 對(duì)往返響應(yīng)時(shí)間的影響：當(dāng)一個(gè)微服務(wù)向另一個(gè)微服務(wù)發(fā)出 API 調(diào)用時(shí)，平均而言第一個(gè)微服務(wù)發(fā)送請(qǐng)求并從第二個(gè)微服務(wù)接收響應(yīng)需要多長(zhǎng)時(shí)間？
• 對(duì)總 CPU 使用率的影響：在運(yùn)行微服務(wù)時(shí)，包括用戶(hù)空間和內(nèi)核/系統(tǒng)使用在內(nèi)的主機(jī)總 CPU 使用率是多少？這包括了支持微服務(wù)所需的所有進(jìn)程，包括 kube-proxy。

為了說(shuō)明這一點(diǎn)，我們?cè)谝粋€(gè)專(zhuān)用節(jié)點(diǎn)上運(yùn)行了一個(gè)clinet微服務(wù)pod，每秒生成 1000 個(gè)請(qǐng)求，發(fā)送到由 10 個(gè)service微服務(wù)pod支持的 Kubernetes 服務(wù)。然后，我們?cè)趇ptables和IPVS模式下，在客戶(hù)端節(jié)點(diǎn)上測(cè)量了性能，使用了各種數(shù)量的 Kubernetes 服務(wù)，每個(gè)服務(wù)有10個(gè)pod支持，最多達(dá)到 10,000 個(gè)服務(wù)（即 100,000 個(gè)服務(wù)后端）。對(duì)于微服務(wù)，我們使用golang編寫(xiě)的簡(jiǎn)單測(cè)試工具作為我們的客戶(hù)端微服務(wù)，并使用標(biāo)準(zhǔn)NGINX作為服務(wù)器微服務(wù)的后端pods。

往返響應(yīng)時(shí)間

在考慮往返響應(yīng)時(shí)間時(shí)，理解連接和請(qǐng)求之間的區(qū)別非常重要。通常，大多數(shù)微服務(wù)將使用持久連接或“keepalive”連接，這意味著每個(gè)連接會(huì)在多個(gè)請(qǐng)求之間重復(fù)使用，而不是每個(gè)請(qǐng)求都需要新建一個(gè)連接。這一點(diǎn)很重要，因?yàn)榇蠖鄶?shù)新連接都需要在網(wǎng)絡(luò)上進(jìn)行三次握手（這需要時(shí)間），并且在 Linux 網(wǎng)絡(luò)棧內(nèi)進(jìn)行更多處理（這也需要一點(diǎn)時(shí)間和 CPU 資源）。

為了說(shuō)明這些差異，我們?cè)谟泻蜎](méi)有 keepalive 連接的情況下進(jìn)行了測(cè)試。對(duì)于 keepalive 連接，我們使用了 NGINX 的默認(rèn)配置，該配置會(huì)將每個(gè)連接保持活躍狀態(tài)以供最多 100 個(gè)請(qǐng)求重復(fù)使用。請(qǐng)參見(jiàn)下圖，注意響應(yīng)時(shí)間越低越好。

圖表顯示了兩個(gè)關(guān)鍵點(diǎn)：

• 在超過(guò) 1,000 個(gè)服務(wù)（10,000 個(gè)后端 pod）之前，iptables 和 IPVS 之間的平均往返響應(yīng)時(shí)間差異微不足道。
• 平均往返響應(yīng)時(shí)間的差異僅在不使用 keepalive 連接時(shí)才明顯。也就是說(shuō)，當(dāng)每個(gè)請(qǐng)求都使用新連接時(shí)，差異才會(huì)顯現(xiàn)。

對(duì)于 iptables 和 IPVS 模式，kube-proxy 的響應(yīng)時(shí)間開(kāi)銷(xiāo)與建立連接有關(guān)，而不是與連接上的數(shù)據(jù)包或請(qǐng)求數(shù)量有關(guān)。這是因?yàn)?Linux 使用連接跟蹤（conntrack），能夠非常高效地將數(shù)據(jù)包匹配到現(xiàn)有連接。如果數(shù)據(jù)包在 conntrack 中被匹配到，就不需要通過(guò) kube-proxy 的 iptables 或 IPVS 規(guī)則來(lái)決定如何處理它。

值得注意的是，在這個(gè)例子中，“服務(wù)器”微服務(wù)使用的是 NGINX pod 提供一個(gè)小的靜態(tài)響應(yīng)體。許多微服務(wù)需要做的工作遠(yuǎn)不止這些，這將導(dǎo)致相應(yīng)更高的響應(yīng)時(shí)間，這意味著 kube-proxy 處理的時(shí)間差在這種圖表中將占據(jù)更小的百分比。

最后有一個(gè)奇怪現(xiàn)象需要解釋?zhuān)簽槭裁丛?10,000 個(gè)服務(wù)時(shí)，非 keepalive 連接的響應(yīng)時(shí)間在 IPVS 模式下變得更慢，即使 IPVS 中新連接的處理復(fù)雜度是 O(1)？要真正深入了解這一點(diǎn)，我們需要進(jìn)行更多的挖掘，但其中一個(gè)因素是整個(gè)系統(tǒng)由于主機(jī)上增加的 CPU 使用而變得更慢。這也引出了下一個(gè)話題。

總CPU使用率

為了說(shuō)明總 CPU 使用率，下面的圖表集中在不使用持久/keepalive 連接的最壞情況下，此時(shí) kube-proxy 連接處理的開(kāi)銷(xiāo)影響最大。

圖表顯示了兩個(gè)關(guān)鍵點(diǎn)：

• 在超過(guò) 1,000 個(gè)服務(wù)（10,000 個(gè)后端 pod）之前，iptables 和 IPVS 之間的 CPU 使用率差異相對(duì)不顯著。
• 在 10,000 個(gè)服務(wù)（100,000 個(gè)后端 pod）時(shí)，iptables 的 CPU 增加約為一個(gè)內(nèi)核的 35%，而 IPVS 增加約為一個(gè)內(nèi)核的 8%。

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

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

值得注意的是，在這個(gè)例子中，“客戶(hù)端”微服務(wù)簡(jiǎn)單地丟棄了從“服務(wù)器”微服務(wù)接收到的每個(gè)響應(yīng)。一個(gè)實(shí)際的微服務(wù)需要做的工作遠(yuǎn)不止這些，這將增加圖表中的基礎(chǔ) CPU 使用率，但不會(huì)改變與服務(wù)數(shù)量相關(guān)的 CPU 增加的絕對(duì)值。

結(jié)論

在顯著超過(guò) 1,000 個(gè)服務(wù)的規(guī)模下，kube-proxy 的 IPVS 模式可以提供一些不錯(cuò)的性能提升。具體效果可能有所不同，但一般來(lái)說(shuō)，對(duì)于使用持久“keepalive”連接風(fēng)格的微服務(wù)，且運(yùn)行在現(xiàn)代內(nèi)核上的情況下，這些性能提升可能相對(duì)有限。對(duì)于不使用持久連接的微服務(wù)，或者在較舊內(nèi)核上運(yùn)行時(shí)，切換到 IPVS 模式可能會(huì)帶來(lái)顯著的收益。

除了性能方面的考慮外，如果您需要比 kube-proxy 的 iptables 模式的隨機(jī)負(fù)載均衡更復(fù)雜的負(fù)載均衡調(diào)度算法，也應(yīng)該考慮使用 IPVS 模式。

如果您不確定 IPVS 是否會(huì)對(duì)您有利，那么堅(jiān)持使用 kube-proxy 的 iptables 模式。它已經(jīng)經(jīng)過(guò)大量的生產(chǎn)環(huán)境驗(yàn)證，盡管并不完美，但可以說(shuō)它作為默認(rèn)選擇是有原因的。

比較 kube-proxy 和 Calico 對(duì) iptables 的使用

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

即使在完全擴(kuò)展的集群中運(yùn)行，擁有 10,000 個(gè)服務(wù)和 100,000 個(gè)后端 pod 時(shí)，Calico 每個(gè)連接執(zhí)行的 iptables 規(guī)則數(shù)量大致與 kube-proxy 在擁有 20 個(gè)服務(wù)和 200 個(gè)后端 pod 時(shí)執(zhí)行的規(guī)則數(shù)量相同。換句話說(shuō)，Calico 對(duì) iptables 的使用是可擴(kuò)展的！