K8S Service實戰(zhàn)與原理初探
【作者】陳成，中國聯(lián)通軟件研究院容器云研發(fā)工程師，公共平臺與架構(gòu)研發(fā)事業(yè)部云計算研發(fā)組長，長期從事大規(guī)模基礎(chǔ)平臺建設(shè)相關(guān)工作，先后從事Mesos、KVM、K8S等研究，專注于容器云計算框架、集群調(diào)度、虛擬化等。
故事的開始，讓我們先從一件生產(chǎn)故障說起。5月29日，內(nèi)部某系統(tǒng)出現(xiàn)大規(guī)模訪問Service故障，發(fā)現(xiàn)Pod容器內(nèi)無法正常訪問ServiceIP:Port，整個故障持續(xù)時間超過12h，相關(guān)運維支撐人員沒有找到根本原因和解決辦法。
經(jīng)過復(fù)盤，我們發(fā)現(xiàn)，大家對于K8S Service的原理不夠清晰，導(dǎo)致對問題的定位不能做得到快速準(zhǔn)確，如果當(dāng)時能夠按照如下的思路去思考問題，排查過程不至于花費如此久的時間。
下面，我們就來細(xì)說一下Service在Kubernetes中的作用、使用方法及原理。
Service是一種暴露一組Pod網(wǎng)絡(luò)的抽象方式，K8S Service提供了針對于一組Pod的負(fù)載均衡的暴露。通過這樣的方式，可以避免不同的pod之間訪問時需要知曉對應(yīng)pod網(wǎng)絡(luò)信息的痛苦。例如：前端->后端，由于前端POD IP隨時變動，后端亦如此，如何處理前端POD和后端POD的通信，就需要Service這一抽象，來保證簡單可靠。
Service的使用
1、典型服務(wù)配置方法
當(dāng)配置了selector之后，Service Controller會自動查找匹配這個selector的pod，并且創(chuàng)建出一個同名的endpoint對象，負(fù)責(zé)具體service之后連接。
2、配置沒有selector的服務(wù)
沒有selector的service不會出現(xiàn)Endpoint的信息，需要手工創(chuàng)建Endpoint綁定，Endpoint可以是內(nèi)部的pod，也可以是外部的服務(wù)。
Service的類型
1.CluserIP
2.LoadBalance
對定義了選擇算符的無頭服務(wù)，Endpoint 控制器在 API 中創(chuàng)建了 Endpoints 記錄， 并且修改 DNS 配置返回 A 記錄（IP 地址），通過這個地址直接到達(dá) Service 的后端 Pod 上。
- 對于 ExternalName 類型的服務(wù)，查找其 CNAME 記錄
- 對所有其他類型的服務(wù)，查找與 Service 名稱相同的任何 Endpoints 的記錄
Service的實現(xiàn)方式
1.用戶態(tài)代理訪問
即：當(dāng)對于每個Service，Kube-Proxy會在本地Node上打開一個隨機(jī)選擇的端口，連接到代理端口的請求，都會被代理轉(zhuǎn)發(fā)給Pod。那么通過Iptables規(guī)則，捕獲到達(dá)Service:Port的請求都會被轉(zhuǎn)發(fā)到代理端口，代理端口重新轉(zhuǎn)為對Pod的訪問
這種方式的缺點是存在內(nèi)核態(tài)轉(zhuǎn)為用戶態(tài)，再有用戶態(tài)轉(zhuǎn)發(fā)的兩次轉(zhuǎn)換，性能較差，一般不再使用
2.Iptables模式
3.Ipvs模式
Service Iptables實現(xiàn)原理
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模式下上的表現(xiàn)
- ClusterIP
NodePort
同時，可以看到Service所申請的端口38081被Kube-proxy所代理和監(jiān)聽
-
LoadBalancer
不帶有Endpoint的Service
帶有外部endpoint的Service
直接通過iptable規(guī)則轉(zhuǎn)發(fā)到對應(yīng)的外部ep地址
總結(jié)
- ClusterIP類型，KubeProxy監(jiān)聽Service和Endpoint創(chuàng)建規(guī)則，采用DNAT將目標(biāo)地址轉(zhuǎn)換為Pod的ip和端口，當(dāng)有多個ep時，按照策略進(jìn)行轉(zhuǎn)發(fā)，默認(rèn)RR模式時，iptables采用：比如有4個實例，四條規(guī)則的概率分別為0.25, 0.33, 0.5和 1，按照順序，一次匹配完成整個流量的分配。
- NodePort類型，將會在上述ClusterIP模式之后，再加上Kube-Proxy的監(jiān)聽（為了確保其他服務(wù)不會占用該端口）和KUBE-NODEPORT的iptable規(guī)則
參考文獻(xiàn)
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/
文章轉(zhuǎn)載：twt企業(yè)IT社區(qū)
（版權(quán)歸原作者所有，侵刪）