對k8s 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:

ports:

- protocol: tcp

port: 80

targetport: 9376

port 埠是service對外暴露的埠，任何人訪問80埠都會被service**到後端pod的9376埠

k8s群集中的每個節點都執行乙個kube-proxy的元件，kube-proxy其實是乙個**層負責實現service

kube-proxy**模式有兩種：

客戶端訪問serviceip（clusterip）請求會先從使用者空間到核心中的iptables，然後回到使用者空間kube-proxy，kube-proxy負責**工作。

具體細節：

每個service都會由kube-proxy在node節點上起乙個隨機的**埠，iptables會捕捉clusterip上的埠(port)流量重定向**埠，訪問**埠的任何連線都會被**到service後端的某乙個pod，預設情況下對後端pod的選擇是輪詢

客戶端訪問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版