前言
Service是k8s中資源的一種，也是k8s能夠實現減少運維工作量，甚至免運維的關鍵點，我們公司的運維都要把服務搭在我們集羣裏，接觸過的人應該都能體會到其方便之處。Service能將pod的變化屏蔽在集羣內部，同時提供負載均衡的能力，自動將請求流量分佈到後端的pod，這一功能的實現靠的就是kube-proxy的流量代理，一共有三種模式，userspace、iptables以及ipvs。
1、userspace
網上的圖是這樣的：
沒大理解，自己畫的一下：
1、爲每個service在node上打開一個隨機端口（代理端口）
2、建立iptables規則，將clusterip的請求重定向到代理端口
3、到達代理端口（用戶空間）的請求再由kubeproxy轉發到後端pod。
這裏爲什麼需要建iptables規則，因爲kube-proxy 監聽的端口在用戶空間，所以需要一層 iptables 把訪問服務的連接重定向給 kube-proxy 服務，這裏就存在內核態到用戶態的切換，代價很大，因此就有了iptables。
2、iptables
這裏以我們集羣的iptables規則爲例介紹數據包的遷移規則：
PREROUTING和OUTPUT兩個檢查點：即入鏈和出鏈都會路由到KUBE-SERVICE這個全局鏈中
接着我們可以看下這個全局鏈的路由過程，這裏只篩選部分規則說明：
1、-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
2、-A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-VFX5D4HWHAGOXYCD --mask 255.255.255.255 --rsource -j KUBE-SEP-VFX5D4HWHAGOXYCD
3、-A KUBE-SEP-VFX5D4HWHAGOXYCD -p tcp -m comment --comment "default/kubernetes:https" -m recent --set --name KUBE-SEP-VFX5D4HWHAGOXYCD --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 172.22.44.62:6443
10.96.0.1爲clusterip，發往目的地爲clusterip的數據包會被轉發由KUBE-SVC-NPX46M4PTMTKRN6Y規則處理，接着我們依次找下去，可以看到最後路由到了172.22.44.62:6443，這就是後端的pod服務的對應ip:port。
不同於userspace，iptables由kube-proxy動態的管理，kube-proxy不再負責轉發，數據包的走向完全由iptables規則決定，這樣的過程不存在內核態到用戶態的切換，效率明顯會高很多。但是隨着service的增加，iptables規則會不斷增加，導致內核十分繁忙（等於在讀一張很大的沒建索引的表）。
測試環境80多個service就有1601條了，而且基本都還是單pod。
3、IPVS
一張圖說明，用ipset存儲iptables規則，這樣規則的數量就能夠得到有效控制，而在查找時就類似hash表的查找。