K8S Service 實戰與原理初探
Service是一種暴露一組Pod網絡的抽象方式，K8S Service提供了針對于一組Pod的負載均衡的暴露。通過這樣的方式，可以避免不同的pod之間訪問時需要知曉對應pod網絡信息的痛苦。例如：前端->后端，由于前端POD IP隨時變動，后端亦如此，如何處理前端POD和后端POD的通信，就需要Service這一抽象，來保證簡單可靠。
Service的使用
1、典型服務配置方法
當配置了selector之后，Service Controller會自動查找匹配這個selector的pod，并且創建出一個同名的endpoint對象，負責具體service之后連接。
2、配置沒有selector的服務
沒有selector的service不會出現Endpoint的信息，需要手工創建Endpoint綁定，Endpoint可以是內部的pod，也可以是外部的服務。
Service的類型
1.CluserIP
2.LoadBalance
- 對于 ExternalName 類型的服務，查找其 CNAME 記錄
- 對所有其他類型的服務，查找與 Service 名稱相同的任何 Endpoints 的記錄
Service的實現方式
1.用戶態代理訪問
即：當對于每個Service，Kube-Proxy會在本地Node上打開一個隨機選擇的端口，連接到代理端口的請求，都會被代理轉發給Pod。那么通過Iptables規則，捕獲到達Service:Port的請求都會被轉發到代理端口，代理端口重新轉為對Pod的訪問
這種方式的缺點是存在內核態轉為用戶態，再有用戶態轉發的兩次轉換，性能較差，一般不再使用
2.Iptables模式
3.Ipvs模式
Service Iptables實現原理
Iptables表和鏈及處理過程
Service的Traffic流量將會通過prerouting和output重定向到kube-service鏈
- KUBE-SERVICES->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a ClusterIP service
- KUBE-NODEPORTS->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a NodePort service
幾種不同類型的Service在Kube-Proxy啟用Iptables模式下上的表現
- ClusterIP
- NodePort
同時，可以看到Service所申請的端口38081被Kube-proxy所代理和監聽
-
LoadBalancer
不帶有Endpoint的Service
帶有外部endpoint的Service
直接通過iptable規則轉發到對應的外部ep地址
總結
- ClusterIP類型，KubeProxy監聽Service和Endpoint創建規則，采用DNAT將目標地址轉換為Pod的ip和端口，當有多個ep時，按照策略進行轉發，默認RR模式時，iptables采用：比如有4個實例，四條規則的概率分別為0.25, 0.33, 0.5和 1，按照順序，一次匹配完成整個流量的分配。
- NodePort類型，將會在上述ClusterIP模式之后，再加上Kube-Proxy的監聽（為了確保其他服務不會占用該端口）和KUBE-NODEPORT的iptable規則
參考文獻
1、iptables https://en.wikipedia.org/wiki/Iptables
2、ipvs https://en.wikipedia.org/wiki/IP_Virtual_Server
3、K8S Service https://kubernetes.io/zh/docs/concepts/services-networking/service/
PS：過兩天給大家搞個粉絲福利，Python【電子資料+視頻教程+包郵紙質書籍】，全部免費送！可以期待一下~
文章轉載：?twt企業IT社區
（版權歸原作者所有，侵刪）