通俗易懂k8s——服務的註冊與發現

語言: CN / TW / HK

這一塊是 k8s 比較核心且抽象的部分,但會採用通俗易懂的方式來講

複習 pod 相關核心結構

pod 結構

pod 相當於一個容器,pod 有獨立的 ip 地址,也有自己的 hostname,利用 namespace 進行資源隔離,相當於一個獨立沙箱環境。

pod 內部封裝的是容器,可以封裝一個,或者多個容器(通常是一組相關的容器)

pod 網路

pod 有自己獨立的 IP 地址

pod 內部的容器之間是通過 localhost 進行訪問

pod 如何對外提供訪問

首先 pod 有自己的 IP 和 hostname,但 pod 是虛擬的資源物件 (在計算機中表現為程序),沒有對應實體 (物理機,物理網絡卡) 與之對應,所以是無法直接對外提供服務訪問的。

因此如果 pod 想對外提供服務,必須繫結物理機埠 (即在物理機上開啟埠,讓這個埠和 pod 的埠進行對映),這樣就可以通過物理機進行資料包的轉發。

下面以一臺 Linux 系統的機器為例子

pod 的負載均衡

很關鍵的一個問題:一組相關的 pod 副本,如何實現訪問負載均衡?就如當請求達到,請求轉發給哪個 pod 比較好?

一個想法就是用 pod 再部署一個 Nginx。

舉例:如下圖,注意下圖右邊的 Node 裡面有兩個是 支付 服務,與訂單服務的是不同型別的 pod。如果一個請求訂單的服務發來上面那個 Nginx,那這個 pod 可以有 4 條轉發路線,可以想到用 hash 呀什麼的把不同請求對映到不同的 pod 去轉發。但能不能這麼做呢?

思考:pod 是一個程序,是有生命週期的,一旦宕機、版本更新都會建立新的 pod( IP 地址會變化,hostname 會變化),此時再使用 Nginx 做負載均衡不太合適,因為它不知道 pod 發生了改變,那請求就不能被接受了。所以服務發生了變化它根本不知道,Nginx 無法發現服務,不能用 Nginx 做負載均衡。那該如何實現呢?使用 Service 資源物件。

什麼是 Service 資源物件

  • POD IP:pod 的 IP 地址

  • NODE IP:物理機的 IP 地址

  • cluster IP:虛擬 IP,是由 kubernetes 抽象出的 service 物件,這個 service 物件就是一個 VIP (virtual IP, VIP) 的資源物件

service 如何實現負載均衡

例如現在要負載均衡地訪問一組相同的服務副本——訂單,這時就要去做一個 service,對外表現出是一個程序或資源物件,有虛擬的 IP (VIP) 和埠。請求會訪問 service,然後 service 自己會 負載均衡 地傳送給相應服務的 POD,也就是下圖中 4 個相同的 pod。

深入 service VIP

  • service 和 pod 都是一個程序,都是虛擬的,因此實際上 service 也不能對外網提供服務

  • service 和 pod 之間可以直接進行通訊,它們的通訊屬於區域網通訊

  • 負載策略:把請求交給 service 後,service 使用 iptables,ipvs 來實現資料包的分發

而要對外網提供服務,首先需要和之前一樣 在物理機上也繫結一個埠 來接受訪問請求,然後把請求轉發給 service,service 再把資料包分發給相應的 POD。訪問流程如下圖所示:

思考1:那 service 物件是如何和 pod 進行關聯的呢?它們之間的關聯利用的 還是標籤選擇器 selector。且service 只能對 一組相同的副本 提供服務,不能跨組提供服務。如果有另一組,需要再建立一個 service。因此不同的業務會有不同的 service。

舉例:service 和 一組 pod 副本是通過標籤選擇器進行關聯的,相同的副本的標籤是一樣的。

selector:app = x 選擇一組訂單的服務的 pod,建立一個 service;app = y 選擇了一組支付的服務的 pod。通過一個 endpoints 屬性儲存這組 pod 的 IP 地址,這樣就有了對映關係了 (關聯起來)。

思考2:pod 宕機或釋出新版本了,service 是如何發現 pod 已經發生變化的?通過 k8s 中的一個元件 —— kube-proxy (第 1 篇有提到過),每個 NODE 裡都執行著這個服務。它需要做的工作如下圖右側:

service 實現服務的發現:kube-proxy 監控 pod,一旦發現 pod 服務變化,將會把新的 ip 地址更新到 service。

注意:endpoints 那些都是儲存在 etcd 裡的 (也是第 1 篇提到過的),所以 kube-proxy 更新的儲存在 etcd 裡的對映關係。

社群交流群

「運維研習社」建立了運維技術交流群,分享技術、職場、兼職、內推等,大家可以新增小編微信進行加群。歡迎有想法、樂於分享的朋友們一起進群交流學習。

掃描新增好友邀您進運維交流群

●通俗易懂k8s——核心元件

通俗易懂k8s——架構篇

Nginx優化之——ALPN

Linux下du和ls計算的檔案大小竟然差10倍?

這套Nginx日誌解決方案,真香!