本篇內(nèi)容主要講解“如何理解Kurbernetes中服務(wù)暴露方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“如何理解Kurbernetes中服務(wù)暴露方法”吧!

成都創(chuàng)新互聯(lián)專注于磐安企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站定制開發(fā)。磐安網(wǎng)站建設(shè)公司,為磐安等地區(qū)提供建站服務(wù)。全流程按需搭建網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

由于最近在進(jìn)一步整理和學(xué)習(xí)云原生解決方案的相關(guān)材料，原來一直沒太理解清楚的就是kurbernetes中的網(wǎng)絡(luò)和服務(wù)暴露方式。最近又查找資料進(jìn)一步學(xué)習(xí)了下。

業(yè)務(wù)場景說明

在前面談DevOps解決方案的時(shí)候就談到，一個(gè)完整的DevOps持續(xù)集成和交付過程，需要和容器云集成，來實(shí)現(xiàn)自動(dòng)化部署，動(dòng)態(tài)彈性伸縮，環(huán)境遷移等能力。

一個(gè)DevOps支撐平臺(tái)離不開和容器化PaaS平臺(tái)的集成，即最終的編譯構(gòu)建完成的內(nèi)容形成鏡像并放到鏡像倉庫，后續(xù)部署，環(huán)境遷移，資源擴(kuò)展基于鏡像倉庫進(jìn)行快速的拷貝和復(fù)制。對(duì)于Docker容器一般會(huì)和K8S結(jié)合來實(shí)現(xiàn)資源的動(dòng)態(tài)調(diào)度，集群管理能力。

在原來談的時(shí)候僅僅談到通過K8s來完成部署和資源動(dòng)態(tài)擴(kuò)展的時(shí)候會(huì)從此一個(gè)VIP虛擬地址提供給應(yīng)用模塊訪問使用，而這里沒有進(jìn)行展開，今天主要是結(jié)合場景進(jìn)一步展開說明。

場景說明：

我們以整個(gè)應(yīng)用實(shí)際有兩個(gè)微服務(wù)模塊來舉例，一個(gè)是UserMgr微服務(wù)，一個(gè)是OrderMgr訂單管理微服務(wù)，這個(gè)兩個(gè)微服務(wù)都通過k8s自動(dòng)化部署到容器云環(huán)境。同時(shí)我們假設(shè)，每個(gè)微服務(wù)都動(dòng)態(tài)擴(kuò)展了2個(gè)副本Pod，即形成了三個(gè)Pod節(jié)點(diǎn)。

在這種情況下，我們不可能直接去訪問Pod IP，一個(gè)是Pod IP本身就會(huì)動(dòng)態(tài)變化，一個(gè)是集群擴(kuò)展后本身同一個(gè)微服務(wù)已經(jīng)存在多個(gè)副本Pod IP。

因此我們需要通過Service來訪問。

Kubernetes Service 定義了這樣一種抽象：一個(gè) Pod 的邏輯分組，一種可以訪問它們的策略 —— 通常稱為微服務(wù)。 這一組 Pod 能夠被  Service 訪問到，通常是通過 Label  Selector實(shí)現(xiàn)的。比如上面的UserMgr微服務(wù)，我們可以給它打一個(gè)UserMgr的標(biāo)簽，然后相同的標(biāo)簽自動(dòng)聚合到一個(gè)Service邏輯分組上面。

內(nèi)部模塊間服務(wù)訪問-ClusterIP

剛才我們談到，整個(gè)業(yè)務(wù)場景里面有UserMgr和OrderMgr兩個(gè)微服務(wù)，那么這兩個(gè)微服務(wù)之間的訪問屬于Kurbernetes集群內(nèi)部的訪問。

在這種集群內(nèi)部訪問場景下，即通過Service的ClusterIP即可。

注意ClusterIP本身是一個(gè)虛擬IP，無法Ping通，對(duì)于該IP的訪問請(qǐng)求實(shí)際是基于IPTables路由表和KubeProxy最終路由到具體的Pod實(shí)例節(jié)點(diǎn)上面。即：

