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

1.1 pod 是什么

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

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

pod 相當(dāng)于一臺(tái)獨(dú)立主機(jī)，內(nèi)部可以封裝一個(gè)或多個(gè)容器（通常是一組相關(guān)的容器），內(nèi)部容器之間訪(fǎng)問(wèn)采用 localhost。

1.2 pod 用來(lái)干什么

通常情況下，在服務(wù)部署的時(shí)候，使用 pod 來(lái)管理一組相關(guān)的服務(wù)（一個(gè) pod 中要么部署一個(gè)服務(wù)，要么部署一組有關(guān)系的服務(wù)）。如下圖是部署了一組有關(guān)系的服務(wù)的結(jié)構(gòu)圖，其中 C 表示容器（container），下面的 pod 里就有很多個(gè)容器。

如何理解一組相關(guān)的服務(wù)？

如下圖：有一個(gè)請(qǐng)求是訪(fǎng)問(wèn) Nginx，然后部署了 Nginx 的容器就把請(qǐng)求轉(zhuǎn)發(fā)給部署了 web 服務(wù)的容器，web 再訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，然后請(qǐng)求會(huì)依次返回來(lái)數(shù)據(jù)，最后再返回給用戶(hù)。因此在 鏈?zhǔn)秸{(diào)用的調(diào)用鏈路上的服務(wù) 叫做一組相關(guān)的服務(wù)。

1.3 實(shí)現(xiàn) web 服務(wù)集群

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

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

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

pod 底層

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

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

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

2. ReplicaSet 副本控制器

2.1 副本控制器基本理解

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

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

2.2 ReplicaSet 和 ReplicationController 的區(qū)別

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

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

不同點(diǎn)：標(biāo)簽選擇器的功能不同。ReplicaSet 可以使用標(biāo)簽選擇器進(jìn)行 單選 和 復(fù)合選擇；而 ReplicationController 只支持 單選操作。

什么意思呢？

假設(shè)下面有下面兩個(gè)不同機(jī)器上的 Node 結(jié)點(diǎn)，如何知道它們的 pod 其實(shí)都是相同的呢？答案是通過(guò)標(biāo)簽。

給每個(gè) pod 打上標(biāo)簽 （ key=value 格式，如下圖中的 app=web， release=stable，這有兩個(gè)選項(xiàng)，相同的pod副本的標(biāo)簽是一樣的），于是副本控制器可以通過(guò)標(biāo)簽選擇器 seletor 去選擇一組相關(guān)的服務(wù)。一旦 selector 和 pod 的標(biāo)簽匹配上了，就表明這個(gè) pod 是當(dāng)前這個(gè)副本控制器控制的，表明了副本控制器和 pod 的所屬關(guān)系。如下圖中 seletor 指定了 app = web 和 release=stable 是復(fù)合選擇，要用 ReplicaSet 才能實(shí)現(xiàn)若用 ReplicationController 的話(huà)只能選擇一個(gè)，如只選擇匹配app=web標(biāo)簽。這樣下面的 3 個(gè) pod 就歸這個(gè)副本控制器管。

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

3. Deployment 部署對(duì)象

3.1 滾動(dòng)更新

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

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

3.2 部署模型

單獨(dú)的 ReplicaSet 是不支持滾動(dòng)更新的，Deployment 對(duì)象支持滾動(dòng)更新，通常和 ReplicaSet 一起使用。

需要滾動(dòng)更新時(shí)的步驟：

Deployment 建立新的 Replicaset

Replicaset 重新建立新的 pod

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

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

4.1 引入定義

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

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

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

因此對(duì) k8s 來(lái)說(shuō)，不能使用 Deployment 部署有狀態(tài)的服務(wù)。通常情況下，Deployment 被用來(lái)部署無(wú)狀態(tài)服務(wù)。然后 StatefulSet 就是為了解決有狀態(tài)服務(wù)使用容器化部署的一個(gè)問(wèn)題。

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

有狀態(tài)服務(wù)

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

在有狀態(tài)服務(wù)集群中，如果把某一個(gè)服務(wù)抽離出來(lái)，一段時(shí)間后再加入回集群網(wǎng)絡(luò)，此后集群網(wǎng)絡(luò)會(huì)無(wú)法使用

無(wú)狀態(tài)服務(wù)

沒(méi)有實(shí)時(shí)的數(shù)據(jù)需要存儲(chǔ)

在無(wú)狀態(tài)服務(wù)集群中，如果把某一個(gè)服務(wù)抽離出去，一段時(shí)間后再加入回集群網(wǎng)絡(luò)，對(duì)集群服務(wù)無(wú)任何影響，因?yàn)樗鼈儾恍枰鼋换ィ恍枰獢?shù)據(jù)同步等等。

4.3 部署模型

StatefulSet 的部署模型和 Deployment 的很相似。比如下圖，借助 PVC（與存儲(chǔ)有關(guān)） 文件系統(tǒng)來(lái)存儲(chǔ)的實(shí)時(shí)數(shù)據(jù)，因此下圖就是一個(gè)有狀態(tài)服務(wù)的部署。在 pod 宕機(jī)之后重新建立 pod 時(shí)，StatefulSet 通過(guò)保證 hostname 不發(fā)生變化來(lái)保證數(shù)據(jù)不丟失。因此 pod 就可以通過(guò) hostname 來(lái)關(guān)聯(lián)（找到） 之前存儲(chǔ)的數(shù)據(jù)。

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

責(zé)任編輯：haq