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

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

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

手機看文章

掃描二維碼
隨時隨地手機看文章

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

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

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

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

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

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

2. pod 如何對外提供訪問

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

3. pod 的負載均衡

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

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

3.1 什么是 Service 資源對象

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

3.2 service 如何實現(xiàn)負載均衡

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

3.3 深入 service VIP

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

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

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

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

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