一文詳解?Kubernetes?中的服務(wù)發(fā)現(xiàn)，運維請收藏

時間：2021-12-08 17:11:42

關(guān)鍵字： NET UBER TE SERVICE

手機(jī)看文章

掃描二維碼
隨時隨地手機(jī)看文章

[導(dǎo)讀]K8S服務(wù)發(fā)現(xiàn)之旅Kubernetes服務(wù)發(fā)現(xiàn)是一個經(jīng)常讓我產(chǎn)生困惑的主題之一。本文分為兩個部分：網(wǎng)絡(luò)方面的背景知識深入了解Kubernetes服務(wù)發(fā)現(xiàn)要了解服務(wù)發(fā)現(xiàn)，首先要了解背后的網(wǎng)絡(luò)知識。這部分內(nèi)容相對淺顯，如果讀者熟知這一部分，完全可以跳過，直接閱讀服務(wù)發(fā)現(xiàn)部分。開始之前...

K8S 服務(wù)發(fā)現(xiàn)之旅

Kubernetes 服務(wù)發(fā)現(xiàn)是一個經(jīng)常讓我產(chǎn)生困惑的主題之一。本文分為兩個部分：

網(wǎng)絡(luò)方面的背景知識
深入了解 Kubernetes 服務(wù)發(fā)現(xiàn)

要了解服務(wù)發(fā)現(xiàn)，首先要了解背后的網(wǎng)絡(luò)知識。這部分內(nèi)容相對淺顯，如果讀者熟知這一部分，完全可以跳過，直接閱讀服務(wù)發(fā)現(xiàn)部分。開始之前還有一個需要提醒的事情就是，為了詳細(xì)描述這一過程，本文略長。

K8S 網(wǎng)絡(luò)基礎(chǔ)

要開始服務(wù)發(fā)現(xiàn)的探索之前，需要理解以下內(nèi)容：

Kubernetes 應(yīng)用運行在容器之中，容器處于 Pod 之內(nèi)。
每個 Pod 都會附著在同一個大的扁平的 IP 網(wǎng)絡(luò)之中，被稱為 Pod 網(wǎng)絡(luò)（通常是 VXLAN 疊加網(wǎng)絡(luò)）。
每個 Pod 都有自己的唯一的 IP 地址，這個 IP 地址在 Pod 網(wǎng)絡(luò)中是可路由的。

上述三個因素結(jié)合起來，讓每個應(yīng)用（應(yīng)用的組件和服務(wù)）無需通過 NAT 之類的網(wǎng)絡(luò)過程，就能夠直接通信。

動態(tài)網(wǎng)絡(luò)

在對應(yīng)用進(jìn)行橫向擴(kuò)容時，會在 Pod 網(wǎng)絡(luò)中加入新的 Pod，新 Pod 自然也伴隨著新的 IP 地址；如果對應(yīng)用進(jìn)行縮容，舊的 Pod 及其 IP 會被刪除。這個過程看起來很是混亂。應(yīng)用的滾動更新和撤回也存在同樣的情形——加入新版本的新 Pod，或者移除舊版本的舊 Pod。新 Pod 會加入新 IP 到 Pod 網(wǎng)絡(luò)中，被終結(jié)的舊 Pod 會刪除其現(xiàn)存 IP。如果沒有其它因素，每個應(yīng)用服務(wù)都需要對網(wǎng)絡(luò)進(jìn)行監(jiān)控，并管理一個健康 Pod 的列表。這個過程會非常痛苦，另外在每個應(yīng)用中編寫這個邏輯也是很低效的。幸運的是，Kubernetes 用一個對象完成了這個過程——Service。

把這個對象叫做 Service 是個壞主意，我們已經(jīng)用這個單詞來形容應(yīng)用的進(jìn)程或組件了。

還有一個值得注意的事情：Kubernetes 執(zhí)行 IP 地址管理（IPAM）職責(zé)，對 Pod 網(wǎng)絡(luò)上已使用和可用的 IP 地址進(jìn)行跟蹤。

Service 帶來穩(wěn)定性

