建站
咨詢
售后
建站咨詢
新聞中心
[[428642]]
本文轉載自微信公眾號「運維開發(fā)故事」，作者沒有文案的夏老師 。轉載本文請聯(lián)系運維開發(fā)故事公眾號。
我們提供的服務有：成都做網站、網站制作、微信公眾號開發(fā)、網站優(yōu)化、網站認證、東陽ssl等。為成百上千企事業(yè)單位解決了網站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的東陽網站制作公司
Iptables模式
kube-proxy 就可以通過 Service 的 Informer 感知到API Server中service和endpoint的變化情況。而作為對這個事件的響應，它就會在宿主機上創(chuàng)建這樣一條 iptables 規(guī)則(你可以通過 iptables-save 看到它)。這些規(guī)則捕獲到service的clusterIP和port的流量，并將這些流量隨機重定向到service后端Pod。對于每個endpoint對象，它生成選擇后端Pod的iptables規(guī)則。
如果選擇的第一個Pod沒有響應，kube-proxy將檢測到到第一個Pod的連接失敗，并將自動重試另一個后端Pod。拓撲圖：
iptables 是一個 Linux 內核功能，是一個高效的防火墻，并提供了大量的數(shù)據(jù)包處理和過濾方面的能力。它可以在核心數(shù)據(jù)包處理管線上用 Hook 掛接一系列的規(guī)則。iptables 模式中 kube-proxy 在 NAT pre-routing Hook 中實現(xiàn)它的 NAT 和負載均衡功能。這種方法簡單有效，依賴于成熟的內核功能，并且能夠和其它跟 iptables 協(xié)作的應用融洽相處。
因為它純粹是為防火墻而設計且基于內核規(guī)則列表，kube-proxy 使用的是一種 O(n) 算法，其中的 n 隨集群規(guī)模同步增長，所以這里的集群規(guī)模越大，更明確的說就是服務和后端 Pod 的數(shù)量越大，查詢的時間就會越長。
一個例子是，在5000節(jié)點集群中使用 NodePort 服務，如果我們有2000個服務并且每個服務有10個 pod，這將在每個工作節(jié)點上至少產生20000個 iptable 記錄，這會使內核非常繁忙。
結論：
kube-proxy 通過 iptables 處理 Service 的過程，其實需要在宿主機上設置相當多的 iptables 規(guī)則。而且，kube-proxy 還需要在控制循環(huán)里不斷地刷新這些規(guī)則來確保它們始終是正確的。不難想到，當你的宿主機上有大量 Pod 的時候，成百上千條 iptables 規(guī)則不斷地被刷新，會大量占用該宿主機的 CPU 資源，甚至會讓宿主機“卡”在這個過程中。所以說，一直以來，基于 iptables 的 Service 實現(xiàn)，都是制約 Kubernetes 項目承載更多量級的 Pod 的主要障礙。
ipvs模式
在 IPVS 模式下，kube-proxy監(jiān)視Kubernetes服務和端點，調用 netlink 接口創(chuàng)建 IPVS 規(guī)則， 并定期將 IPVS 規(guī)則與 Kubernetes 服務和端點同步。訪問服務時，IPVS 將流量定向到后端Pod之一。IPVS代理模式基于類似于 iptables 模式的 netfilter 掛鉤函數(shù)， 但是使用哈希表作為基礎數(shù)據(jù)結構，并且在內核空間中工作。這意味著，與 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延遲要短，并且在同步代理規(guī)則時具有更好的性能。與其他代理模式相比，IPVS 模式還支持更高的網絡流量吞吐量。
IPVS 模式的工作原理，其實跟 iptables 模式類似。當我們創(chuàng)建了前面的 Service 之后，kube-proxy 首先會在宿主機上創(chuàng)建一個虛擬網卡(叫作：kube-ipvs0)，并為它分配 Service VIP 作為 IP 地址。接下來，kube-proxy 就會通過 Linux 的 IPVS 模塊，為這個 IP 地址設置三個 IPVS 虛擬主機，并設置這三個虛擬主機之間使用輪詢模式 (rr) 來作為負載均衡策略。拓撲圖如下所示拓撲圖：
IPVS 是一個用于負載均衡的 Linux 內核功能。IPVS 模式下，kube-proxy 使用 IPVS 負載均衡代替了 iptable。這種模式同樣有效，IPVS 的設計就是用來為大量服務進行負載均衡的，它有一套優(yōu)化過的 API，使用優(yōu)化的查找算法，而不是簡單的從列表中查找規(guī)則。
這樣一來，kube-proxy 在 IPVS 模式下，其連接過程的復雜度為 O(1)。換句話說，多數(shù)情況下，他的連接處理效率是和集群規(guī)模無關的。
另外作為一個獨立的負載均衡器，IPVS 包含了多種不同的負載均衡算法，例如輪詢、最短期望延遲、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機平等的選擇算法。IPVS一個潛在缺點是，與正常情況下的數(shù)據(jù)包相比，由IPVS處理的數(shù)據(jù)包通過iptables篩選器hook的路徑不同。如果打算將IPVS與其他使用iptables的程序一起使用，則需要研究它們是否可以一起正常工作。不過Ipvs代理模式已經推出很久了，很多組件已經適配的很好了，比如Calico。
結論：
IPVS是專門設計用來做內核四層負載均衡的，由于使用了hash表的數(shù)據(jù)結構，因此相比iptables來說性能會更好?；贗PVS實現(xiàn)Service轉發(fā)，Kubernetes幾乎能夠具備無限的水平擴展能力。隨著Kubernetes的部署規(guī)模越來越大，應用越來越廣泛，IPVS必然會取代iptables成為Kubernetes Service的默認實現(xiàn)后端。
總結
IPVS (IP Virtual Server，IP虛擬服務器)是基于Netfilter的、作為linux內核的一部分實現(xiàn)傳輸層負載均衡的技術，通常稱為第4層LAN交換。IPVS集成在LVS(Linux Virtual Server)中，它在主機中運行，并在真實服務器集群前充當負載均衡器。IPVS可以將對TCP/UDP服務的請求轉發(fā)給后端的真實服務器，并使真實服務器的服務在單個IP地址上顯示為虛擬服務。因此IPVS天然支持Kubernetes Service。
- 隨著kubernetes使用量的增長，其資源的可擴展性變得越來越重要。特別是對于使用kubernetes運行大型工作負載的開發(fā)人員或者公司來說，service的可擴展性至關重要。kube-proxy是為service構建路由規(guī)則的模塊，之前依賴iptables來實現(xiàn)主要service類型的支持，比如(ClusterIP和NodePort)。但是iptables很難支持上萬級的service，因為iptables純粹是為防火墻而設計的，并且底層數(shù)據(jù)結構是內核規(guī)則的列表。
- 而相比于 iptables，IPVS 在內核中的實現(xiàn)其實也是基于 Netfilter 的 NAT 模式，所以在轉發(fā)這一層上，理論上 IPVS 并沒有顯著的性能提升。但是，IPVS 并不需要在宿主機上為每個 Pod 設置 iptables 規(guī)則，而是把對這些“規(guī)則”的處理放到了內核態(tài)，從而極大地降低了維護這些規(guī)則的代價。
- kubernetes早在1.6版本就已經有能力支持5000多節(jié)點，這樣基于iptables的kube-proxy就成為集群擴容到5000節(jié)點的瓶頸。舉例來說，如果在一個5000節(jié)點的集群，我們創(chuàng)建2000個service，并且每個service有10個pod，那么我們就會在每個節(jié)點上有至少20000條iptables規(guī)則，這會導致內核非常繁忙。基于IPVS的集群內負載均衡就可以完美的解決這個問題。IPVS是專門為負載均衡設計的，并且底層使用哈希表這種非常高效的數(shù)據(jù)結構，幾乎可以允許無限擴容。不過需要注意的是，IPVS 模塊只負責上述的負載均衡和代理功能。而一個完整的 Service 流程正常工作所需要的包過濾、SNAT 等操作，還是要靠 iptables 來實現(xiàn)。只不過，這些輔助性的 iptables 規(guī)則數(shù)量有限，也不會隨著 Pod 數(shù)量的增加而增加。
IPVS模式在Kubernetes v1.8中引入，并在v1.9中進入了beta。1.11中實現(xiàn)了GA(General Availability)。IPTABLES模式在v1.1中添加，并成為自v1.2以來的默認操作模式。IPVS和IPTABLES都基于netfilter。IPVS模式和IPTABLES模式之間的差異如下：
- IPVS為大型集群提供了更好的可擴展性和性能。(規(guī)則的存儲方式使用的數(shù)據(jù)結構更高效)
- IPVS支持比iptables更復雜的負載平衡算法(rr：循環(huán)，lc：最少連接，dh：目標散列，sh：源哈希，sed：最短的預期延遲，nq：從不排隊)。
- IPVS支持服務器健康檢查和連接重試等。
在集群中不超過1000個服務的時候，iptables 和 ipvs 并無太大的差異。而且由于iptables 與網絡策略實現(xiàn)的良好兼容性，iptables 是個非常好的選擇。當你的集群服務超過1000個時，而且服務之間鏈接大多沒有開啟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
本文名稱：Kube-Proxy中使用Ipvs與Iptables的比較
URL網址：http://www.5511xx.com/article/cdceehs.html
