iptables與IPVS選哪個好

本篇內(nèi)容主要講解“iptables與IPVS選哪個好”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“iptables與IPVS選哪個好”吧!

kube-proxy 是 Kubernetes 中的關(guān)鍵組件。他的角色就是在服務(wù)（ClusterIP 和 NodePort）和其后端 Pod 之間進(jìn)行負(fù)載均衡。kube-proxy 有三種運(yùn)行模式，每種都有不同的實現(xiàn)技術(shù)： userspace 、 iptables 或者 IPVS 。

背景：iptables 模式

iptables 是一個 Linux 內(nèi)核功能，是一個高效的防火墻，并提供了大量的數(shù)據(jù)包處理和過濾方面的能力。它可以在核心數(shù)據(jù)包處理管線上用 Hook 掛接一系列的規(guī)則。iptables 模式中 kube-proxy 在 NAT pre-routing Hook 中實現(xiàn)它的 NAT 和負(fù)載均衡功能。這種方法簡單有效，依賴于成熟的內(nèi)核功能，并且能夠和其它跟 iptables 協(xié)作的應(yīng)用（例如 Calico）融洽相處。

然而 kube-proxy 的用法是一種 O(n) 算法，其中的 n 隨集群規(guī)模同步增長，這里的集群規(guī)模，更明確的說就是服務(wù)和后端 Pod 的數(shù)量。

背景：IPVS 模式

IPVS 是一個用于負(fù)載均衡的 Linux 內(nèi)核功能。IPVS 模式下，kube-proxy 使用 IPVS 負(fù)載均衡代替了 iptable。這種模式同樣有效，IPVS 的設(shè)計就是用來為大量服務(wù)進(jìn)行負(fù)載均衡的，它有一套優(yōu)化過的 API，使用優(yōu)化的查找算法，而不是簡單的從列表中查找規(guī)則。

這樣一來，kube-proxy 在 IPVS 模式下，其連接過程的復(fù)雜度為 O(1)。換句話說，多數(shù)情況下，他的連接處理效率是和集群規(guī)模無關(guān)的。

另外作為一個獨立的負(fù)載均衡器，IPVS 包含了多種不同的負(fù)載均衡算法，例如輪詢、最短期望延遲、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機(jī)平等的選擇算法。

IPVS 的一個潛在缺點就是，IPVS 處理數(shù)據(jù)包的路徑和通常情況下 iptables 過濾器的路徑是不同的。如果計劃在有其他程序使用 iptables 的環(huán)境中使用 IPVS，需要進(jìn)行一些研究，看看他們是否能夠協(xié)調(diào)工作。（Calico 已經(jīng)和 IPVS kube-proxy 兼容）

性能對比

iptables 的連接處理算法復(fù)雜度是 O(n)，而 IPVS 模式是 O(1)，但是在微服務(wù)環(huán)境中，其具體表現(xiàn)如何呢？

在多數(shù)場景中，有兩個關(guān)鍵屬性需要關(guān)注：

• 響應(yīng)時間：一個微服務(wù)向另一個微服務(wù)發(fā)起調(diào)用時，第一個微服務(wù)發(fā)送請求，并從第二個微服務(wù)中得到響應(yīng)，中間消耗了多少時間？

• CPU 消耗：運(yùn)行微服務(wù)的過程中，總體 CPU 使用情況如何？包括用戶和核心空間的 CPU 使用，包含所有用于支持微服務(wù)的進(jìn)程（也包括 kube-proxy）。

為了說明問題，我們運(yùn)行一個微服務(wù)作為客戶端，這個微服務(wù)以 Pod 的形式運(yùn)行在一個獨立的節(jié)點上，每秒鐘發(fā)出 1000 個請求，請求的目標(biāo)是一個 Kubernetes 服務(wù)，這個服務(wù)由 10 個 Pod 作為后端，運(yùn)行在其它的節(jié)點上。接下來我們在客戶端節(jié)點上進(jìn)行了測量，包括 iptables 以及 IPVS 模式，運(yùn)行了數(shù)量不等的 Kubernetes 服務(wù)，每個服務(wù)都有 10 個 Pod，最大有 10,000 個服務(wù)（也就是 100,000 個 Pod）。我們用 golang 編寫了一個簡單的測試工具作為客戶端，用標(biāo)準(zhǔn)的 NGINX 作為后端服務(wù)。

響應(yīng)時間

響應(yīng)時間很重要，有助于我們理解連接和請求的差異。典型情況下，多數(shù)微服務(wù)都會使用持久或者 keepalive 連接，這意味著每個連接都會被多個請求復(fù)用，而不是每個請求一次連接。這很重要，因為多數(shù)連接的新建過程都需要完成三次 TCP 握手的過程，這需要消耗時間，也需要在 Linux 網(wǎng)絡(luò)棧中進(jìn)行更多操作，也就會消耗更多 CPU 和時間。

這張圖展示了兩個關(guān)鍵點：

• iptables 和 IPVS 的平均響應(yīng)時間在 1000 個服務(wù)（10000 個 Pod）以上時，會開始觀察到差異。

• 只有在每次請求都發(fā)起新連接的情況下，兩種模式的差異才比較明顯。