Request-》ClusterIP-》IPTables+KubeProxy-》Pod Instance

如下圖：

在iptables代理模式下，對(duì)每個(gè)Service，它會(huì)安裝iptables規(guī)則，從而捕獲到達(dá)該Service的clusterIP(虛擬IP)和端口的請(qǐng)求，進(jìn)而將請(qǐng)求重定向到Service的一組backend中某個(gè)上面。對(duì)于每個(gè)Endpoints對(duì)象，它也會(huì)安裝iptables規(guī)則，這個(gè)規(guī)則會(huì)選擇一個(gè)backend  Pod。默認(rèn)的策略是，隨機(jī)選擇一個(gè)backend。

對(duì)外提供服務(wù)-NodePort方式

如果需要對(duì)外提供服務(wù)，實(shí)際上有NodePort，LoadBalancer和Ingress多種方式。下面分別來對(duì)這幾種方式做下說明。

NodePort方式主要通過每個(gè)節(jié)點(diǎn)IP加端口的形式暴露端口，訪問任意一個(gè)node  ip都可以訪問到(前提沒有指定node調(diào)度策略)，其中端口可以通過apiserver的配置文件可以看到端口暴露范圍。

比如還是上面的兩個(gè)微服務(wù)模塊部署下去后，對(duì)于8001端口可以配置為訪問UserMgr這個(gè)微服務(wù)模塊。即：10.0.0.1:8001，  10.0.0.1:8002，10.0.0.1:8003。

對(duì)于NodePort這種模式，實(shí)際上仍然是將請(qǐng)求轉(zhuǎn)發(fā)到Service上面，再通過Service路由到具體的Pod實(shí)例節(jié)點(diǎn)上面。唯一差異在于NodeIP是可以訪問到的IP地址。

這三個(gè)地址都可以訪問到用戶管理這個(gè)微服務(wù)。注意一個(gè)port端口映射到一個(gè)微服務(wù)上面，比如8001映射到UserMgr微服務(wù)，8002映射到8002微服務(wù)。上面三個(gè)地址都可以外部訪問到，如果客戶端要統(tǒng)一訪問，統(tǒng)一接入到類似Ngnix反向代理就可以了。

但是這種方式存在問題即如果新增加了Node節(jié)點(diǎn)，我們需要在集群或負(fù)載均衡上新增加配置信息，其次就是Node本身是附屬在虛擬機(jī)上面，如果整個(gè)IaaS環(huán)境的虛擬機(jī)重啟后IP地址可能發(fā)生變化，那么這個(gè)時(shí)候又需要手工進(jìn)行配置。

對(duì)外提供服務(wù)-LoadBalancer方式

這種方式主要是利用其他第三方的LB暴露服務(wù)的，阿里云或者亞馬遜的LB等等。在這種方式下注意對(duì)于每一個(gè)微服務(wù)都會(huì)消耗一個(gè)IP，因此可能帶來公有云費(fèi)用的問題。其次，也不容易形成了要給統(tǒng)一的服務(wù)訪問出口。

在這種方式下，來自外部負(fù)載均衡器的流量將直接達(dá)到 backend Pod 上，不過實(shí)際它們是如何工作的，這要依賴于云提供商。  在這些情況下，將根據(jù)用戶設(shè)置的 loadBalancerIP 來創(chuàng)建負(fù)載均衡器。

對(duì)外提供服務(wù)-Ingress方式

Ingress資源對(duì)象，用于將不同URL的訪問請(qǐng)求轉(zhuǎn)發(fā)到后端不同的Service,以實(shí)現(xiàn)HTTP層的業(yè)務(wù)路由機(jī)制。Kubernetes使用一個(gè)Ingress策略定義和一個(gè)具體的Ingress  Controller,兩者結(jié)合并實(shí)現(xiàn)了一個(gè)完整的Ingress負(fù)載均衡器。

Ingress  Controller將基于Ingress規(guī)則將客戶請(qǐng)求直接轉(zhuǎn)發(fā)到Service對(duì)應(yīng)的后端Endpoint上，這樣會(huì)跳過kube-proxy的轉(zhuǎn)發(fā)功能，kube-proxy  不再起作用。

