淺談?Kubernetes?中的服務(wù)發(fā)現(xiàn)
[導(dǎo)讀]原文：https://nigelpoulton.com/blog/f/demystifying-kubernetes-service-discoveryKubernetes服務(wù)發(fā)現(xiàn)是一個(gè)經(jīng)常讓我產(chǎn)生困惑的主題之一。本文分為兩個(gè)部分：網(wǎng)絡(luò)方面的背景知識(shí)深入了解Kubernetes服...
原文：https://nigelpoulton.com/blog/f/demystifying-kubernetes-service-discoveryKubernetes 服務(wù)發(fā)現(xiàn)是一個(gè)經(jīng)常讓我產(chǎn)生困惑的主題之一。本文分為兩個(gè)部分：
上述三個(gè)因素結(jié)合起來(lái)，讓每個(gè)應(yīng)用（應(yīng)用的組件和服務(wù)）無(wú)需通過(guò) NAT 之類的網(wǎng)絡(luò)過(guò)程，就能夠直接通信。
在上圖中，底部的 Pod 會(huì)因?yàn)樯炜s、更新、故障等情況發(fā)生變化，而 Service 會(huì)對(duì)這些變化進(jìn)行跟蹤。同時(shí) Service 的名字、IP 和端口都不會(huì)發(fā)生變化。
這里的負(fù)載均衡是一個(gè)簡(jiǎn)單的 4 層輪詢。它工作在連接層面，所以同一個(gè)連接里發(fā)起的所有請(qǐng)求都會(huì)進(jìn)入同一個(gè) Pod。因?yàn)樵?4 層工作，所以對(duì)于 7 層的 HTTP 頭或者 Cookie 之類的東西是無(wú)法感知的。
Kubernetes 使用 DNS 作為服務(wù)注冊(cè)表。為了滿足這一需要，每個(gè) Kubernetes 集群都會(huì)在 kube-system 命名空間中用 Pod 的形式運(yùn)行一個(gè) DNS 服務(wù)，通常稱之為集群 DNS。每個(gè) Kubernetes 服務(wù)都會(huì)自動(dòng)注冊(cè)到集群 DNS 之中。注冊(cè)過(guò)程大致如下：Service 對(duì)象注冊(cè)到集群 DNS 之中后，就能夠被運(yùn)行在集群中的其它 Pod 發(fā)現(xiàn)了。
Kubernetes 自動(dòng)為每個(gè) Service 創(chuàng)建 Endpoints 對(duì)象。Endpoints 對(duì)象的職責(zé)就是保存一個(gè)符合 Service 標(biāo)簽選擇器標(biāo)準(zhǔn)的 Pod 列表，這些 Pod 將接收來(lái)自 Service 的流量。下面的圖中，Service 會(huì)選擇兩個(gè) Pod，并且還展示了 Service 的 Endpoints 對(duì)象，這個(gè)對(duì)象里包含了兩個(gè)符合 Service 選擇標(biāo)準(zhǔn)的 Pod 的 IP。在后面我們將解釋網(wǎng)絡(luò)如何把 ClusterIP 流量轉(zhuǎn)發(fā)給 Pod IP 的過(guò)程，還會(huì)引用到 Endpoints 對(duì)象。要使用服務(wù)發(fā)現(xiàn)功能，每個(gè) Pod 都需要知道集群 DNS 的位置才能使用它。因此每個(gè) Pod 中的每個(gè)容器的?/etc/resolv.conf 文件都被配置為使用集群 DNS 進(jìn)行解析。如果 my-app 中的 Pod 想要連接到 your-app 中的 Pod，就得向 DNS 服務(wù)器發(fā)起對(duì)域名 your-app-svc 的查詢。假設(shè)它們本地的 DNS 解析緩存中沒(méi)有這個(gè)記錄，則需要把查詢提交到集群 DNS 服務(wù)器。會(huì)得到 you-app-svc 的 ClusterIP（VIP）。一個(gè) Pod 需要用 Service 連接其它 Pod。首先向集群 DNS 發(fā)出查詢，把 Service 名稱解析為 ClusterIP，然后把流量發(fā)送給位于 Service 網(wǎng)絡(luò)的 ClusterIP 上。然而沒(méi)有到 Service 網(wǎng)絡(luò)的路由，所以 Pod 把流量發(fā)送給它的缺省網(wǎng)關(guān)。這一行為導(dǎo)致流量被轉(zhuǎn)發(fā)給 Pod 所在節(jié)點(diǎn)的網(wǎng)卡，然后是節(jié)點(diǎn)的缺省網(wǎng)關(guān)。這個(gè)操作中，節(jié)點(diǎn)的內(nèi)核修改了數(shù)據(jù)包 Header 中的目標(biāo) IP，使其轉(zhuǎn)向健康的 Pod。最終所有 Pod 都是在同一個(gè)可路由的扁平的疊加網(wǎng)絡(luò)上，剩下的內(nèi)容就很簡(jiǎn)單了。
- 網(wǎng)絡(luò)方面的背景知識(shí)
- 深入了解 Kubernetes 服務(wù)發(fā)現(xiàn)
Kubernetes 網(wǎng)絡(luò)基礎(chǔ)
要開(kāi)始服務(wù)發(fā)現(xiàn)的探索之前，需要理解以下內(nèi)容：- Kubernetes 應(yīng)用運(yùn)行在容器之中，容器處于 Pod 之內(nèi)。
- 每個(gè) Pod 都會(huì)附著在同一個(gè)大的扁平的 IP 網(wǎng)絡(luò)之中，被稱為 Pod 網(wǎng)絡(luò)（通常是 VXLAN 疊加網(wǎng)絡(luò)）。
- 每個(gè) Pod 都有自己的唯一的 IP 地址，這個(gè) IP 地址在 Pod 網(wǎng)絡(luò)中是可路由的。
上述三個(gè)因素結(jié)合起來(lái)，讓每個(gè)應(yīng)用（應(yīng)用的組件和服務(wù)）無(wú)需通過(guò) NAT 之類的網(wǎng)絡(luò)過(guò)程，就能夠直接通信。動(dòng)態(tài)網(wǎng)絡(luò)
在對(duì)應(yīng)用進(jìn)行橫向擴(kuò)容時(shí)，會(huì)在 Pod 網(wǎng)絡(luò)中加入新的 Pod，新 Pod 自然也伴隨著新的 IP 地址；如果對(duì)應(yīng)用進(jìn)行縮容，舊的 Pod 及其 IP 會(huì)被刪除。這個(gè)過(guò)程看起來(lái)很是混亂。應(yīng)用的滾動(dòng)更新和撤回也存在同樣的情形——加入新版本的新 Pod，或者移除舊版本的舊 Pod。新 Pod 會(huì)加入新 IP 到 Pod 網(wǎng)絡(luò)中，被終結(jié)的舊 Pod 會(huì)刪除其現(xiàn)存 IP。如果沒(méi)有其它因素，每個(gè)應(yīng)用服務(wù)都需要對(duì)網(wǎng)絡(luò)進(jìn)行監(jiān)控，并管理一個(gè)健康 Pod 的列表。這個(gè)過(guò)程會(huì)非常痛苦，另外在每個(gè)應(yīng)用中編寫(xiě)這個(gè)邏輯也是很低效的。幸運(yùn)的是，Kubernetes 用一個(gè)對(duì)象完成了這個(gè)過(guò)程——Service。把這個(gè)對(duì)象叫做 Service 是個(gè)壞主意，我們已經(jīng)用這個(gè)單詞來(lái)形容應(yīng)用的進(jìn)程或組件了。還有一個(gè)值得注意的事情：Kubernetes 執(zhí)行 IP 地址管理（IPAM）職責(zé)，對(duì) Pod 網(wǎng)絡(luò)上已使用和可用的 IP 地址進(jìn)行跟蹤。
Service 帶來(lái)穩(wěn)定性
Kubernetes Service 對(duì)象在一組提供服務(wù)的 Pod 之前創(chuàng)建一個(gè)穩(wěn)定的網(wǎng)絡(luò)端點(diǎn)，并為這些 Pod 進(jìn)行負(fù)載分配。一般會(huì)在一組完成同樣工作的 Pod 之前放置一個(gè) Service 對(duì)象。例如可以在你的 Web 前端 Pod 前方提供一個(gè) Service，在認(rèn)證服務(wù) Pod 之前提供另一個(gè)。行使不同職責(zé)的 Pod 之前就不應(yīng)該用單一的 Service 了。客戶端和 Service 通信，Service 負(fù)責(zé)把流量負(fù)載均衡給 Pod。在上圖中，底部的 Pod 會(huì)因?yàn)樯炜s、更新、故障等情況發(fā)生變化，而 Service 會(huì)對(duì)這些變化進(jìn)行跟蹤。同時(shí) Service 的名字、IP 和端口都不會(huì)發(fā)生變化。
Kubernetes Service 解析
可以把 Kubernetes Service 理解為前端和后端兩部分：- 前端：名稱、IP 和端口等不變的部分。
- 后端：符合特定標(biāo)簽選擇條件的 Pod 集合。
這里的負(fù)載均衡是一個(gè)簡(jiǎn)單的 4 層輪詢。它工作在連接層面，所以同一個(gè)連接里發(fā)起的所有請(qǐng)求都會(huì)進(jìn)入同一個(gè) Pod。因?yàn)樵?4 層工作，所以對(duì)于 7 層的 HTTP 頭或者 Cookie 之類的東西是無(wú)法感知的。
小結(jié)
應(yīng)用在容器中運(yùn)行，在 Kubernetes 中體現(xiàn)為 Pod 的形式。Kubernetes 集群中的所有 Pod 都處于同一個(gè)平面的 Pod 網(wǎng)絡(luò)，有自己的 IP 地址。這意味著所有的 Pod 之間都能直接連接。然而 Pod 是不穩(wěn)定的，可能因?yàn)楦鞣N因素創(chuàng)建和銷毀。Kubernetes 提供了穩(wěn)定的網(wǎng)絡(luò)端點(diǎn)，稱為 Service，這個(gè)對(duì)象處于一組相似的 Pod 前方，提供了穩(wěn)定的名稱、IP 和端口?？蛻舳诉B接到 Service，Service 把流量負(fù)載均衡給 Pod。接下來(lái)聊聊服務(wù)發(fā)現(xiàn)。深入了解 Kubernetes 服務(wù)發(fā)現(xiàn)
服務(wù)發(fā)現(xiàn)實(shí)際上包含兩個(gè)功能點(diǎn)：- 服務(wù)注冊(cè)
- 服務(wù)發(fā)現(xiàn)
服務(wù)注冊(cè)
服務(wù)注冊(cè)過(guò)程指的是在服務(wù)注冊(cè)表中登記一個(gè)服務(wù)，以便讓其它服務(wù)發(fā)現(xiàn)。Kubernetes 使用 DNS 作為服務(wù)注冊(cè)表。為了滿足這一需要，每個(gè) Kubernetes 集群都會(huì)在 kube-system 命名空間中用 Pod 的形式運(yùn)行一個(gè) DNS 服務(wù)，通常稱之為集群 DNS。每個(gè) Kubernetes 服務(wù)都會(huì)自動(dòng)注冊(cè)到集群 DNS 之中。注冊(cè)過(guò)程大致如下：
- 向 API Server 用 POST 方式提交一個(gè)新的 Service 定義；
- 這個(gè)請(qǐng)求需要經(jīng)過(guò)認(rèn)證、鑒權(quán)以及其它的準(zhǔn)入策略檢查過(guò)程之后才會(huì)放行；
- Service 得到一個(gè) ClusterIP（虛擬 IP 地址），并保存到集群數(shù)據(jù)倉(cāng)庫(kù)；
- 在集群范圍內(nèi)傳播 Service 配置；
- 集群 DNS 服務(wù)得知該 Service 的創(chuàng)建，據(jù)此創(chuàng)建必要的 DNS A 記錄。
Service 對(duì)象注冊(cè)到集群 DNS 之中后，就能夠被運(yùn)行在集群中的其它 Pod 發(fā)現(xiàn)了。Endpoint 對(duì)象
Service 的前端創(chuàng)建成功并注冊(cè)到服務(wù)注冊(cè)表（DNS）之后，剩下的就是后端的工作了。后端包含一個(gè) Pod 列表，Service 對(duì)象會(huì)把流量分發(fā)給這些 Pod。毫無(wú)疑問(wèn)，這個(gè) Pod 列表需要是最新的。Service 對(duì)象有一個(gè) Label Selector 字段，這個(gè)字段是一個(gè)標(biāo)簽列表，符合列表?xiàng)l件的 Pod 就會(huì)被服務(wù)納入到服務(wù)的負(fù)載均衡范圍之中。參見(jiàn)下圖：Kubernetes 自動(dòng)為每個(gè) Service 創(chuàng)建 Endpoints 對(duì)象。Endpoints 對(duì)象的職責(zé)就是保存一個(gè)符合 Service 標(biāo)簽選擇器標(biāo)準(zhǔn)的 Pod 列表，這些 Pod 將接收來(lái)自 Service 的流量。下面的圖中，Service 會(huì)選擇兩個(gè) Pod，并且還展示了 Service 的 Endpoints 對(duì)象，這個(gè)對(duì)象里包含了兩個(gè)符合 Service 選擇標(biāo)準(zhǔn)的 Pod 的 IP。在后面我們將解釋網(wǎng)絡(luò)如何把 ClusterIP 流量轉(zhuǎn)發(fā)給 Pod IP 的過(guò)程，還會(huì)引用到 Endpoints 對(duì)象。
服務(wù)發(fā)現(xiàn)
假設(shè)我們?cè)谝粋€(gè) Kubernetes 集群中有兩個(gè)應(yīng)用，my-app 和 your-app，my-app 的 Pod 的前端是一個(gè) 名為 my-app-svc 的 Service 對(duì)象；your-app Pod 之前的 Service 就是 your-app-svc。這兩個(gè) Service 對(duì)象對(duì)應(yīng)的 DNS 記錄是：- my-app-svc：10.0.0.10
- your-app-svc：10.0.0.20
要使用服務(wù)發(fā)現(xiàn)功能，每個(gè) Pod 都需要知道集群 DNS 的位置才能使用它。因此每個(gè) Pod 中的每個(gè)容器的?/etc/resolv.conf 文件都被配置為使用集群 DNS 進(jìn)行解析。如果 my-app 中的 Pod 想要連接到 your-app 中的 Pod，就得向 DNS 服務(wù)器發(fā)起對(duì)域名 your-app-svc 的查詢。假設(shè)它們本地的 DNS 解析緩存中沒(méi)有這個(gè)記錄，則需要把查詢提交到集群 DNS 服務(wù)器。會(huì)得到 you-app-svc 的 ClusterIP（VIP）。這里有個(gè)前提就是 my-app 需要知道目標(biāo)服務(wù)的名稱。至此，my-app 中的 Pod 得到了一個(gè)目標(biāo) IP 地址，然而這只是個(gè)虛擬 IP，在轉(zhuǎn)入目標(biāo) Pod 之前，還有些網(wǎng)絡(luò)工作要做。
網(wǎng)絡(luò)
一個(gè) Pod 得到了 Service 的 ClusterIP 之后，就嘗試向這個(gè) IP 發(fā)送流量。然而 ClusterIP 所在的網(wǎng)絡(luò)被稱為 Service Network，這個(gè)網(wǎng)絡(luò)有點(diǎn)特別——沒(méi)有路由指向它。因?yàn)闆](méi)有路由，所有容器把發(fā)現(xiàn)這種地址的流量都發(fā)送到了缺省網(wǎng)關(guān)（名為 CBR0?的網(wǎng)橋）。這些流量會(huì)被轉(zhuǎn)發(fā)給 Pod 所在節(jié)點(diǎn)的網(wǎng)卡上。節(jié)點(diǎn)的網(wǎng)絡(luò)棧也同樣沒(méi)有路由能到達(dá) Service Network，所以只能發(fā)送到自己的缺省網(wǎng)關(guān)。路由到節(jié)點(diǎn)缺省網(wǎng)關(guān)的數(shù)據(jù)包會(huì)通過(guò) Node 內(nèi)核——這里有了變化。回顧一下前面的內(nèi)容。首先 Service 對(duì)象的配置是全集群范圍有效的，另外還會(huì)再次說(shuō)到 Endpoints 對(duì)象。我們要在回顧中發(fā)現(xiàn)他們各自在這一過(guò)程中的職責(zé)。每個(gè) Kubernetes 節(jié)點(diǎn)上都會(huì)運(yùn)行一個(gè)叫做 kube-proxy 的系統(tǒng)服務(wù)。這是一個(gè)基于 Pod 運(yùn)行的 Kubernetes 原生應(yīng)用，它所實(shí)現(xiàn)的控制器會(huì)監(jiān)控 API Server 上 Service 的變化，并據(jù)此創(chuàng)建 iptables 或者 IPVS 規(guī)則，這些規(guī)則告知節(jié)點(diǎn)，捕獲目標(biāo)為 Service 網(wǎng)絡(luò)的報(bào)文，并轉(zhuǎn)發(fā)給 Pod IP。有趣的是，kube-proxy 并不是一個(gè)普遍意義上的代理。它的工作不過(guò)是創(chuàng)建和管理 iptables/IPVS 規(guī)則。這個(gè)命名的原因是它過(guò)去使用 unserspace 模式的代理。每個(gè)新 Service 對(duì)象的配置，其中包含它的 ClusterIP 以及 Endpoints 對(duì)象（其中包含健康 Pod 的列表），都會(huì)被發(fā)送給 每個(gè)節(jié)點(diǎn)上的 kube-proxy 進(jìn)程。kube-proxy 會(huì)創(chuàng)建 iptables 或者 IPVS 規(guī)則，告知節(jié)點(diǎn)捕獲目標(biāo)為 Service ClusterIP 的流量，并根據(jù) Endpoints 對(duì)象的內(nèi)容轉(zhuǎn)發(fā)給對(duì)應(yīng)的 Pod。也就是說(shuō)每次節(jié)點(diǎn)內(nèi)核處理到目標(biāo)為 Service 網(wǎng)絡(luò)的數(shù)據(jù)包時(shí)，都會(huì)對(duì)數(shù)據(jù)包的 Header 進(jìn)行改寫(xiě)，把目標(biāo) IP 改為 Service Endpoints 對(duì)象中的健康 Pod 的 IP。
原本使用的 iptables 正在被 IPVS 取代（Kubernetes 1.11 進(jìn)入穩(wěn)定期）。長(zhǎng)話短說(shuō)，iptables 是一個(gè)包過(guò)濾器，并非為負(fù)載均衡設(shè)計(jì)的。IPVS 是一個(gè) 4 層的負(fù)載均衡器，其性能和實(shí)現(xiàn)方式都比 iptables 更適合這種使用場(chǎng)景。
總結(jié)
需要消化的內(nèi)容很多，簡(jiǎn)單回顧一下。創(chuàng)建新的 Service 對(duì)象時(shí)，會(huì)得到一個(gè)虛擬 IP，被稱為 ClusterIP。服務(wù)名及其 ClusterIP 被自動(dòng)注冊(cè)到集群 DNS 中，并且會(huì)創(chuàng)建相關(guān)的 Endpoints 對(duì)象用于保存符合標(biāo)簽條件的健康 Pod 的列表，Service 對(duì)象會(huì)向列表中的 Pod 轉(zhuǎn)發(fā)流量。與此同時(shí)集群中所有節(jié)點(diǎn)都會(huì)配置相應(yīng)的 iptables/IPVS 規(guī)則，監(jiān)聽(tīng)目標(biāo)為 ClusterIP 的流量并轉(zhuǎn)發(fā)給真實(shí)的 Pod IP。這個(gè)過(guò)程如下圖所示：一個(gè) Pod 需要用 Service 連接其它 Pod。首先向集群 DNS 發(fā)出查詢，把 Service 名稱解析為 ClusterIP，然后把流量發(fā)送給位于 Service 網(wǎng)絡(luò)的 ClusterIP 上。然而沒(méi)有到 Service 網(wǎng)絡(luò)的路由，所以 Pod 把流量發(fā)送給它的缺省網(wǎng)關(guān)。這一行為導(dǎo)致流量被轉(zhuǎn)發(fā)給 Pod 所在節(jié)點(diǎn)的網(wǎng)卡，然后是節(jié)點(diǎn)的缺省網(wǎng)關(guān)。這個(gè)操作中，節(jié)點(diǎn)的內(nèi)核修改了數(shù)據(jù)包 Header 中的目標(biāo) IP，使其轉(zhuǎn)向健康的 Pod。最終所有 Pod 都是在同一個(gè)可路由的扁平的疊加網(wǎng)絡(luò)上，剩下的內(nèi)容就很簡(jiǎn)單了。 
下載文檔
