Service介紹
在k8s中，pod是應用程序的載體，我們可以通過pod的ip來訪問應用程序，但是pod的ip地址不是固定的，這也就意味着不方便直接采用pod的ip對服務進行訪問
為了解決這個問題，k8s提供了service資源，service會對提供同一個服務的多個pod進行聚合，並且提供一個統一的入口地址。通過訪問service的入口地址就能訪問到后面的pod服務。
service在很多情況下只是一個概念，真正起作用的其實是kube-proxy服務進程，每個node節點上都運行一個kube-proxy服務進程，當創建service的時候會通過api-server向etcd寫入創建的service信息，而kube-proxy會基於監聽的機制發現這種service的變動，然后它會將最新的service信息轉換成對應的訪問規則。
kube-proxy三種工作模式
kube-proxy目前支持三種工作模式
userspace模式
userspace模式下，kube-proxy為service后端的每個service創建一個監聽端口，發向cluster ip的請求被iptables規則重定向到kube-proxy監聽的端口上，kube-proxy根據LB算法選擇一個提供服務的pod並和其建立連接，以將請求轉發到pod上。
該模式下，kube-proxy充當了一個四層負載均衡器的角色，由於kube-proxy運行在userspace中，在進行轉發處理時會增加內核和用戶空間之間的數據拷貝，雖然比較穩定，但是效率比較低。
iptables模式
iptables模式下，kube-proxy為service后端的每個pod創建對應的iptables規則，直接將發向cluster ip的請求重定向到一個pod ip。
該模式下kube-proxy不承擔四層負載均衡器的角色，只負責創建iptables規則。該模式的優點是較userspace模式效率更高，但不能提供靈活的LB策略，當后端pod不可用時也無法進行重試
ipvs模式
ipvs模式和iptables類似，kube-proxy監控pod的變化並創建相應的ipvs規則，ipvs相對iptables轉發效率更高。除此以外，ipvs支持更多的LB算法。
此模式必須安裝ipvs內核模塊，否則會降級為iptables，如何安裝已經在k8s集群環境搭建中闡述
開啟ipvs
[root@master ~]# kubectl edit cm kube-proxy -n kube-system
找到里面的mode字段，將內容修改為ipvs
刪除kube-proxy的pod並重建
[root@master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system pod "kube-proxy-ck9sg" deleted pod "kube-proxy-hlpd6" deleted pod "kube-proxy-jh9gq" deleted
查看ipvs，發現產生了一批規則
[root@master ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.96.0.1:443 rr -> 192.168.145.131:6443 Masq 1 0 0 TCP 10.96.0.10:53 rr -> 10.244.0.8:53 Masq 1 0 0 -> 10.244.0.9:53 Masq 1 0 0 TCP 10.96.0.10:9153 rr -> 10.244.0.8:9153 Masq 1 0 0 -> 10.244.0.9:9153 Masq 1 0 0 UDP 10.96.0.10:53 rr -> 10.244.0.8:53 Masq 1 0 0 -> 10.244.0.9:53 Masq 1 0 0