一 kube-proxy原理 1.1 kube-proxy概述 Kubernetes為了支持集群的水平擴展、高可用性，抽象出了Service的概念。Service是對一組Pod的抽象，它會根據訪問策略（如負載均衡策略）來訪問這組Pod。Kubernetes在創建Service時會為Service分配 ...
一 kube-proxy原理
1.1 kube-proxy概述
Kubernetes為了支持集群的水平擴展、高可用性，抽象出了Service的概念。Service是對一組Pod的抽象，它會根據訪問策略（如負載均衡策略）來訪問這組Pod。Kubernetes在創建Service時會為Service分配一個虛擬的IP地址，客戶端通過訪問這個虛擬的IP地址來訪問服務，Service則負責將請求轉發到後端的Pod上。 Service作用類似反向代理，但與普通的反向代理有一些不同：首先，它的IP地址是虛擬的，預設情況無法從外面訪問；其次，它的部署和啟停是由Kubernetes統一自動管理的。 然而，Service是一個抽象概念，而真正提供Service功能的是kube-proxy服務進程。在Kubernetes集群的每個Node上都會運行一個kube-proxy服務進程，可以簡單理解此進程是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到後端的多個Pod實例上。 此外，Service的ClusterIP與NodePort等概念是kube-proxy服務通過iptables的NAT轉換實現的，kube-proxy在運行過程中動態創建與Service相關的iptables規則，這些規則實現了將訪問服務（ClusterIP或NodePort）的請求負載分發到後端Pod的功能。 由於iptables機制針對的是本地的kube-proxy埠，所以在每個Node上都要運行kube-proxy組件。這樣一來，在Kubernetes集群內部，才可以在任意Node上發起對Service的訪問請求。 綜上所述，由於kube-proxy的作用，在Service的調用過程中客戶端無須關心後端有幾個Pod，中間過程的通信、負載均衡及故障恢復都是透明的。二 kube-proxy模式
2.1 userspace模式
起初，kube-proxy進程是一個真實的TCP/UDP代理，類似HAProxy，負責從Service到Pod的訪問流量的轉發，這種模式被稱為userspace（用戶空間代理）模式。
如圖所示，當某個Pod以ClusterIP方式訪問某個Service的時候，這個流量會被Pod所在本機的iptables轉發到本機的kube-proxy進程，然後由kube-proxy建立起到後端Pod的TCP/UDP連接，隨後將請求轉發到某個後端Pod上，併在這個過程中實現負載均衡功能。
ClusterIP與NodePort的實現原理，以及kube-proxy與APIServer的交互過程，如下圖所示：
提示：如上為舊版kube-proxy與APIServer的交互過程。
2.2 iptables模式
如圖所示，Kubernetes從1.2版本開始，將iptables作為kube-proxy的預設模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch介面實時跟蹤Service與Endpoint的變更信息，並更新對應的iptables規則，Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。
根據Kubernetes的網路模型，一個Node上的Pod與其他Node上的Pod應該能夠直接建立雙向的TCP/IP通信通道，所以如果直接修改iptables規則，則也可以實現kube-proxy的功能，只不過後者更加高端，因為是全自動模式的。
與第1代的userspace模式相比，iptables模式完全工作在內核態，不用再經過用戶態的kube-proxy中轉，因而性能更強。
iptables模式雖然實現起來簡單，但存在無法避免的缺陷：在集群中的Service和Pod大量增加以後，iptables中的規則會急速膨脹，導致性能顯著下降，在某些極端情況下甚至會出現規則丟失的情況，並且這種故障難以重現與排查，於是Kubernetes從1.8版本開始引入第3代的IPVS（IPVirtualServer）模式。
kube-proxy針對Service和Pod創建的一些主要的iptables規則如下。
- KUBE-CLUSTER-IP：在masquerade-all=true或clusterCIDR指定的情況下對ServiceClusterIP地址進行偽裝，以解決數據包欺騙問題。
- KUBE-EXTERNAL-IP：將數據包偽裝成Service的外部IP地址。
- KUBE-LOAD-BALANCER、KUBE-LOAD-BALANCERLOCAL：偽裝LoadBalancer類型的Service流量。
- KUBE-NODE-PORT-TCP、KUBE-NODE-PORT-LOCALTCP、KUBE-NODE-PORTUDP、KUBE-NODE-PORT-LOCAL-UDP：偽裝NodePort類型的Service流量。
2.3 IPVS模式
如圖所示。IPVS在Kubernetes1.11中升級為GA穩定版。iptables與IPVS雖然都是基於Netfilter實現的，但因為定位不同，二者有著本質的差別：iptables是為防火牆而設計的；IPVS則專門用於高性能負載均衡，並使用更高效的數據結構（Hash表），允許幾乎無限的規模擴張，因此被kube-proxy採納為第三代模式。
與iptables相比，IPVS擁有以下明顯優勢：
- 為大型集群提供了更好的可擴展性和性能；
- 支持比iptables更複雜的複製均衡演算法（最小負載、最少連接、加權等）；
- 支持伺服器健康檢查和連接重試等功能；
- 可以動態修改ipset的集合，即使iptables的規則正在使用這個集合。
