![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_2_20211111074459801)
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ò)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 是做日志收集用的)![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_3_20211111074459926)
3. pod 的負(fù)載均衡很關(guān)鍵的一個(gè)問題:一組相關(guān)的 pod 副本,如何實(shí)現(xiàn)訪問負(fù)載均衡?就如當(dāng)請求達(dá)到,請求轉(zhuǎn)發(fā)給哪個(gè) pod 比較好?一個(gè)想法就是用 pod 再部署一個(gè) Nginx。舉例:如下圖,注意下圖右邊的 Node 里面有兩個(gè)是 支付 服務(wù),與訂單服務(wù)的是不同類型的 pod。如果一個(gè)請求訂單的服務(wù)發(fā)來上面那個(gè) Nginx,那這個(gè) pod 可以有 4 條轉(zhuǎn)發(fā)路線,可以想到用 hash 呀什么的把不同請求映射到不同的 pod 去轉(zhuǎn)發(fā)。但能不能這么做呢?![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_4_2021111107450020) 思考:pod 是一個(gè)進(jìn)程,是有生命周期的,一旦宕機(jī)、版本更新都會(huì)創(chuàng)建新的 pod( IP 地址會(huì)變化,hostname 會(huì)變化),此時(shí)再使用 Nginx 做負(fù)載均衡不太合適,因?yàn)樗恢?pod 發(fā)生了改變,那請求就不能被接受了。所以服務(wù)發(fā)生了變化它根本不知道,Nginx 無法發(fā)現(xiàn)服務(wù),不能用 Nginx 做負(fù)載均衡。那該如何實(shí)現(xiàn)呢?使用 Service 資源對(duì)象。3.1 什么是 Service 資源對(duì)象- 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) 和端口。請求會(huì)訪問 service,然后 service 自己會(huì) 負(fù)載均衡 地發(fā)送給相應(yīng)服務(wù)的 POD,也就是下圖中 4 個(gè)相同的 pod。![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_5_20211111074500145)
3.3 深入 service VIP- service 和 pod 都是一個(gè)進(jìn)程,都是虛擬的,因此實(shí)際上 service 也不能對(duì)外網(wǎng)提供服務(wù)
- service 和 pod 之間可以直接進(jìn)行通信,它們的通信屬于局域網(wǎng)通信
- 負(fù)載策略:把請求交給 service 后,service 使用 iptables,ipvs 來實(shí)現(xiàn)數(shù)據(jù)包的分發(fā)
而要對(duì)外網(wǎng)提供服務(wù),首先需要和之前一樣 在物理機(jī)上也綁定一個(gè)端口 來接受訪問請求,然后把請求轉(zhuǎn)發(fā)給 service,service 再把數(shù)據(jù)包分發(fā)給相應(yīng)的 POD。訪問流程如下圖所示:![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_6_20211111074500287) 思考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)起來)。![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_7_20211111074500442) 思考2:pod 宕機(jī)或發(fā)布新版本了,service 是如何發(fā)現(xiàn) pod 已經(jīng)發(fā)生變化的?通過 k8s 中的一個(gè)組件 —— kube-proxy (第 1 篇有提到過),每個(gè) NODE 里都運(yùn)行著這個(gè)服務(wù)。它需要做的工作如下圖右側(cè):![Image](http://image109.360doc.com/DownloadImg/2021/11/1107/233792747_8_20211111074500567) 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)系。來源:https://blog.csdn.net/qq_43280818/article/details/107164860
|