溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶(hù)服務(wù)條款》

Kubernetes里的Service究竟是如何工作的

發(fā)布時(shí)間：2021-12-21 17:39:48 來(lái)源：億速云 閱讀：152 作者：柒染 欄目：云計(jì)算

這篇文章將為大家詳細(xì)講解有關(guān)Kubernetes里的Service究竟是如何工作的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

Service是Kubernetes接入層的一種抽象資源，它為我們提供了一種固定的、統(tǒng)一的訪(fǎng)問(wèn)接口地址和負(fù)載均衡能力，這時(shí)可能會(huì)想到，當(dāng)時(shí)使用docker-compose的時(shí)候，不存在Service概念，不也運(yùn)行起來(lái)了嗎？是的，在Kubernetes集群內(nèi)部Pod ip也是互通的，但是Pod的ip會(huì)經(jīng)常因?yàn)閿U(kuò)容、重建而導(dǎo)致客戶(hù)端訪(fǎng)問(wèn)錯(cuò)誤，pod訪(fǎng)問(wèn)無(wú)法提供負(fù)載均衡的能力，而Service通過(guò)選擇一組Pod的label就直接可以訪(fǎng)問(wèn)到Pod，而且可以使用萬(wàn)年不變的域名，所以就選擇Service了。

1、Service是怎么產(chǎn)生的，在集群內(nèi)部是如何存在的呢？

在kubernetes當(dāng)中所謂的Service是kube-proxy生成iptables或ipvs規(guī)則，它會(huì)產(chǎn)生一組虛擬地址，在集群環(huán)境下有效。Service不能直接到達(dá)Pod內(nèi)部，中間會(huì)間隔EndPoints，這是一組ip和port的組合。默認(rèn)類(lèi)型是ClusterIP它僅能接收集群中pod客戶(hù)端程序的訪(fǎng)問(wèn)請(qǐng)求。這也是最常用的一種類(lèi)型，另外還有NodePort、LoadBalancer、ExternalName。

2、iptables或ipvs，到底是iptables還是ipvs呢？
一個(gè)Service對(duì)象就是工作節(jié)點(diǎn)上的一些iptables或ipvs規(guī)則，用于將到達(dá)Service對(duì)象IP地址的流量調(diào)度轉(zhuǎn)發(fā)至相應(yīng)的Endpoints對(duì)象指向的IP地址和端口之上。  
這句話(huà)我們經(jīng)?？吹?，如何理解呢？

Kubernetes1.1之前是基于userspace實(shí)現(xiàn)，這種模型之下，每次請(qǐng)求流量要先到達(dá)內(nèi)核空間，經(jīng)有套接字轉(zhuǎn)發(fā)到kube-proxy，然后再由它送回到內(nèi)核空間，之后調(diào)度到后端pod之上，可以看出請(qǐng)求在用戶(hù)空間和內(nèi)核空間來(lái)回轉(zhuǎn)發(fā)，效率必然不高。但是當(dāng)pod無(wú)響應(yīng)時(shí)，能夠自動(dòng)重定向到其它pod。

在Kubernetes1.1版本開(kāi)始引入iptables規(guī)則，Kubernetes1.2開(kāi)始成為默認(rèn)類(lèi)型。即在創(chuàng)建Service資源時(shí)，集群上每個(gè)節(jié)點(diǎn)的kube-proxy都會(huì)收到通知，并且創(chuàng)建iptables規(guī)則，用于轉(zhuǎn)發(fā)到此Service ClusterIP的流量。工作TCP/IP的傳輸層，高效穩(wěn)定。
 但是這種方式有如下缺點(diǎn)：
1、iptables代理模型挑中的pod無(wú)響應(yīng)時(shí)，不能自動(dòng)重定向到集群內(nèi)部其它pod資源對(duì)象之上。  
2、kube-proxy通過(guò)iptables處理Service和pod的交互，每產(chǎn)生一個(gè)計(jì)算節(jié)點(diǎn)或者產(chǎn)生大量的pod就需要產(chǎn)生相應(yīng)大量的iptables規(guī)則，不難想象，這些iptables規(guī)則每次需要刷新匹配保證正確性，就需要占用大量的CPU資源，所以基于iptables的Service實(shí)現(xiàn)就成了制約Kubernetes承載更多pod的瓶頸。

在Kubernetes1.11開(kāi)始默認(rèn)使用ipvs模型，在這種模型下kube-proxy會(huì)跟蹤APIServer上Service和endpoints對(duì)象變化，調(diào)用netlink創(chuàng)建ipvs規(guī)則，請(qǐng)求調(diào)度流量功能由ipvs實(shí)現(xiàn)，運(yùn)行于netfilter之上的鉤子函數(shù)，具有流量轉(zhuǎn)發(fā)速度快，規(guī)則性能同步好的特點(diǎn)，支持眾多調(diào)度算法，剩下仍然由iptables完成。說(shuō)到這里我們就大概明白了iptables和ipvs的作用和關(guān)系了。

3、Kubernetes的服務(wù)發(fā)現(xiàn)是通過(guò)dns實(shí)現(xiàn)，那么為什么會(huì)出現(xiàn)四種類(lèi)型的服務(wù)暴露方式呢？
說(shuō)到Service不得不介紹kubernetes網(wǎng)絡(luò)模型和通信方式

