Kube-Proxy中使用Ipvs與Iptables的比較

作者：沒有文案的夏老師 2021-10-13 16:00:53

kube-proxy 就可以通過 Service 的 Informer 感知到API Server中service和endpoint的變化情況。而作為對這個事件的響應(yīng)，它就會在宿主機(jī)上創(chuàng)建這樣一條 iptables 規(guī)則(你可以通過 iptables-save 看到它)。

[[428642]]

本文轉(zhuǎn)載自微信公眾號「運維開發(fā)故事」，作者沒有文案的夏老師。轉(zhuǎn)載本文請聯(lián)系運維開發(fā)故事公眾號。

Iptables模式

kube-proxy 就可以通過 Service 的 Informer 感知到API Server中service和endpoint的變化情況。而作為對這個事件的響應(yīng)，它就會在宿主機(jī)上創(chuàng)建這樣一條 iptables 規(guī)則(你可以通過 iptables-save 看到它)。這些規(guī)則捕獲到service的clusterIP和port的流量，并將這些流量隨機(jī)重定向到service后端Pod。對于每個endpoint對象，它生成選擇后端Pod的iptables規(guī)則。

如果選擇的第一個Pod沒有響應(yīng)，kube-proxy將檢測到到第一個Pod的連接失敗，并將自動重試另一個后端Pod。拓?fù)鋱D：

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)用融洽相處。

因為它純粹是為防火墻而設(shè)計且基于內(nèi)核規(guī)則列表，kube-proxy 使用的是一種 O(n) 算法，其中的 n 隨集群規(guī)模同步增長，所以這里的集群規(guī)模越大，更明確的說就是服務(wù)和后端 Pod 的數(shù)量越大，查詢的時間就會越長。

一個例子是，在5000節(jié)點集群中使用 NodePort 服務(wù)，如果我們有2000個服務(wù)并且每個服務(wù)有10個 pod，這將在每個工作節(jié)點上至少產(chǎn)生20000個 iptable 記錄，這會使內(nèi)核非常繁忙。

結(jié)論：

kube-proxy 通過 iptables 處理 Service 的過程，其實需要在宿主機(jī)上設(shè)置相當(dāng)多的 iptables 規(guī)則。而且，kube-proxy 還需要在控制循環(huán)里不斷地刷新這些規(guī)則來確保它們始終是正確的。不難想到，當(dāng)你的宿主機(jī)上有大量 Pod 的時候，成百上千條 iptables 規(guī)則不斷地被刷新，會大量占用該宿主機(jī)的 CPU 資源，甚至?xí)屗拗鳈C(jī)“卡”在這個過程中。所以說，一直以來，基于 iptables 的 Service 實現(xiàn)，都是制約 Kubernetes 項目承載更多量級的 Pod 的主要障礙。

ipvs模式

在 IPVS 模式下，kube-proxy監(jiān)視Kubernetes服務(wù)和端點，調(diào)用 netlink 接口創(chuàng)建 IPVS 規(guī)則，并定期將 IPVS 規(guī)則與 Kubernetes 服務(wù)和端點同步。訪問服務(wù)時，IPVS 將流量定向到后端Pod之一。IPVS代理模式基于類似于 iptables 模式的 netfilter 掛鉤函數(shù)，但是使用哈希表作為基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，并且在內(nèi)核空間中工作。這意味著，與 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延遲要短，并且在同步代理規(guī)則時具有更好的性能。與其他代理模式相比，IPVS 模式還支持更高的網(wǎng)絡(luò)流量吞吐量。

IPVS 模式的工作原理，其實跟 iptables 模式類似。當(dāng)我們創(chuàng)建了前面的 Service 之后，kube-proxy 首先會在宿主機(jī)上創(chuàng)建一個虛擬網(wǎng)卡(叫作：kube-ipvs0)，并為它分配 Service VIP 作為 IP 地址。接下來，kube-proxy 就會通過 Linux 的 IPVS 模塊，為這個 IP 地址設(shè)置三個 IPVS 虛擬主機(jī)，并設(shè)置這三個虛擬主機(jī)之間使用輪詢模式 (rr) 來作為負(fù)載均衡策略。拓?fù)鋱D如下所示拓?fù)鋱D：

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一個潛在缺點是，與正常情況下的數(shù)據(jù)包相比，由IPVS處理的數(shù)據(jù)包通過iptables篩選器hook的路徑不同。如果打算將IPVS與其他使用iptables的程序一起使用，則需要研究它們是否可以一起正常工作。不過Ipvs代理模式已經(jīng)推出很久了，很多組件已經(jīng)適配的很好了，比如Calico。

結(jié)論：