Kubernetes Service 對象在一組提供服務(wù)的 Pod 之前創(chuàng)建一個穩(wěn)定的網(wǎng)絡(luò)端點，并為這些 Pod 進(jìn)行負(fù)載分配。一般會在一組完成同樣工作的 Pod 之前放置一個 Service 對象。例如可以在你的 Web 前端 Pod 前方提供一個 Service，在認(rèn)證服務(wù) Pod 之前提供另一個。行使不同職責(zé)的 Pod 之前就不應(yīng)該用單一的 Service 了。客戶端和 Service 通信，Service 負(fù)責(zé)把流量負(fù)載均衡給 Pod。

在上圖中，底部的 Pod 會因為伸縮、更新、故障等情況發(fā)生變化，而 Service 會對這些變化進(jìn)行跟蹤。同時 Service 的名字、IP 和端口都不會發(fā)生變化。

K8S Service 解析

可以把 Kubernetes Service 理解為前端和后端兩部分：

前端：名稱、IP 和端口等不變的部分。
后端：符合特定標(biāo)簽選擇條件的 Pod 集合。

前端是穩(wěn)定可靠的，它的名稱、IP 和端口在 Service 的整個生命周期中都不會改變。前端的穩(wěn)定性意味著無需擔(dān)心客戶端 DNS 緩存超時等問題。后端是高度動態(tài)的，其中包括一組符合標(biāo)簽選擇條件的 Pod，會通過負(fù)載均衡的方式進(jìn)行訪問。

這里的負(fù)載均衡是一個簡單的 4 層輪詢。它工作在連接層面，所以同一個連接里發(fā)起的所有請求都會進(jìn)入同一個 Pod。因為在 4 層工作，所以對于 7 層的 HTTP 頭或者 Cookie 之類的東西是無法感知的。

小結(jié)

應(yīng)用在容器中運行，在 Kubernetes 中體現(xiàn)為 Pod 的形式。Kubernetes 集群中的所有 Pod 都處于同一個平面的 Pod 網(wǎng)絡(luò)，有自己的 IP 地址。這意味著所有的 Pod 之間都能直接連接。然而 Pod 是不穩(wěn)定的，可能因為各種因素創(chuàng)建和銷毀。Kubernetes 提供了穩(wěn)定的網(wǎng)絡(luò)端點，稱為 Service，這個對象處于一組相似的 Pod 前方，提供了穩(wěn)定的名稱、IP 和端口?？蛻舳诉B接到 Service，Service 把流量負(fù)載均衡給 Pod。接下來聊聊服務(wù)發(fā)現(xiàn)。

深入 K8S 服務(wù)發(fā)現(xiàn)

深入了解 Kubernetes 服務(wù)發(fā)現(xiàn)服務(wù)發(fā)現(xiàn)實際上包含兩個功能點：

服務(wù)注冊
服務(wù)發(fā)現(xiàn)

服務(wù)注冊

服務(wù)注冊過程指的是在服務(wù)注冊表中登記一個服務(wù)，以便讓其它服務(wù)發(fā)現(xiàn)。

Kubernetes 使用 DNS 作為服務(wù)注冊表。為了滿足這一需要，每個 Kubernetes 集群都會在 kube-system 命名空間中用 Pod 的形式運行一個 DNS 服務(wù)，通常稱之為集群 DNS。每個 Kubernetes 服務(wù)都會自動注冊到集群 DNS 之中。注冊過程大致如下：

向 API Server 用 POST 方式提交一個新的 Service 定義；
這個請求需要經(jīng)過認(rèn)證、鑒權(quán)以及其它的準(zhǔn)入策略檢查過程之后才會放行；
Service 得到一個 ClusterIP（虛擬 IP 地址），并保存到集群數(shù)據(jù)倉庫；
在集群范圍內(nèi)傳播 Service 配置；
集群 DNS 服務(wù)得知該 Service 的創(chuàng)建，據(jù)此創(chuàng)建必要的 DNS A 記錄。

