從k8s的1.8版本開始，kube-proxy引入了IPVS模式，IPVS模式與iptables同樣基於Netfilter，但是ipvs採用的hash表，iptables採用一條條的規則列表。iptables又是爲了防火牆設計的，集羣數量越多iptables規則就越多，而iptables規則是從上到下匹配，所以效率就越是低下。因此當service數量達到一定規模時，hash查表的速度優勢就會顯現出來，從而提高service的服務性能
每個節點的kube-proxy負責監聽API server中service和endpoint的變化情況。將變化信息寫入本地userspace、iptables、ipvs來實現service負載均衡，使用NAT將vip流量轉至endpoint中。由於userspace模式因爲可靠性和性能（頻繁切換內核/用戶空間）早已經淘汰，所有的客戶端請求svc，先經過iptables，然後再經過kube-proxy到pod，所以性能很差。
ipvs和iptables都是基於netfilter的，兩者差別如下：
- ipvs 爲大型集羣提供了更好的可擴展性和性能
- ipvs 支持比 iptables 更復雜的負載均衡算法（最小負載、最少連接、加權等等）
- ipvs 支持服務器健康檢查和連接重試等功能
一、Iptables模式
在這種模式下，kube-proxy監視API Server中service和endpoint的變化情況。對於每個service，它都生成相應的iptables規則，這些規則捕獲到service的clusterIP和port的流量，並將這些流量隨機重定向到service後端Pod。對於每個endpoint對象，它生成選擇後端Pod的iptables規則。
如果選擇的第一個Pod沒有響應，kube-proxy將檢測到到第一個Pod的連接失敗，並將自動重試另一個後端Pod。
拓撲圖：
缺點：
iptables 因爲它純粹是爲防火牆而設計的，並且基於內核規則列表，集羣數量越多性能越差。
一個例子是，在5000節點集羣中使用 NodePort 服務，如果我們有2000個服務並且每個服務有10個 pod，這將在每個工作節點上至少產生20000個 iptable 記錄，這可能使內核非常繁忙。
二、IPVS模式（NAT模式）
在這種模式下，kube-proxy監聽API Server中service和endpoint的變化情況，調用netlink接口創建相應的ipvs規則，並定期將ipvs規則與Kubernetes服 Services和Endpoints同步。保證IPVS狀態。當訪問Services時，IPVS將流量定向到後端pod之一。
IPVS代理模式基於netfilter hook函數，該函數類似於iptables模式，但使用hash表作爲底層數據結構，在內核空間中工作。這意味着IPVS模式下的kube-proxy使用更低的重定向流量。其同步規則的效率和網絡吞吐量也更高。
拓撲圖：
說明：
ipvs依賴iptables進行包過濾、SNAT、masquared(僞裝)。 使用 ipset 來存儲需要 DROP 或 masquared 的流量的源或目標地址，以確保 iptables 規則的數量是恆定的，這樣我們就不需要關心我們有多少服務了
如果沒有加載並啓用ipvs模塊，或者沒有配置ipvs相關配置，則會被降級成iptables模式。