1.核心組件原理—— pod 核心原理

1.1 pod 是什麼

  • pod 也可以理解是一個容器,裝的是docker 創建的容器,也就是用來封裝容器的一個容器;
  • pod 是一個虛擬化分組, 有自己的IP 地址和主機名hostname,利用namespace 進行資源隔離,相當於一台獨立沙箱環境;
  • pod 相當於一台獨立主機,內部可以封裝一個或多個容器(通常是一組相關的容器),內部容器之間訪問採用localhost。

1.2 pod 用來幹什麼

通常情況下,在服務部署的時候,使用pod 來管理一組相關的服務(一個pod 中要么部署一個服務,要么部署一組有關係的服務)。如下圖是部署了一組有關係的服務的結構圖,其中C 表示容器(container),下面的pod 裡就有很多個容器。

如何理解一組相關的服務?

如下圖:有一個請求是訪問Nginx,然後部署了Nginx 的容器就把請求轉發給部署了web 服務的容器,web 再訪問數據庫,然後請求會依次返回來數據,最後再返回給用戶。

因此在鍊式調用的調用鏈路上的服務叫做一組相關的服務。

 

1.3 實現web 服務集群

只需要復制多個pod 的副本即可,這也是k8s 管理的先進之處。k8s 如果要進行擴容或縮容,只需要控制pod 的數量即可。比如上面那個部署模式,服務集群就是複制多個這樣的pod。

Kubernetes 核心組件原理梳理,運維必備~插圖(3)

 

1.4 pod 底層網絡和數據存儲是如何進行的

前面說過pod 內部的容器也是一個獨立的沙箱環境,因此也有自己的ip 和端口。如果內部容器還是通過ip:port 來通信,相當於還是遠程訪問,這樣的話性能會受到一定的影響。如何提高內部容器之間訪問的性能呢?

 

pod 底層

  • pod 內部容器創建之前,必須先創建pause 容器。pause 有兩個作用:共享網絡和共享存儲。
  • 每個服務容器共享pause 存儲,不需要自己存儲數據,都交給pause維護。
  • pause 也相當於這三個容器的網卡,因此他們之間的訪問可以通過localhost 方式訪問,相當於訪問本地服務一樣,性能非常高(就像本地幾台虛擬機之間可以ping 通)。

2. ReplicaSet 副本控制器

2.1 副本控制器基本理解

作用:管理控制pod 副本(服務集群)的數量,以使其永遠與預期設定的數量保持一致。

例如:replicas = 3 (創建3 個副本,這是提前設置好的)

 

當副本設置為3 時,副本控制器將會永遠保證副本數量為3。因此當有pod 服務宕機時(如上面第3 個pod),那副本控制器會立馬重新創建一個新的pod,就能夠保證副本數量一直為預先設定好的3 個。

2.2 ReplicaSet 和ReplicationController 的區別

ReplicaSet 和ReplicationController 都是副本控制器,其中:

  • 相同點:都有前面2.1 節所描述的功能
  • 不同點:標籤選擇器的功能不同。ReplicaSet 可以使用標籤選擇器進行單选和複合選擇;而ReplicationController 只支持單選操作。

什麼意思呢?

假設下面有下面兩個不同機器上的Node 結點,如何知道它們的pod 其實都是相同的呢?答案是通過標籤。

給每個pod 打上標籤( key=value 格式,如下圖中的app=web, release=stable,這有兩個選項,相同的pod副本的標籤是一樣的),於是副本控制器可以通過標籤選擇器seletor 去選擇一組相關的服務。

一旦selector 和pod 的標籤匹配上了,就表明這個pod 是當前這個副本控制器控制的,表明了副本控制器和pod 的所屬關係。如下圖中seletor 指定了app = web 和release=stable 是複合選擇,要用ReplicaSet 才能實現若用ReplicationController 的話只能選擇一個,如只選擇匹配app=web標籤。這樣下面的3 個pod 就歸這個副本控制器管。

 

可見ReplicaSet 功能更齊全,所以在新版的k8s 中,建議使用ReplicaSet 作為副本控制器,不再使用ReplicationController。

3. Deployment 部署對象

3.1 滾動更新

ReplicaSet 副本控制器可以永久保持pod 副本的數量。但是項目的需求在不斷的迭代、更新,項目在不斷發版。那如何做到服務更新?難道把服務停掉再把新版本部署上去嗎?當然不是,答案是用滾動更新。就是重新創建一個pod (v2版本) 來代替之前的pod (v1版本)。

 

那是如何滾動更新的呢?涉及到下面要講到的部署模型。

3.2 部署模型

單獨的ReplicaSet 是不支持滾動更新的,Deployment 對象支持滾動更新,通常和ReplicaSet 一起使用。

需要滾動更新時的步驟:

  1. Deployment 建立新的Replicaset
  2. Replicaset 重新建立新的pod

所以它們之間是有層次關係的,Deployment 管Replicaset,Replicaset 維護pod。在更新時刪除的是舊的pod,老版本的ReplicaSet 是不會刪除的,所以在需要時還可以回退以前的狀態。

 

4. StatefulSet 部署有狀態服務

4.1 引入定義

思考:如果MySQL(有狀態服務) 使用容器化部署,會存在什麼問題?

  1. 容器都是有生命週期的,一旦宕機數據就很可能丟失
  2. pod 也有生命週期的,用pod 部署時把pod 集群副本重啟以後也可能會出現數據丟失

因此對k8s 來說,不能使用Deployment 部署有狀態的服務。通常情況下,Deployment 被用來部署無狀態服務。

然後StatefulSet 就是為了解決有狀態服務使用容器化部署的一個問題。

4.2 如何理解狀態服務

  • 有狀態服務
  • 有實時的數據需要存儲
  • 在有狀態服務集群中,如果把某一個服務抽離出來,一段時間後再加入回集群網絡,此後集群網絡會無法使用
  • 無狀態服務
  • 沒有實時的數據需要存儲
  • 在無狀態服務集群中,如果把某一個服務抽離出去,一段時間後再加入回集群網絡,對集群服務無任何影響,因為它們不需要做交互,不需要數據同步等等。

4.3 部署模型

StatefulSet 的部署模型和Deployment 的很相似。

比如下圖,借助PVC(與存儲有關) 文件系統來存儲的實時數據,因此下圖就是一個有狀態服務的部署。

在pod 宕機之後重新建立pod 時,StatefulSet 通過保證hostname 不發生變化來保證數據不丟失。因此pod 就可以通過hostname 來關聯(找到) 之前存儲的數據。

 

原文鏈接:https://blog.csdn.net/qq_43280818/article/details/106910187

By tony

自由軟體愛好者~喜歡不斷的思考各種問題,有新的事物都會想去學習嘗試 做實驗並熱衷研究 沒有所謂頂天的技術 只有謙虛及不斷的學習 精進專業,本站主要以分享系統及網路相關知識、資源而建立。 Github http://stnet253.github.io

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料