上面過程中，第 5 個步驟是關(guān)鍵環(huán)節(jié)。集群 DNS 使用的是 CoreDNS，以 Kubernetes 原生應(yīng)用的形式運行。CoreDNS 實現(xiàn)了一個控制器，會對 API Server 進(jìn)行監(jiān)聽，一旦發(fā)現(xiàn)有新建的 Service 對象，就創(chuàng)建一個從 Service 名稱映射到 ClusterIP 的域名記錄。這樣 Service 就不必自行向 DNS 進(jìn)行注冊，CoreDNS 控制器會關(guān)注新創(chuàng)建的 Service 對象，并實現(xiàn)后續(xù)的 DNS 過程。DNS 中注冊的名稱就是 metadata.name，而 ClusterIP 則由 Kubernetes 自行分配。

Service 對象注冊到集群 DNS 之中后，就能夠被運行在集群中的其它 Pod 發(fā)現(xiàn)了。

Endpoint 對象

Service 的前端創(chuàng)建成功并注冊到服務(wù)注冊表（DNS）之后，剩下的就是后端的工作了。后端包含一個 Pod 列表，Service 對象會把流量分發(fā)給這些 Pod。毫無疑問，這個 Pod 列表需要是最新的。Service 對象有一個 Label Selector 字段，這個字段是一個標(biāo)簽列表，符合列表條件的 Pod 就會被服務(wù)納入到服務(wù)的負(fù)載均衡范圍之中。參見下圖：

Kubernetes 自動為每個 Service 創(chuàng)建 Endpoints 對象。Endpoints 對象的職責(zé)就是保存一個符合 Service 標(biāo)簽選擇器標(biāo)準(zhǔn)的 Pod 列表，這些 Pod 將接收來自 Service 的流量。下面的圖中，Service 會選擇兩個 Pod，并且還展示了 Service 的 Endpoints 對象，這個對象里包含了兩個符合 Service 選擇標(biāo)準(zhǔn)的 Pod 的 IP。在后面我們將解釋網(wǎng)絡(luò)如何把 ClusterIP 流量轉(zhuǎn)發(fā)給 Pod IP 的過程，還會引用到 Endpoints 對象。

服務(wù)發(fā)現(xiàn)

假設(shè)我們在一個 Kubernetes 集群中有兩個應(yīng)用，my-app 和 your-app，my-app 的 Pod 的前端是一個名為 my-app-svc 的 Service 對象；your-app Pod 之前的 Service 就是 your-app-svc。這兩個 Service 對象對應(yīng)的 DNS 記錄是：

my-app-svc：10.0.0.10
your-app-svc：10.0.0.20

要使用服務(wù)發(fā)現(xiàn)功能，每個 Pod 都需要知道集群 DNS 的位置才能使用它。因此每個 Pod 中的每個容器的 /etc/resolv.conf 文件都被配置為使用集群 DNS 進(jìn)行解析。如果 my-app 中的 Pod 想要連接到 your-app 中的 Pod，就得向 DNS 服務(wù)器發(fā)起對域名 your-app-svc 的查詢。假設(shè)它們本地的 DNS 解析緩存中沒有這個記錄，則需要把查詢提交到集群 DNS 服務(wù)器。會得到 you-app-svc 的 ClusterIP（VIP）。

這里有個前提就是 my-app 需要知道目標(biāo)服務(wù)的名稱。

至此，my-app 中的 Pod 得到了一個目標(biāo) IP 地址，然而這只是個虛擬 IP，在轉(zhuǎn)入目標(biāo) Pod 之前，還有些網(wǎng)絡(luò)工作要做。

網(wǎng)絡(luò)