不管是 iptables 還是 IPVS，kube-proxy 的響應(yīng)時間開銷都是和建立連接的數(shù)量相關(guān)的，而不是數(shù)據(jù)包或者請求數(shù)量，這是因為 Linux 使用了 Conntrack，能夠高效地將數(shù)據(jù)包和現(xiàn)存連接關(guān)聯(lián)起來。如果數(shù)據(jù)包能夠被 Conntrack 成功匹配，那就不需要通過 kube-proxy 的 iptables 或 IPVS 規(guī)則來推算去向。Linux conntrack 非常棒?。ń^大多數(shù)時候）

值得注意的是，例子中的服務(wù)端微服務(wù)使用 NGINX 提供一個靜態(tài)小頁面。多數(shù)微服務(wù)要做更多操作，因此會產(chǎn)生更高的響應(yīng)時間，也就是 kube-proxy 處理過程在總體時間中的占比會減少。

還有個需要解釋的古怪問題：既然 IPVS 的連接過程復(fù)雜度是 O(1)，為什么在 10,000 服務(wù)的情況下，非 Keepalive 的響應(yīng)時間還是提高了？我們需要深入挖掘更多內(nèi)容才能解釋這一問題，但是其中一個因素就是因為上升的 CPU 用量拖慢了整個系統(tǒng)。這就是下一個主題需要探究的內(nèi)容。

CPU 用量

為了描述 CPU 用量，下圖關(guān)注的是最差情況：不使用持久/keepalive 連接的情況下，kube-proxy 會有最大的處理開銷。

上圖說明了兩件事：

• 在超過 1000 個服務(wù)（也就是 10,000 個 Pod）的情況下，CPU 用量差異才開始明顯。

• 在一萬個服務(wù)的情況下（十萬個后端 Pod），iptables 模式增長了 0.35 個核心的占用，而 IPVS 模式僅增長了 8%。

有兩個主要因素造成 CPU 用量增長：

第一個因素是，缺省情況下 kube-proxy 每 30 秒會用所有服務(wù)對內(nèi)核重新編程。這也解釋了為什么 IPVS 模式下，新建連接的 O(1) 復(fù)雜度也仍然會產(chǎn)生更多的 CPU 占用。另外，如果是舊版本內(nèi)核，重新編程 iptables 的 API 會更慢。所以如果你用的內(nèi)核較舊，iptables 模式可能會占用更多的 CPU。

另一個因素是，kube-proxy 使用 IPVS 或者 iptables 處理新連接的消耗。對 iptables 來說，通常是 O(n) 的復(fù)雜度。在存在大量服務(wù)的情況下，會出現(xiàn)顯著的 CPU 占用升高。例如在 10,000 服務(wù)（100,000 個后端 Pod）的情況下，iptables 會為每個請求的每個連接處理大約 20000 條規(guī)則。如果使用 NINGX 缺省每連接 100 請求的 keepalive 設(shè)置，kube-proxy 的 iptables 規(guī)則執(zhí)行次數(shù)會減少為 1%，會把 iptables 的 CPU 消耗降低到和 IPVS 類似的水平。

客戶端微服務(wù)會簡單的丟棄響應(yīng)內(nèi)容。真實世界中自然會進(jìn)行更多處理，也會造成更多的 CPU 消耗，但是不會影響 CPU 消耗隨服務(wù)數(shù)量增長的事實。

結(jié)論

在超過 1000 服務(wù)的規(guī)模下，kube-proxy 的 IPVS 模式會有更好的性能表現(xiàn)。雖然可能有多種不同情況，但是通常來說，讓微服務(wù)使用持久連接、運(yùn)行現(xiàn)代內(nèi)核，也能取得較好的效果。如果運(yùn)行的內(nèi)核較舊，或者無法使用持久連接，那么 IPVS 模式可能是個更好的選擇。

拋開性能問題不談，IPVS 模式還有個好處就是具有更多的負(fù)載均衡算法可供選擇。

如果你還不確定 IPVS 是否合適，那就繼續(xù)使用 iptables 模式好了。這種傳統(tǒng)模式有大量的生產(chǎn)案例支撐，他是一個不完美的缺省選項。

補(bǔ)充：Calico 和 kube-proxy 的 iptables 比較

本文中我們看到，kube-proxy 中的 iptables 用法在大規(guī)模集群中可能會產(chǎn)生性能問題。有人問我 Calico 為什么沒有類似的問題。答案是 Calico 中 kube-proxy 的用法是不同的。kube-proxy 使用了一個很長的規(guī)則鏈條，鏈條長度會隨著集群規(guī)模而增長，Calico 使用的是一個很短的優(yōu)化過的規(guī)則鏈，經(jīng)由 ipsets 的加持，也具備了 O(1) 復(fù)雜度的查詢能力。

下圖證明了這一觀點，其中展示了每次連接過程中，kube-proxy 和 Calico 中 iptables 規(guī)則數(shù)量的平均值。這里假設(shè)集群中的節(jié)點平均有 30 個 Pod，每個 Pod 具有 3 個網(wǎng)絡(luò)規(guī)則。

即使是使用 10,000 個服務(wù)和 100,000 個 Pod 的情況下，Calico 每連接執(zhí)行的 iptables 規(guī)則也只是和 kube-proxy 在 20 服務(wù) 200 個 Pod 的情況基本一致。

到此，相信大家對“iptables與IPVS選哪個好”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！