服務service
service是一個抽象概念，定義了一個服務的多個pod邏輯合集和訪問pod的策略，一般把service稱為微服務
舉個例子一個a服務運行3個pod，b服務怎么訪問a服務的pod，pod的ip都不是持久化的重啟之后就會有變化。
這時候b服務可以訪問跟a服務綁定的service，service信息是固定的提前告訴b就行了，service通過Label Selector跟a服務的pod綁定,無論a的pod如何變化對b來說都是透明的
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
port 端口是service對外暴露的端口，任何人訪問80端口都會被service代理到后端pod的9376端口
服務代理
k8s群集中的每個節點都運行一個kube-proxy的組件，kube-proxy其實是一個代理層負責實現service
kube-proxy代理模式有兩種：
代理模式：userspace
客戶端訪問ServiceIP（clusterIP）請求會先從用戶空間到內核中的iptables，然后回到用戶空間kube-proxy，kube-proxy負責代理工作。
具體細節：
每個service都會由kube-proxy在node節點上起一個隨機的代理端口，iptables會捕捉clusterIP上的端口(port)流量重定向代理端口，訪問代理端口的任何連接都會被代理到service后端的某一個pod，默認情況下對后端pod的選擇是輪詢
代理模式：iptables
客戶端訪問ServiceIP（clusterIP）請求會由iptables直接重定向到后端
具體細節：
每個service都會由kube-proxy（監控 kube-control）生成一組iptables規則，iptables（nat 表）會捕捉clusterIP上的端口(targetPort)流量重定向后端某一個pod，默認對pod的選擇是隨機的
Kubernetes v1.2之前默認是userspace之后是iptables模式，iptables模式性能和可靠性更好，但是iptables模式依賴健康檢查，在沒有健康檢查的情況下如果一個pod不響應，iptables模式不會切換另一個pod上
Kubernetes v1.9版本會支持lvs的ipvs模式目前還是beta版
service的類型
- ClusterIP 默認模式，只能在集群內部訪問
- NodePort 在每個節點上都監聽一個同樣的端口號(30000-32767)，ClusterIP和路由規則會自動創建。集群外部可以訪問<NodeIP>:<NodePort>聯系到集群內部服務，可以配合外部負載均衡使用（我現在公司用的就是這個模式配合阿里雲的SLB）
- LoadBalancer 要配合支持公有雲負載均衡使用比如GCE、AWS。其實也是NodePort，只不過會把<NodeIP>:<NodePort>自動添加到公有雲的負載均衡當中
- ExternalName 創建一個dns別名指到service name上，主要是防止service name發生變化，要配合dns插件使用