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

1.1 pod 是什么

pod 也可以理解是一個容器，裝的是 docker 創(chuàng)建的容器，也就是用來封裝容器的一個容器；

pod 是一個虛擬化分組， 有自己的 IP 地址和主機名 hostname，利用 namespace 進行資源隔離，相當于一臺獨立沙箱環(huán)境；

pod 相當于一臺獨立主機，內(nèi)部可以封裝一個或多個容器(通常是一組相關的容器)，內(nèi)部容器之間訪問采用 localhost。

1.2 pod 用來干什么

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

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

如下圖：有一個請求是訪問 Nginx，然后部署了 Nginx 的容器就把請求轉發(fā)給部署了 web 服務的容器，web 再訪問數(shù)據(jù)庫，然后請求會依次返回來數(shù)據(jù)，最后再返回給用戶。因此在 鏈式調(diào)用的調(diào)用鏈路上的服務 叫做一組相關的服務。

1.3 實現(xiàn) web 服務集群

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

1.4 pod 底層網(wǎng)絡和數(shù)據(jù)存儲是如何進行的

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

pod 底層

pod 內(nèi)部容器創(chuàng)建之前，必須先創(chuàng)建 pause 容器。pause 有兩個作用：共享網(wǎng)絡和共享存儲。

每個服務容器共享 pause 存儲，不需要自己存儲數(shù)據(jù)，都交給 pause維護。

pause 也相當于這三個容器的網(wǎng)卡，因此他們之間的訪問可以通過 localhost 方式訪問，相當于訪問本地服務一樣，性能非常高（就像本地幾臺虛擬機之間可以 ping 通）。

2. ReplicaSet 副本控制器

2.1 副本控制器基本理解

作用：管理控制 pod 副本（服務集群）的數(shù)量，以使其永遠與預期設定的數(shù)量保持一致。例如：replicas = 3 （創(chuàng)建 3 個副本，這是提前設置好的）

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

2.2 ReplicaSet 和 ReplicationController 的區(qū)別

ReplicaSet 和 ReplicationController 都是副本控制器，其中：

相同點：都有前面 2.1 節(jié)所描述的功能

不同點：標簽選擇器的功能不同。ReplicaSet 可以使用標簽選擇器進行 單選 和 復合選擇；而 ReplicationController 只支持 單選操作。

什么意思呢？

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

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

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

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

3. Deployment 部署對象

3.1 滾動更新

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

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

3.2 部署模型

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

需要滾動更新時的步驟：

Deployment 建立新的 Replicaset

Replicaset 重新建立新的 pod

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

4. StatefulSet 部署有狀態(tài)服務

4.1 引入定義

思考：如果 MySQL(有狀態(tài)服務) 使用容器化部署，會存在什么問題？

1、容器都是有生命周期的，一旦宕機數(shù)據(jù)就很可能丟失

2、pod 也有生命周期的，用 pod 部署時把 pod 集群副本重啟以后也可能會出現(xiàn)數(shù)據(jù)丟失

因此對 k8s 來說，不能使用 Deployment 部署有狀態(tài)的服務。通常情況下，Deployment 被用來部署無狀態(tài)服務。

然后 StatefulSet 就是為了解決有狀態(tài)服務使用容器化部署的一個問題。

4.2 如何理解狀態(tài)服務

有狀態(tài)服務

有實時的數(shù)據(jù)需要存儲

在有狀態(tài)服務集群中，如果把某一個服務抽離出來，一段時間后再加入回集群網(wǎng)絡，此后集群網(wǎng)絡會無法使用

無狀態(tài)服務

沒有實時的數(shù)據(jù)需要存儲

在無狀態(tài)服務集群中，如果把某一個服務抽離出去，一段時間后再加入回集群網(wǎng)絡，對集群服務無任何影響，因為它們不需要做交互，不需要數(shù)據(jù)同步等等。

4.3 部署模型

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

比如下圖，借助 PVC(與存儲有關) 文件系統(tǒng)來存儲的實時數(shù)據(jù)，因此下圖就是一個有狀態(tài)服務的部署。

在 pod 宕機之后重新建立 pod 時，StatefulSet 通過保證 hostname 不發(fā)生變化來保證數(shù)據(jù)不丟失。因此 pod 就可以通過 hostname 來關聯(lián)(找到) 之前存儲的數(shù)據(jù)。

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

審核編輯 ：李倩