kubeproxy 的三種模式

kube-proxy是對service的實現，也就是service只是用來抽象定義，真正具體化幹活的是kube-proxy.它執行在每一個node節點上，負責該節點的網路代理。它是一個pod。

userspace

• 單純的使用者態 會經過核心切換存一點過的開銷
• 頻繁使用者空間和核心空間之間切換

iptales

• 核心態直接作用Linux netfilter
• 當service或者endpoints、pod發生變化時，kube-proxy會建立對應的iptables規則
• 對於每個服務，它都安裝iptables規則，該規則捕獲到服務clusterIP和的port流量，並將該流量重定向到服務的後端集之一。
• 對於每個Endpoint物件，它將安裝iptables規則，該規則選擇一個後端Pod。
• 預設情況下，iptables模式下的kube-proxy會隨機選擇一個後端，所選的第一個Pod沒有響應，則連線失敗，無法重試
• 缺點：服務多的時候產生太多的 iptables 規則，非增量式更新會引入一定的時延，大規模情況下有明顯的效能問題

ipvs

• 核心態直接作用網路協議棧
• kube-proxy監視Kubernetes服務和端點，呼叫netlink介面以相應地建立IPVS規則，並定期將IPVS規則與Kubernetes服務和端點同步。
• 用雜湊表作為基礎資料結構，訪問服務時，IPVS將流量定向到後端Pod之一, 更低的延遲來重定向流量。
• 更多的輪詢策略。 rr：輪循、lc：連線最少（開啟的連線最少）、dh：目標雜湊、sh：源雜湊、sed：最短的預期延遲、nq：永不排隊
• 採用增量式更新，並可以保證 service 更新期間連線保持不斷開