一 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的規則正在使用這個集合。
由於IPVS無法提供包過濾、airpin-masqueradetricks（地址偽裝）、SNAT等功能，因此在某些場景（如NodePort的實現）下還要與iptables搭配使用。
在IPVS模式下，kube-proxy又做了重要的升級，即使用iptables的擴展ipset，而不是直接調用iptables來生成規則鏈。iptables規則鏈是一個線性的數據結構，ipset則引入了帶索引的數據結構，因此當規則很多時，也可以很高效地查找和匹配。
可以將ipset簡單理解為一個IP（段）的集合，這個集合的內容可以是IP地址、IP網段、端口等，iptables可以直接添加規則對這個“可變的集合”進行操作，這樣做的好處在於可以大大減少iptables規則的數量，從而減少性能損耗。假設要禁止上萬個IP訪問我們的服務器，則用iptables的話，就需要一條一條地添加規則，會在iptables中生成大量的規則；但是用ipset的話，只需將相關的IP地址（網段）加入ipset集合中即可，這樣只需設置少量的iptables規則即可實現目標。