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

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

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比公主嶺網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式公主嶺網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋公主嶺地區(qū)。費用合理售后完善，10年實體公司更值得信賴。

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

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

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

2、iptables或ipvs，到底是iptables還是ipvs呢？

一個Service對象就是工作節(jié)點上的一些iptables或ipvs規(guī)則，用于將到達Service對象IP地址的流量調(diào)度轉(zhuǎn)發(fā)至相應的Endpoints對象指向的IP地址和端口之上。

這句話我們經(jīng)常看到，如何理解呢？

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

在Kubernetes1.1版本開始引入iptables規(guī)則，Kubernetes1.2開始成為默認類型。即在創(chuàng)建Service資源時，集群上每個節(jié)點的kube-proxy都會收到通知，并且創(chuàng)建iptables規(guī)則，用于轉(zhuǎn)發(fā)到此Service ClusterIP的流量。工作TCP/IP的傳輸層，高效穩(wěn)定。
但是這種方式有如下缺點：

1、iptables代理模型挑中的pod無響應時，不能自動重定向到集群內(nèi)部其它pod資源對象之上。

2、kube-proxy通過iptables處理Service和pod的交互，每產(chǎn)生一個計算節(jié)點或者產(chǎn)生大量的pod就需要產(chǎn)生相應大量的iptables規(guī)則，不難想象，這些iptables規(guī)則每次需要刷新匹配保證正確性，就需要占用大量的CPU資源，所以基于iptables的Service實現(xiàn)就成了制約Kubernetes承載更多pod的瓶頸。

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

3、Kubernetes的服務發(fā)現(xiàn)是通過DNS實現(xiàn)，那么為什么會出現(xiàn)四種類型的服務暴露方式呢？

說到Service不得不介紹kubernetes網(wǎng)絡模型和通信方式

一個完整的Kubernetes集群應該包含三層網(wǎng)絡，首先第一層是mater和node節(jié)點之間的網(wǎng)絡，這個網(wǎng)絡需要在部署kubernetes集群之前配置完成；

第二層網(wǎng)絡是pod的網(wǎng)絡通過kubelet或者cni插件實現(xiàn)，用于pod之間或者內(nèi)部的通信，集群中的所有pod均處在同一個網(wǎng)絡平面空間內(nèi)，可以直接通信；

第三層網(wǎng)絡是Service資源的網(wǎng)絡，是一個虛擬網(wǎng)絡，用于為Kubernetes集群配置IP地址，但此地址并不配置于任何主機或者容器的網(wǎng)絡接口之上，而是通過kubeproxy配置為iptables規(guī)則，將發(fā)往該地址的所有流量調(diào)度至后端的pod之上。

通信方式分為以下四種：

同一個pod的內(nèi)部通信；
各個pod彼此通信；
pod和service的通信；
集群外部流向service的通信。

所以Service為了滿足這些通信方式就出現(xiàn)了如下類型：

ClusterIP：為集群內(nèi)部ip地址暴露服務，僅在集群內(nèi)可達，外部ip無法訪問，默認Service類型；

NodePort：這種類型建立在clusterIp之上，為節(jié)點的IP地址暴NodePort服務，外部節(jié)點可以通過NodeIP:NodePort直接訪問；

LoadBalancer：這種類型構(gòu)建在NodePort之上，它可以關聯(lián)到集群外部的某個負載均衡設備。Kubernetes沒有為私有化集群提供LoadBalancer的支持。如果在私有化集群使用需要自建負載均衡器；

ExternalName：其通過將Service映射至由externalName字段的內(nèi)容指定的主機名來暴露服務，此主機名需要被DNS服務解析至CNAME類型的記錄。這句話怎么理解呢？

舉個例子，你所有的服務都在集群內(nèi)部，但是你有個數(shù)據(jù)庫是MongoDB，沒有實現(xiàn)容器化，更沒有部署在Kubernetes內(nèi)部，當然你可以通過在ConfigMap中添加配置訪問這個外部服務，但是當你的環(huán)境發(fā)生變化，比如從開發(fā)環(huán)境和生產(chǎn)環(huán)境的數(shù)據(jù)地址不同，這個時候你需要修改和重建ConfigMap。

這個時候可以使用Kubernetes ExternalName內(nèi)置服務發(fā)現(xiàn)機制運用于集群外部運行的服務，像使用集群內(nèi)的服務一樣使用外部服務！通過這種方式，您可以在開發(fā)環(huán)境和生產(chǎn)環(huán)境中實現(xiàn)相同的功能，如果您最終將服務移入集群內(nèi)，則不需要更改任何代碼和配置。

kind: ServiceapiVersion: v1metadata: name: mongospec: type: ExternalName externalName: mango123456.com

你只需要訪問：mongodb://<dbuser>:<dbpassword>@mongo:<port>就可以自動訪問外部服務。

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

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

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

targetPort：pod目標端口，如果不設置使用默認port端口，port和nodePort的數(shù)據(jù)通過這個端口進入到Pod內(nèi)部，Pod里面的containers的端口映射到這個端口，提供服務；

nodePort：Kubernetes集群外部用戶訪問端口；

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

名稱欄目：Kubernetes里的Service究竟是如何工作的
本文來源：http://bm7419.com/article20/igcgco.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、App開發(fā)、網(wǎng)站營銷、App設計、手機網(wǎng)站建設、網(wǎng)站維護

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容