Kubernetes 核心組件原理

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。

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