[[428642]]

本文轉載自微信公眾號「運維開發故事」，作者沒有文案的夏老師 。轉載本文請聯系運維開發故事公眾號。

Iptables模式

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

如果選擇的第一個Pod沒有響應，kube-proxy將檢測到到第一個Pod的連接失敗，并將自動重試另一個后端Pod。拓撲圖：

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

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

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

結論：

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

ipvs模式

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

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

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

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

另外作為一個獨立的負載均衡器，IPVS 包含了多種不同的負載均衡算法，例如輪詢、最短期望延遲、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機平等的選擇算法。IPVS一個潛在缺點是，與正常情況下的數據包相比，由IPVS處理的數據包通過iptables篩選器hook的路徑不同。如果打算將IPVS與其他使用iptables的程序一起使用，則需要研究它們是否可以一起正常工作。不過Ipvs代理模式已經推出很久了，很多組件已經適配的很好了，比如Calico。

結論：

IPVS是專門設計用來做內核四層負載均衡的，由于使用了hash表的數據結構，因此相比iptables來說性能會更好。基于IPVS實現Service轉發，Kubernetes幾乎能夠具備無限的水平擴展能力。隨著Kubernetes的部署規模越來越大，應用越來越廣泛，IPVS必然會取代iptables成為Kubernetes Service的默認實現后端。

總結

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

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

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

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

在集群中不超過1000個服務的時候，iptables 和 ipvs 并無太大的差異。而且由于iptables 與網絡策略實現的良好兼容性，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