一. Service定義
Kubernetes Service 定義了這樣一種概念: -個[Pod]的邏輯分組，-種可以通路它們的政策--通常稱為微服務。這一組Pod能夠被Service 通路到，通常是通過Label selector來通路
二. Service類型
Service在K8s中有以下四種類型：
1. Clusterlp: 預設類型，自動配置設定-個僅Cluster内部可以通路的虛拟IP
2. NodePort: 在ClusterIP基礎上為Service在每台機器.上綁定個端口，這樣就可以通過: NodePort來訪
問該服務
3. LoadBalancer: 在NodePort的基礎上，借助cloud provider建立-一個外部負載均衡器，并将請求轉發
到: NodePort
4. ExternalName: 把叢集外部的服務引入到叢集内部來，在叢集内部直接使用。沒有任何類型代理被建立，
這隻有kubernetes 1.7或更高版本的kube-dns才支援
三. Service代理
在Kubernetes叢集中，每個Node運作一個kube-proxy 程序。kube-proxy 負責為Service 實作了一種VIP (虛拟IP)的形式，而不是ExternalName 的形式。 在Kubernetes v1.0版本，代理完全在userspace. 在Kubernetes v1.1版本，新增了iptables代理，但并不是預設的運作模式。從Kubermetes v1.2起，預設就是iptables代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理在Kubernetes 1.14版本開始預設使用ipvs代理
在Kubernetes v1.0版本，Service 是"4層”(TCP/UDP overIP)概念。在Kubernetesv1.1版本,新增了Ingress API (beta 版)，用來表示“7層”(HTTP) 服務。
看下圖：
四. Service代理模式分類
1. userspace
這種方式是需要經過kube-proxy的，比較消耗時間
2. iptables代理模式
這種方式不需要經過kube-proxy，隻需要經過iptables的防火牆，而它的pod資訊還是有service，kube-proxy來維護的。
3. IPVS代理模式
這種模式，kube-proxy 會監視Kubernetes Service 對象和Endpoints， 調用netlink 接口以相應地建立ipvs規則并定期與Kubernetes Service 對象和Endpoints 對象同步ipvs規則，以確定ipvs狀态與期望一緻。通路服務時，流量将被重定向到其中-個後端Pod
與iptables類似，ipvs 于netfilter的hook功能，但使用哈希表作為底層資料結構并在核心空間中工作。這意味着ipvs可以更快地重定向流量，并且在同步代理規則時具有更好的性能。此外，ipvs 為負載均衡算法提供了更多選項，例如:
●rr:輪詢排程
●lc:最小連接配接數
●dh:目标哈希
●sh:源哈希
●sed:最短期望延遲
● nq:不排隊排程