kube-proxy 通過 Informer知道了Service、endpoints對象的創建，然后把service身上的CLUSTER-IP 和端口已經端點信息拿出來，創建iptable NAT規則做轉發或通過ipvs模塊創建VS服務器，這樣經過CLUSTER-IP的流量都被轉發到后端pod。

iptables模式

我們先查看nat表的OUTPUT鏈，存在kube-proxy創建的KUBE-SERVICE鏈

iptables -nvL OUTPUT -t nat

在KUBE-SERVICES鏈中有一條目的地為10.96.148.206即CLUSTER-IP地址跳轉到KUBE-SVC-EJUV4ZBKPDWOZNF4

iptables -nvL KUBE-SERVICES -t nat |grep service-demo

接著是查看這條鏈，以1/3的概率跳轉到其中一條

iptables -nvL KUBE-SVC-EJUV4ZBKPDWOZNF4 -t nat

最后KUBE-SEP-BTFJGISFGMEBGVUF鏈終于找到了DNAT規則

iptables -nvL KUBE-SEP-BTFJGISFGMEBGVUF -t nat

即將請求通過DNAT發送到地址100.101.184.61:9376也就是我們其中一個Pod。

IPVS模式

與iptalbes模式相比，IPVS模式工作在內核態，在同步代理規則時具有更好的性能，同時提高網絡吞吐量為大型集群提供了更好的可擴展性。

IPVS 模式在工作時，當我們創建了前面的 Service 之后，kube-proxy 首先會在宿主機上創建一個虛擬網卡kube-ipvs0，并為它分配 Service VIP 作為 IP 地址，如圖

接著kube-proxy通過Linux的IPVS模塊為這個 IP 地址添加三個 IPVS 虛擬主機，并設置這三個虛擬主機之間使用輪詢模式 來作為負載均衡策略。

通過ipvsadm查看

ipvsadm -ln |grep -C 5 10.96.148.206

可以看到虛擬server的IP即是Pod的地址，這樣流量即向了目的地Pod。

以上我們先認識了Service這個API對象，接著講到了service與endpoints和pod的關聯，然后是service與kube-proxy的關系，以及kube-proxy的兩種模式如何通過service的IP創建iptables、IPVS規則將流量轉發到Pod。