一個 Pod 得到了 Service 的 ClusterIP 之后，就嘗試向這個 IP 發(fā)送流量。然而 ClusterIP 所在的網(wǎng)絡(luò)被稱為 Service Network，這個網(wǎng)絡(luò)有點特別——沒有路由指向它。因為沒有路由，所有容器把發(fā)現(xiàn)這種地址的流量都發(fā)送到了缺省網(wǎng)關(guān)（名為 CBR0 的網(wǎng)橋）。這些流量會被轉(zhuǎn)發(fā)給 Pod 所在節(jié)點的網(wǎng)卡上。節(jié)點的網(wǎng)絡(luò)棧也同樣沒有路由能到達(dá) Service Network，所以只能發(fā)送到自己的缺省網(wǎng)關(guān)。路由到節(jié)點缺省網(wǎng)關(guān)的數(shù)據(jù)包會通過 Node 內(nèi)核——這里有了變化。回顧一下前面的內(nèi)容。首先 Service 對象的配置是全集群范圍有效的，另外還會再次說到 Endpoints 對象。我們要在回顧中發(fā)現(xiàn)他們各自在這一過程中的職責(zé)。每個 Kubernetes 節(jié)點上都會運行一個叫做 kube-proxy 的系統(tǒng)服務(wù)。這是一個基于 Pod 運行的 Kubernetes 原生應(yīng)用，它所實現(xiàn)的控制器會監(jiān)控 API Server 上 Service 的變化，并據(jù)此創(chuàng)建 iptables 或者 IPVS 規(guī)則，這些規(guī)則告知節(jié)點，捕獲目標(biāo)為 Service 網(wǎng)絡(luò)的報文，并轉(zhuǎn)發(fā)給 Pod IP。

有趣的是，kube-proxy 并不是一個普遍意義上的代理。它的工作不過是創(chuàng)建和管理 iptables/IPVS 規(guī)則。這個命名的原因是它過去使用 unserspace 模式的代理。

每個新 Service 對象的配置，其中包含它的 ClusterIP 以及 Endpoints 對象（其中包含健康 Pod 的列表），都會被發(fā)送給每個節(jié)點上的 kube-proxy 進(jìn)程。kube-proxy 會創(chuàng)建 iptables 或者 IPVS 規(guī)則，告知節(jié)點捕獲目標(biāo)為 Service ClusterIP 的流量，并根據(jù) Endpoints 對象的內(nèi)容轉(zhuǎn)發(fā)給對應(yīng)的 Pod。也就是說每次節(jié)點內(nèi)核處理到目標(biāo)為 Service 網(wǎng)絡(luò)的數(shù)據(jù)包時，都會對數(shù)據(jù)包的 Header 進(jìn)行改寫，把目標(biāo) IP 改為 Service Endpoints 對象中的健康 Pod 的 IP。

原本使用的 iptables 正在被 IPVS 取代（Kubernetes 1.11 進(jìn)入穩(wěn)定期）。長話短說，iptables 是一個包過濾器，并非為負(fù)載均衡設(shè)計的。IPVS 是一個 4 層的負(fù)載均衡器，其性能和實現(xiàn)方式都比 iptables 更適合這種使用場景。

總結(jié)

需要消化的內(nèi)容很多，簡單回顧一下。創(chuàng)建新的 Service 對象時，會得到一個虛擬 IP，被稱為 ClusterIP。服務(wù)名及其 ClusterIP 被自動注冊到集群 DNS 中，并且會創(chuàng)建相關(guān)的 Endpoints 對象用于保存符合標(biāo)簽條件的健康 Pod 的列表，Service 對象會向列表中的 Pod 轉(zhuǎn)發(fā)流量。與此同時集群中所有節(jié)點都會配置相應(yīng)的 iptables/IPVS 規(guī)則，監(jiān)聽目標(biāo)為 ClusterIP 的流量并轉(zhuǎn)發(fā)給真實的 Pod IP。這個過程如下圖所示：

一個 Pod 需要用 Service 連接其它 Pod。首先向集群 DNS 發(fā)出查詢，把 Service 名稱解析為 ClusterIP，然后把流量發(fā)送給位于 Service 網(wǎng)絡(luò)的 ClusterIP 上。然而沒有到 Service 網(wǎng)絡(luò)的路由，所以 Pod 把流量發(fā)送給它的缺省網(wǎng)關(guān)。這一行為導(dǎo)致流量被轉(zhuǎn)發(fā)給 Pod 所在節(jié)點的網(wǎng)卡，然后是節(jié)點的缺省網(wǎng)關(guān)。這個操作中，節(jié)點的內(nèi)核修改了數(shù)據(jù)包 Header 中的目標(biāo) IP，使其轉(zhuǎn)向健康的 Pod。

譯者：偽架構(gòu)師