|
1. 復習 pod 相關核心結構1.1 pod 結構- pod 相當于一個容器，pod 有獨立的 ip 地址,，也有自己的 hostname,，利用 namespace 進行資源隔離，相當于一個獨立沙箱環(huán)境,。
- pod 內(nèi)部封裝的是容器,，可以封裝一個，或者多個容器（通常是一組相關的容器）
1.2 pod 網(wǎng)絡2. pod 如何對外提供訪問首先 pod 有自己的 IP 和 hostname,，但 pod 是虛擬的資源對象 (在計算機中表現(xiàn)為進程),，沒有對應實體 (物理機，物理網(wǎng)卡) 與之對應,，所以是無法直接對外提供服務訪問的,。因此如果 pod 想對外提供服務，必須綁定物理機端口 (即在物理機上開啟端口,，讓這個端口和 pod 的端口進行映射),，這樣就可以通過物理機進行數(shù)據(jù)包的轉發(fā),。下面以一臺 Linux 系統(tǒng)的機器為例子（ logstash 是做日志收集用的）
3. pod 的負載均衡很關鍵的一個問題：一組相關的 pod 副本，如何實現(xiàn)訪問負載均衡,？就如當請求達到,，請求轉發(fā)給哪個 pod 比較好？一個想法就是用 pod 再部署一個 Nginx,。舉例：如下圖,，注意下圖右邊的 Node 里面有兩個是 支付 服務，與訂單服務的是不同類型的 pod,。如果一個請求訂單的服務發(fā)來上面那個 Nginx,，那這個 pod 可以有 4 條轉發(fā)路線，可以想到用 hash 呀什么的把不同請求映射到不同的 pod 去轉發(fā),。但能不能這么做呢,？
思考：pod 是一個進程，是有生命周期的,，一旦宕機,、版本更新都會創(chuàng)建新的 pod（ IP 地址會變化，hostname 會變化）,，此時再使用 Nginx 做負載均衡不太合適,，因為它不知道 pod 發(fā)生了改變，那請求就不能被接受了,。所以服務發(fā)生了變化它根本不知道,，Nginx 無法發(fā)現(xiàn)服務，不能用 Nginx 做負載均衡,。那該如何實現(xiàn)呢？使用 Service 資源對象,。3.1 什么是 Service 資源對象- cluster IP：虛擬 IP,，是由 kubernetes 抽象出的 service 對象，這個 service 對象就是一個 VIP (virtual IP, VIP) 的資源對象
3.2 service 如何實現(xiàn)負載均衡例如現(xiàn)在要負載均衡地訪問一組相同的服務副本——訂單,，這時就要去做一個 service,，對外表現(xiàn)出是一個進程或資源對象，有虛擬的 IP (VIP) 和端口,。請求會訪問 service,，然后 service 自己會 負載均衡 地發(fā)送給相應服務的 POD，也就是下圖中 4 個相同的 pod,。
3.3 深入 service VIP- service 和 pod 都是一個進程,，都是虛擬的，因此實際上 service 也不能對外網(wǎng)提供服務
- service 和 pod 之間可以直接進行通信,，它們的通信屬于局域網(wǎng)通信
- 負載策略：把請求交給 service 后,，service 使用 iptables,，ipvs 來實現(xiàn)數(shù)據(jù)包的分發(fā)
而要對外網(wǎng)提供服務，首先需要和之前一樣 在物理機上也綁定一個端口 來接受訪問請求,，然后把請求轉發(fā)給 service,，service 再把數(shù)據(jù)包分發(fā)給相應的 POD。訪問流程如下圖所示：
思考1：那 service 對象是如何和 pod 進行關聯(lián)的呢,？它們之間的關聯(lián)利用的 還是標簽選擇器 selector,。且service 只能對 一組相同的副本 提供服務，不能跨組提供服務,。如果有另一組,，需要再創(chuàng)建一個 service。因此不同的業(yè)務會有不同的 service,。舉例：service 和 一組 pod 副本是通過標簽選擇器進行關聯(lián)的,，相同的副本的標簽是一樣的。selector：app = x 選擇一組訂單的服務的 pod,，創(chuàng)建一個 service,；app = y 選擇了一組支付的服務的 pod。通過一個 endpoints 屬性存儲這組 pod 的 IP 地址,，這樣就有了映射關系了 (關聯(lián)起來),。
思考2：pod 宕機或發(fā)布新版本了，service 是如何發(fā)現(xiàn) pod 已經(jīng)發(fā)生變化的,？通過 k8s 中的一個組件 —— kube-proxy (第 1 篇有提到過),，每個 NODE 里都運行著這個服務。它需要做的工作如下圖右側：
service 實現(xiàn)服務的發(fā)現(xiàn)：kube-proxy 監(jiān)控 pod,，一旦發(fā)現(xiàn) pod 服務變化,，將會把新的 ip 地址更新到 service。注意：endpoints 那些都是存儲在 etcd 里的 (也是第 1 篇提到過的),，所以 kube-proxy 更新的存儲在 etcd 里的映射關系,。來源：https://blog.csdn.net/qq_43280818/article/details/107164860
|