對(duì)于Ingress完全可以理解為整個(gè)Kurbernetes集群對(duì)外的一個(gè)網(wǎng)關(guān)或代理出口。把它理解為一個(gè)對(duì)外的API網(wǎng)關(guān)也沒有問題。通過Ingress可以接入和注冊(cè)各個(gè)微服務(wù)，微服務(wù)的IP訪問地址意義，通過后面不同的路徑和url來區(qū)分具體路由到哪個(gè)微服務(wù)上面。

對(duì)于Ingress網(wǎng)關(guān)的選型

該篇文章給出了一個(gè)對(duì)比圖如下：

可以看到，當(dāng)前Kong API網(wǎng)關(guān)本身也有了Kurbernetes插件后，形成了Kong  Ingress，即既滿足了集群節(jié)點(diǎn)的對(duì)外暴露，同時(shí)又包括了Kong網(wǎng)關(guān)的一些核心能力，包括服務(wù)注冊(cè)發(fā)現(xiàn)，限流熔斷，安全等能力都可以滿足日常對(duì)API管理的需要。

簡單來說，如果你是將內(nèi)部微服務(wù)的API接口暴露出去給前端APP用，那么采用Kong Ingress應(yīng)該是一個(gè)不錯(cuò)的選擇。同時(shí)Kong ingress  還有一個(gè)非常大的優(yōu)點(diǎn)，他提供了一些 API、服務(wù)的定義，去抽象成 K8S 的 CRD，所以可以很方便地通過 K8S ingress 配置，同步到 Kong  的集群。

在DevOps集成中能做什么?

對(duì)于API網(wǎng)關(guān)和DevOps的協(xié)同，我在前面做過思考和整理如下。

我們首先看下什么時(shí)候需要涉及到API網(wǎng)關(guān)，在我們最初的概念里面是當(dāng)一個(gè)業(yè)務(wù)應(yīng)用需要對(duì)外發(fā)布API接口服務(wù)能力，這個(gè)對(duì)外發(fā)布可能是外部其它合作伙伴使用，也可能是我們自己的APP前端使用，只要存在這種場景往往就涉及到API網(wǎng)關(guān)的使用。

在一個(gè)大型項(xiàng)目的多團(tuán)隊(duì)協(xié)同下可以看到，如果都采用微服務(wù)架構(gòu)，我們實(shí)際建議的是每個(gè)團(tuán)隊(duì)都是自己獨(dú)立的微服務(wù)注冊(cè)中心，負(fù)責(zé)團(tuán)隊(duì)內(nèi)部多個(gè)微服務(wù)模塊之間的API接口調(diào)用，這些API接口調(diào)用走注冊(cè)中心即可。但是涉及到跨團(tuán)隊(duì)協(xié)同的API接口服務(wù)，那么就需要注冊(cè)到API網(wǎng)關(guān)進(jìn)行統(tǒng)一管理。

簡單來說就是，對(duì)外發(fā)布API或者跨團(tuán)隊(duì)API接口調(diào)用都需要涉及將API注冊(cè)接入到網(wǎng)關(guān)管理。

對(duì)于一個(gè)微服務(wù)模塊和API網(wǎng)關(guān)的協(xié)同，包括了提供API接口服務(wù)注冊(cè)和接入到網(wǎng)關(guān)，也包括了從網(wǎng)關(guān)調(diào)用API接口服務(wù)消費(fèi)。因此需要從API注冊(cè)接入和API消費(fèi)調(diào)用兩個(gè)方面來談協(xié)同。

API注冊(cè)接入

對(duì)于整個(gè)DevOps過程可以看到，底層是Docker容器+K8s資源調(diào)度，在我們編排流水線的時(shí)候涉及到編譯構(gòu)建和打包，部署等各個(gè)動(dòng)作。實(shí)際上可以看到在完成自動(dòng)部署后接口服務(wù)會(huì)暴露一個(gè)k8s提供出來的動(dòng)態(tài)ip訪問地址。而我們需要做的是將這個(gè)ip地址提供出來的訪問接口，注冊(cè)和接入到網(wǎng)關(guān)。