一個(gè)完整的Kubernetes集群應(yīng)該包含三層網(wǎng)絡(luò)，首先第一層是mater和node節(jié)點(diǎn)之間的網(wǎng)絡(luò)，這個(gè)網(wǎng)絡(luò)需要在部署kubernetes集群之前配置完成；
第二層網(wǎng)絡(luò)是pod的網(wǎng)絡(luò)通過(guò)kubelet或者cni插件實(shí)現(xiàn)，用于pod之間或者內(nèi)部的通信，集群中的所有pod均處在同一個(gè)網(wǎng)絡(luò)平面空間內(nèi)，可以直接通信；
第三層網(wǎng)絡(luò)是Service資源的網(wǎng)絡(luò)，是一個(gè)虛擬網(wǎng)絡(luò)，用于為Kubernetes集群配置IP地址，但此地址并不配置于任何主機(jī)或者容器的網(wǎng)絡(luò)接口之上，而是通過(guò)kubeproxy配置為iptables規(guī)則，將發(fā)往該地址的所有流量調(diào)度至后端的pod之上。

通信方式分為以下四種：

  • 同一個(gè)pod的內(nèi)部通信；

  • 各個(gè)pod彼此通信；

  • pod和service的通信；

  • 集群外部流向service的通信。


所以Service為了滿(mǎn)足這些通信方式就出現(xiàn)了如下類(lèi)型：
ClusterIP：為集群內(nèi)部ip地址暴露服務(wù)，僅在集群內(nèi)可達(dá)，外部ip無(wú)法訪(fǎng)問(wèn)，默認(rèn)Service類(lèi)型；

NodePort：這種類(lèi)型建立在clusterIp之上，為節(jié)點(diǎn)的IP地址暴NodePort服務(wù)，外部節(jié)點(diǎn)可以通過(guò)NodeIP:NodePort直接訪(fǎng)問(wèn)；

LoadBalancer：這種類(lèi)型構(gòu)建在NodePort之上，它可以關(guān)聯(lián)到集群外部的某個(gè)負(fù)載均衡設(shè)備。Kubernetes沒(méi)有為私有化集群提供LoadBalancer的支持。如果在私有化集群使用需要自建負(fù)載均衡器；
ExternalName：其通過(guò)將Service映射至由externalName字段的內(nèi)容指定的主機(jī)名來(lái)暴露服務(wù)，此主機(jī)名需要被DNS服務(wù)解析至CNAME類(lèi)型的記錄。這句話(huà)怎么理解呢？

舉個(gè)例子，你所有的服務(wù)都在集群內(nèi)部，但是你有個(gè)數(shù)據(jù)庫(kù)是mongodb，沒(méi)有實(shí)現(xiàn)容器化，更沒(méi)有部署在Kubernetes內(nèi)部，當(dāng)然你可以通過(guò)在ConfigMap中添加配置訪(fǎng)問(wèn)這個(gè)外部服務(wù)，但是當(dāng)你的環(huán)境發(fā)生變化，比如從開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境的數(shù)據(jù)地址不同，這個(gè)時(shí)候你需要修改和重建ConfigMap。
這個(gè)時(shí)候可以使用Kubernetes  ExternalName內(nèi)置服務(wù)發(fā)現(xiàn)機(jī)制運(yùn)用于集群外部運(yùn)行的服務(wù)，像使用集群內(nèi)的服務(wù)一樣使用外部服務(wù)！通過(guò)這種方式，您可以在開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境中實(shí)現(xiàn)相同的功能，如果您最終將服務(wù)移入集群內(nèi)，則不需要更改任何代碼和配置。  
kind: ServiceapiVersion: v1metadata: name: mongospec: type: ExternalName externalName: mango123456.com
你只需要訪(fǎng)問(wèn)：mongodb://<dbuser>:<dbpassword>@mongo:<port>就可以自動(dòng)訪(fǎng)問(wèn)外部服務(wù)。

4、Service本身有端口、Pod也有端口、容器也有端口，之間有什么關(guān)系呢？

containerPort：一個(gè)信息性數(shù)據(jù)，為集群提供一個(gè)可以快速了解相關(guān)pod可以訪(fǎng)問(wèn)端口的途徑，而且顯式指定容器端口，無(wú)論你是否指定都不影響其他節(jié)點(diǎn)上的客戶(hù)端pod對(duì)其進(jìn)行訪(fǎng)問(wèn)；

port：服務(wù)提供端口，用于kubernetes集群內(nèi)部服務(wù)訪(fǎng)問(wèn)；

targetPort：pod目標(biāo)端口，如果不設(shè)置使用默認(rèn)port端口，port和nodePort的數(shù)據(jù)通過(guò)這個(gè)端口進(jìn)入到Pod內(nèi)部，Pod里面的containers的端口映射到這個(gè)端口，提供服務(wù)；
nodePort：Kubernetes集群外部用戶(hù)訪(fǎng)問(wèn)端口；

關(guān)于Kubernetes里的Service究竟是如何工作的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手