對k8s service的一些理解

服務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

targetPort 端口是service對外暴露的端口，任何人訪問9376端口都會被service代理到後端pod的80端口

服務代理

k8s羣集中的每一個節點都運行一個kube-proxy的組件，kube-proxy實際上是一個代理層負責實現service

kube-proxy代理模式有兩種：

代理模式：userspace

客戶端訪問ServiceIP（clusterIP）請求會先從用戶空間到內核中的iptables，而後回到用戶空間kube-proxy，kube-proxy負責代理工做。

具體細節：

每一個service都會由kube-proxy在node節點上起一個隨機的代理端口，iptables會捕捉clusterIP上的端口(targetPort)流量重定向代理端口，訪問代理端口的任何鏈接都會被代理到service後端的某一個pod，默認狀況下對後端pod的選擇是輪詢

 

代理模式：iptables

客戶端訪問ServiceIP（clusterIP）請求會由iptables直接重定向到後端

具體細節：

每一個service都會由kube-proxy生成一組iptables規則，iptables會捕捉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插件使用