IPVS是專門設(shè)計用來做內(nèi)核四層負(fù)載均衡的，由于使用了hash表的數(shù)據(jù)結(jié)構(gòu)，因此相比iptables來說性能會更好。基于IPVS實現(xiàn)Service轉(zhuǎn)發(fā)，Kubernetes幾乎能夠具備無限的水平擴(kuò)展能力。隨著Kubernetes的部署規(guī)模越來越大，應(yīng)用越來越廣泛，IPVS必然會取代iptables成為Kubernetes Service的默認(rèn)實現(xiàn)后端。

總結(jié)

IPVS (IP Virtual Server，IP虛擬服務(wù)器)是基于Netfilter的、作為linux內(nèi)核的一部分實現(xiàn)傳輸層負(fù)載均衡的技術(shù)，通常稱為第4層LAN交換。IPVS集成在LVS(Linux Virtual Server)中，它在主機(jī)中運行，并在真實服務(wù)器集群前充當(dāng)負(fù)載均衡器。IPVS可以將對TCP/UDP服務(wù)的請求轉(zhuǎn)發(fā)給后端的真實服務(wù)器，并使真實服務(wù)器的服務(wù)在單個IP地址上顯示為虛擬服務(wù)。因此IPVS天然支持Kubernetes Service。

隨著kubernetes使用量的增長，其資源的可擴(kuò)展性變得越來越重要。特別是對于使用kubernetes運行大型工作負(fù)載的開發(fā)人員或者公司來說，service的可擴(kuò)展性至關(guān)重要。kube-proxy是為service構(gòu)建路由規(guī)則的模塊，之前依賴iptables來實現(xiàn)主要service類型的支持，比如(ClusterIP和NodePort)。但是iptables很難支持上萬級的service，因為iptables純粹是為防火墻而設(shè)計的，并且底層數(shù)據(jù)結(jié)構(gòu)是內(nèi)核規(guī)則的列表。
而相比于 iptables，IPVS 在內(nèi)核中的實現(xiàn)其實也是基于 Netfilter 的 NAT 模式，所以在轉(zhuǎn)發(fā)這一層上，理論上 IPVS 并沒有顯著的性能提升。但是，IPVS 并不需要在宿主機(jī)上為每個 Pod 設(shè)置 iptables 規(guī)則，而是把對這些“規(guī)則”的處理放到了內(nèi)核態(tài)，從而極大地降低了維護(hù)這些規(guī)則的代價。
kubernetes早在1.6版本就已經(jīng)有能力支持5000多節(jié)點，這樣基于iptables的kube-proxy就成為集群擴(kuò)容到5000節(jié)點的瓶頸。舉例來說，如果在一個5000節(jié)點的集群，我們創(chuàng)建2000個service，并且每個service有10個pod，那么我們就會在每個節(jié)點上有至少20000條iptables規(guī)則，這會導(dǎo)致內(nèi)核非常繁忙。基于IPVS的集群內(nèi)負(fù)載均衡就可以完美的解決這個問題。IPVS是專門為負(fù)載均衡設(shè)計的，并且底層使用哈希表這種非常高效的數(shù)據(jù)結(jié)構(gòu)，幾乎可以允許無限擴(kuò)容。不過需要注意的是，IPVS 模塊只負(fù)責(zé)上述的負(fù)載均衡和代理功能。而一個完整的 Service 流程正常工作所需要的包過濾、SNAT 等操作，還是要靠 iptables 來實現(xiàn)。只不過，這些輔助性的 iptables 規(guī)則數(shù)量有限，也不會隨著 Pod 數(shù)量的增加而增加。

IPVS模式在Kubernetes v1.8中引入，并在v1.9中進(jìn)入了beta。1.11中實現(xiàn)了GA(General Availability)。IPTABLES模式在v1.1中添加，并成為自v1.2以來的默認(rèn)操作模式。IPVS和IPTABLES都基于netfilter。IPVS模式和IPTABLES模式之間的差異如下：

IPVS為大型集群提供了更好的可擴(kuò)展性和性能。(規(guī)則的存儲方式使用的數(shù)據(jù)結(jié)構(gòu)更高效)
IPVS支持比iptables更復(fù)雜的負(fù)載平衡算法(rr：循環(huán)，lc：最少連接，dh：目標(biāo)散列，sh：源哈希，sed：最短的預(yù)期延遲，nq：從不排隊)。
IPVS支持服務(wù)器健康檢查和連接重試等。

在集群中不超過1000個服務(wù)的時候，iptables 和 ipvs 并無太大的差異。而且由于iptables 與網(wǎng)絡(luò)策略實現(xiàn)的良好兼容性，iptables 是個非常好的選擇。當(dāng)你的集群服務(wù)超過1000個時，而且服務(wù)之間鏈接大多沒有開啟keepalive，IPVS模式可能是一個不錯的選擇。

參考文章：

https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/

https://cloud.tencent.com/developer/article/1470033

https://blog.csdn.net/qq_36807862/article/details/106068871

責(zé)任編輯：武曉燕來源：運維開發(fā)故事