如何理解Kurbernetes中服務(wù)暴露方法

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

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

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

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

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

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

場景說明：

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

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

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

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

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

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

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

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

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

如下圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

該篇文章給出了一個對比圖如下：

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

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

在DevOps集成中能做什么?

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

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

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

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

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

API注冊接入

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

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

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

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

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

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

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

API消費調(diào)用

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

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

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

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

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

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