通俗理解?Kubernetes?中的服務(wù)，搞懂后真“有趣”

時(shí)間：2021-12-08 17:11:42

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

手機(jī)看文章

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

[導(dǎo)讀]1.復(fù)習(xí)pod相關(guān)核心結(jié)構(gòu)1.1pod結(jié)構(gòu)pod相當(dāng)于一個(gè)容器，pod有獨(dú)立的ip地址，也有自己的hostname，利用namespace進(jìn)行資源隔離，相當(dāng)于一個(gè)獨(dú)立沙箱環(huán)境。pod內(nèi)部封裝的是容器，可以封裝一個(gè)，或者多個(gè)容器（通常是一組相關(guān)的容器）1.2pod網(wǎng)絡(luò)pod有自己獨(dú)...

1. 復(fù)習(xí) pod 相關(guān)核心結(jié)構(gòu)

1.1 pod 結(jié)構(gòu)

pod 相當(dāng)于一個(gè)容器，pod 有獨(dú)立的 ip 地址，也有自己的 hostname，利用 namespace 進(jìn)行資源隔離，相當(dāng)于一個(gè)獨(dú)立沙箱環(huán)境。
pod 內(nèi)部封裝的是容器，可以封裝一個(gè)，或者多個(gè)容器（通常是一組相關(guān)的容器）

1.2 pod 網(wǎng)絡(luò)

pod 有自己獨(dú)立的 IP 地址
pod 內(nèi)部的容器之間是通過 localhost 進(jìn)行訪問

2. pod 如何對(duì)外提供訪問

首先 pod 有自己的 IP 和 hostname，但 pod 是虛擬的資源對(duì)象 (在計(jì)算機(jī)中表現(xiàn)為進(jìn)程)，沒有對(duì)應(yīng)實(shí)體 (物理機(jī)，物理網(wǎng)卡) 與之對(duì)應(yīng)，所以是無法直接對(duì)外提供服務(wù)訪問的。因此如果 pod 想對(duì)外提供服務(wù)，必須綁定物理機(jī)端口 (即在物理機(jī)上開啟端口，讓這個(gè)端口和 pod 的端口進(jìn)行映射)，這樣就可以通過物理機(jī)進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)。下面以一臺(tái) Linux 系統(tǒng)的機(jī)器為例子（ logstash 是做日志收集用的）

3. pod 的負(fù)載均衡

很關(guān)鍵的一個(gè)問題：一組相關(guān)的 pod 副本，如何實(shí)現(xiàn)訪問負(fù)載均衡？就如當(dāng)請(qǐng)求達(dá)到，請(qǐng)求轉(zhuǎn)發(fā)給哪個(gè) pod 比較好？一個(gè)想法就是用 pod 再部署一個(gè) Nginx。舉例：如下圖，注意下圖右邊的 Node 里面有兩個(gè)是支付服務(wù)，與訂單服務(wù)的是不同類型的 pod。如果一個(gè)請(qǐng)求訂單的服務(wù)發(fā)來上面那個(gè) Nginx，那這個(gè) pod 可以有 4 條轉(zhuǎn)發(fā)路線，可以想到用 hash 呀什么的把不同請(qǐng)求映射到不同的 pod 去轉(zhuǎn)發(fā)。但能不能這么做呢？

思考：pod 是一個(gè)進(jìn)程，是有生命周期的，一旦宕機(jī)、版本更新都會(huì)創(chuàng)建新的 pod（ IP 地址會(huì)變化，hostname 會(huì)變化），此時(shí)再使用 Nginx 做負(fù)載均衡不太合適，因?yàn)樗恢?pod 發(fā)生了改變，那請(qǐng)求就不能被接受了。所以服務(wù)發(fā)生了變化它根本不知道，Nginx 無法發(fā)現(xiàn)服務(wù)，不能用 Nginx 做負(fù)載均衡。那該如何實(shí)現(xiàn)呢？使用 Service 資源對(duì)象。

3.1 什么是 Service 資源對(duì)象

POD IP：pod 的 IP 地址
NODE IP：物理機(jī)的 IP 地址
cluster IP：虛擬 IP，是由 kubernetes 抽象出的 service 對(duì)象，這個(gè) service 對(duì)象就是一個(gè) VIP (virtual IP, VIP) 的資源對(duì)象

3.2 service 如何實(shí)現(xiàn)負(fù)載均衡

例如現(xiàn)在要負(fù)載均衡地訪問一組相同的服務(wù)副本——訂單，這時(shí)就要去做一個(gè) service，對(duì)外表現(xiàn)出是一個(gè)進(jìn)程或資源對(duì)象，有虛擬的 IP (VIP) 和端口。請(qǐng)求會(huì)訪問 service，然后 service 自己會(huì) 負(fù)載均衡地發(fā)送給相應(yīng)服務(wù)的 POD，也就是下圖中 4 個(gè)相同的 pod。

3.3 深入 service VIP

service 和 pod 都是一個(gè)進(jìn)程，都是虛擬的，因此實(shí)際上 service 也不能對(duì)外網(wǎng)提供服務(wù)
service 和 pod 之間可以直接進(jìn)行通信，它們的通信屬于局域網(wǎng)通信
負(fù)載策略：把請(qǐng)求交給 service 后，service 使用 iptables，ipvs 來實(shí)現(xiàn)數(shù)據(jù)包的分發(fā)

而要對(duì)外網(wǎng)提供服務(wù)，首先需要和之前一樣在物理機(jī)上也綁定一個(gè)端口來接受訪問請(qǐng)求，然后把請(qǐng)求轉(zhuǎn)發(fā)給 service，service 再把數(shù)據(jù)包分發(fā)給相應(yīng)的 POD。訪問流程如下圖所示：

思考1：那 service 對(duì)象是如何和 pod 進(jìn)行關(guān)聯(lián)的呢？它們之間的關(guān)聯(lián)利用的還是標(biāo)簽選擇器 selector。且service 只能對(duì) 一組相同的副本提供服務(wù)，不能跨組提供服務(wù)。如果有另一組，需要再創(chuàng)建一個(gè) service。因此不同的業(yè)務(wù)會(huì)有不同的 service。舉例：service 和一組 pod 副本是通過標(biāo)簽選擇器進(jìn)行關(guān)聯(lián)的，相同的副本的標(biāo)簽是一樣的。selector：app = x 選擇一組訂單的服務(wù)的 pod，創(chuàng)建一個(gè) service；app = y 選擇了一組支付的服務(wù)的 pod。通過一個(gè) endpoints 屬性存儲(chǔ)這組 pod 的 IP 地址，這樣就有了映射關(guān)系了 (關(guān)聯(lián)起來)。

思考2：pod 宕機(jī)或發(fā)布新版本了，service 是如何發(fā)現(xiàn) pod 已經(jīng)發(fā)生變化的？通過 k8s 中的一個(gè)組件 —— kube-proxy (第 1 篇有提到過)，每個(gè) NODE 里都運(yùn)行著這個(gè)服務(wù)。它需要做的工作如下圖右側(cè)：

service 實(shí)現(xiàn)服務(wù)的發(fā)現(xiàn)：kube-proxy 監(jiān)控 pod，一旦發(fā)現(xiàn) pod 服務(wù)變化，將會(huì)把新的 ip 地址更新到 service。注意：endpoints 那些都是存儲(chǔ)在 etcd 里的 (也是第 1 篇提到過的)，所以 kube-proxy 更新的存儲(chǔ)在 etcd 里的映射關(guān)系。