在整個(gè)過程搞清楚后，實(shí)際上我可以有兩種方式來處理API注冊(cè)接入。

1. 在部署節(jié)點(diǎn)，增加自定義腳本編寫，通過自定義運(yùn)行的腳本來完成API接口服務(wù)的注冊(cè)。

2. 增加接口注冊(cè)流水線編排節(jié)點(diǎn)，在部署節(jié)點(diǎn)完成后，編排注冊(cè)節(jié)點(diǎn)，在API注冊(cè)節(jié)點(diǎn)定義接口注冊(cè)內(nèi)容。

由于整個(gè)DevOps流水線設(shè)計(jì)和執(zhí)行偏開發(fā)人員使用，可以看到，采用第一種方式往往更加靈活。唯一的就是在定義某一個(gè)流水線的時(shí)候，需要預(yù)先規(guī)劃好需要接入和注冊(cè)的接口內(nèi)容。

而在DevOps支撐平臺(tái)雖然不需要完整的API網(wǎng)關(guān)管控功能，但是最好還是增加一個(gè)功能，就是能夠在DevOps支撐平臺(tái)查詢到當(dāng)前已經(jīng)注冊(cè)和接入了哪些接口服務(wù)，注冊(cè)接入后提供的代理服務(wù)地址是什么，是哪個(gè)微服務(wù)模塊注冊(cè)接入的該服務(wù)等基本服務(wù)目錄信息。

基于前面思考，后續(xù)我們考慮就是實(shí)現(xiàn)Kong  Ingress和K8s集群的集成，對(duì)于需要要注冊(cè)的接口服務(wù)先寫入配置文件，然后在K8s進(jìn)行微服務(wù)部署或動(dòng)態(tài)節(jié)點(diǎn)擴(kuò)展的時(shí)候，通過API調(diào)用，將接口服務(wù)自動(dòng)注冊(cè)到API網(wǎng)關(guān)上面，實(shí)現(xiàn)對(duì)外訪問。

API消費(fèi)調(diào)用

注意在采用了API網(wǎng)關(guān)后帶來的一個(gè)好處就是，API網(wǎng)關(guān)本身提供出來的API訪問地址的IP是固定的，不會(huì)隨著每次微服務(wù)模塊的自動(dòng)構(gòu)建和部署動(dòng)態(tài)變化。對(duì)于API網(wǎng)關(guān)我們會(huì)提前先部署到測試環(huán)境和生產(chǎn)環(huán)境，在網(wǎng)關(guān)部署完成后再開始進(jìn)行各個(gè)微服務(wù)模塊的持續(xù)集成和部署操作。

因此一個(gè)微服務(wù)模塊需要訪問其它微服務(wù)模塊哪些接口，一個(gè)方法是每次都調(diào)用服務(wù)注冊(cè)中心去查詢具體的服務(wù)訪問地址，一個(gè)方法就是本身要將訪問地址存在在本地配置文件。更好的方法是：

1. 首先調(diào)用先訪問服務(wù)注冊(cè)中心，獲取服務(wù)訪問地址，并存在到本地配置文件

2. 在發(fā)現(xiàn)本地配置文件已經(jīng)有服務(wù)訪問地址后，不再從服務(wù)注冊(cè)中心調(diào)用，除非得到地址變更消息通知

在這個(gè)確定后，微服務(wù)模塊本身的構(gòu)建打包和部署，實(shí)際上和原來沒有和API網(wǎng)關(guān)協(xié)同是完全一樣的，只是配置文件訪問地址固定為了API網(wǎng)關(guān)提供的地址而已。如何知道API網(wǎng)關(guān)提供了哪些地址，即我們談到的可以在API網(wǎng)關(guān)的管控平臺(tái)查詢，也可以在DevOps平臺(tái)提供的服務(wù)目錄查詢功能上進(jìn)行查詢。

到此，相信大家對(duì)“如何理解Kurbernetes中服務(wù)暴露方法”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！