service流量
Kubernetes 之所以需要 Service，一方面是因為 Pod 的 IP 不是固定的（Pod可能會重建），另一方面則是因為一組 Pod 實例之間總會有負載均衡的需求。
Service通過 Label Selector實現的對一組的Pod的訪問。
對於容器應用而言。
Kubernetes 提供了基於 VIP（虛擬IP） 的網橋的方式訪問 Service，再由 Service 重定向到相應的 Pod。
service的類型：
ClusterIP：提供一個集群內部的虛擬IP以供Pod訪問（service默認類型)
NodePort：在每個Node上打開一個端口以供外部訪問，Kubernetes將會在每個Node上打開一個端口並且每個Node的端口都是一樣的，通過\:NodePort的方式Kubernetes集群外部的程序可以訪問Service。
LoadBalancer：通過外部的負載均衡器來訪問。
====service實現原理：
兩種方式
1.基於iptables規則來實現。但是當Pod數量過多時，成百上千條 iptables 規則不斷地被刷新，會大量占用該宿主機的 CPU 資源。
2. 基於IPVS來實現，IPVS屬於內核模塊，所以把轉發的操作放到內核態中，性能更好。
1. 基於iptables來實現的service
在 Kubernetes 集群中，每個 Node 運行一個 kube-proxy(服務代理) 進程。kube-proxy 負責為 Service 實現了一種 VIP（虛擬 IP）的形式。
也就是說Service 是由 kube-proxy 組件，加上 iptables 來共同實現的。
通過iptables規則，是實現了serviec RR輪詢的方式去訪問后端的Pod。
2. IPVS模式
Kubernetes 的 kube-proxy 還支持一種叫作 IPVS 的模式
通過上面的講解，你可以看到，kube-proxy 通過 iptables 處理 Service 的過程，其實需要在宿主機上設置相當多的 iptables 規則。而且，kube-proxy 還需要在控制循環里不斷地刷新這些規則來確保它們始終是正確的。
不難想到，當你的宿主機上有大量 Pod 的時候，成百上千條 iptables 規則不斷地被刷新，會大量占用該宿主機的 CPU 資源，甚至會讓宿主機“卡”在這個過程中。所以說，一直以來，基於 iptables 的 Service 實現，都是制約 Kubernetes 項目承載更多量級的 Pod 的主要障礙。
而相比於 iptables，IPVS 在內核中的實現其實也是基於 Netfilter 的 NAT 模式，所以在轉發這一層上，理論上 IPVS 並沒有顯著的性能提升。但是，IPVS 並不需要在宿主機上為每個 Pod 設置 iptables 規則，而是把對這些“規則”的處理放到了內核態，從而極大地降低了維護這些規則的代價。這也正印證了我在前面提到過的，“將重要操作放入內核態”是提高性能的重要手段。
IPVS 模塊只負責上述的負載均衡和代理功能。而一個完整的 Service 流程正常工作所需要的包過濾、SNAT 等操作，還是要靠 iptables 來實現。只不過，這些輔助性的 iptables 規則數量有限，也不會隨着 Pod 數量的增加而增加。
在大規模集群里，我非常建議你為 kube-proxy 設置–proxy-mode=ipvs 來開啟這個功能。它為 Kubernetes 集群規模帶來的提升，還是非常巨大的。
Kubernetes 的 Service 的負載均衡策略，在 iptables 和 ipvs 模式下，都有哪幾種？具體工作模式是怎樣的？
service 負載分發策略有兩種：
RoundRobin：輪詢模式，即輪詢將請求轉發到后端的各個pod上（默認模式）；
SessionAffinity：基於客戶端IP地址進行會話保持的模式，第一次客戶端訪問后端某個pod，之后的請求都轉發到這個pod上。