【云原生|Kubernetes】13-Deployment資源控制器詳解

前言

kubernetes中有很多資源控制器，這些資源控制器我們只說(shuō)一些重要且常用的。在介紹Deploymen之前，我們會(huì)逐個(gè)介紹這些控制器。

Pod控制器介紹

? Pod控制器是用于實(shí)現(xiàn)管理pod的中間層，確保pod資源符合預(yù)期的狀態(tài)，pod的資源出現(xiàn)故障時(shí)，會(huì)嘗試 進(jìn)行重啟，當(dāng)根據(jù)重啟策略無(wú)效，則會(huì)重新新建pod的資源。

控制器種類

• ReplicaSet: 代用戶創(chuàng)建指定數(shù)量的pod副本數(shù)量，確保pod副本數(shù)量符合預(yù)期狀態(tài)，并且支持滾動(dòng)式自動(dòng)擴(kuò)容和縮容功能。

ReplicaSet主要三個(gè)組件組成：

（1）用戶期望的pod副本數(shù)量

（2）標(biāo)簽選擇器，判斷哪個(gè)pod歸自己管理

（3）當(dāng)現(xiàn)存的pod數(shù)量不足，會(huì)根據(jù)pod資源模板進(jìn)行新建

幫助用戶管理無(wú)狀態(tài)的pod資源，精確反應(yīng)用戶定義的目標(biāo)數(shù)量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

• Deployment: 工作在ReplicaSet之上，用于管理無(wú)狀態(tài)應(yīng)用，目前來(lái)說(shuō)最好的控制器。支持滾動(dòng)更新和回滾功能，還提供聲明式配置。
• DaemonSet： 用于確保集群中的每一個(gè)節(jié)點(diǎn)只運(yùn)行特定的pod副本，通常用于實(shí)現(xiàn)系統(tǒng)級(jí)后臺(tái)任務(wù)。比如ELK服務(wù)。特性：服務(wù)是無(wú)狀態(tài)的；服務(wù)必須是守護(hù)進(jìn)程
• Job： 只要完成就立即退出，不需要重啟或重建。
• Cronjob： 周期性任務(wù)控制，不需要持續(xù)后臺(tái)運(yùn)行。
• StatefulSet： 管理有狀態(tài)應(yīng)用。

ReplicaSet簡(jiǎn)介

ReplicaSet 的目的是維護(hù)一組在任何時(shí)候都處于運(yùn)行狀態(tài)的 Pod 副本的穩(wěn)定集合。 因此，它通常用來(lái)保證給定數(shù)量的、完全相同的 Pod 的可用性

ReplicaSet工作原理

• ReplicaSet 是通過(guò)一組字段來(lái)定義的，包括一個(gè)用來(lái)識(shí)別可獲得的 Pod 的集合的選擇算符、一個(gè)用來(lái)標(biāo)明應(yīng)該維護(hù)的副本個(gè)數(shù)的數(shù)值、一個(gè)用來(lái)指定應(yīng)該創(chuàng)建新 Pod 以滿足副本個(gè)數(shù)條件時(shí)要使用的 Pod 模板等等。 每個(gè) ReplicaSet 都通過(guò)根據(jù)需要?jiǎng)?chuàng)建和刪除 Pod 以使得副本個(gè)數(shù)達(dá)到期望值， 進(jìn)而實(shí)現(xiàn)其存在價(jià)值。當(dāng) ReplicaSet 需要?jiǎng)?chuàng)建新的 Pod 時(shí)，會(huì)使用所提供的 Pod 模板。

• ReplicaSet 通過(guò) Pod 上的 metadata.ownerReferences 字段連接到附屬 Pod，該字段給出當(dāng)前對(duì)象的屬主資源。 ReplicaSet 所獲得的 Pod 都在其 ownerReferences 字段中包含了屬主 ReplicaSet 的標(biāo)識(shí)信息。正是通過(guò)這一連接，ReplicaSet 知道它所維護(hù)的 Pod 集合的狀態(tài)， 并據(jù)此計(jì)劃其操作行為。

  ReplicaSet 使用其選擇算符來(lái)辨識(shí)要獲得的 Pod 集合。如果某個(gè) Pod 沒(méi)有 OwnerReference 或者其 OwnerReference 不是一個(gè)控制器， 且其匹配到某 ReplicaSet 的選擇算符，則該 Pod 立即被此 ReplicaSet 獲得。

何時(shí)使用 ReplicaSet

ReplicaSet 確保任何時(shí)間都有指定數(shù)量的 Pod 副本在運(yùn)行。 然而，Deployment 是一個(gè)更高級(jí)的概念，它管理 ReplicaSet，并向 Pod 提供聲明式的更新以及許多其他有用的功能。 因此，我們建議使用 Deployment 而不是直接使用 ReplicaSet， 除非你需要自定義更新業(yè)務(wù)流程或根本不需要更新；這實(shí)際上意味著，你可能永遠(yuǎn)不需要操作 ReplicaSet 對(duì)象：而是使用 Deployment，并在 spec 部分定義你的應(yīng)用。這也是為什么我在介紹Deployment之前先介紹ReplixaSet的原因。

Deployment簡(jiǎn)介

一個(gè) Deployment 為 Pod 和 ReplicaSet 提供聲明式的更新能力。

你負(fù)責(zé)描述 Deployment 中的 目標(biāo)狀態(tài)，而 Deployment 控制器（Controller） 以受控速率更改實(shí)際狀態(tài)， 使其變?yōu)槠谕麪顟B(tài)。你可以定義 Deployment 以創(chuàng)建新的 ReplicaSet，或刪除現(xiàn)有 Deployment， 并通過(guò)新的 Deployment 收養(yǎng)其資源。

kubernetes下有多個(gè)Deployment，Deployment下管理RepliceSet，通過(guò)RepliceSet管理多個(gè)Pod，通過(guò)Pod管理容器。

它們之間的關(guān)系圖如下：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-IERRxP5x-1689039436678)(D:\學(xué)習(xí)\學(xué)習(xí)筆記\圖片\117.png)]

Deployment典型案例

• 創(chuàng)建 Deployment 以將 ReplicaSet 上線。ReplicaSet 在后臺(tái)創(chuàng)建 Pod。 檢查 ReplicaSet 的上線狀態(tài)，查看其是否成功。

• 通過(guò)更新 Deployment 的 PodTemplateSpec，聲明 Pod 的新?tīng)顟B(tài) 。 新的 ReplicaSet 會(huì)被創(chuàng)建，Deployment 以受控速率將 Pod 從舊 ReplicaSet 遷移到新 ReplicaSet。 每個(gè)新的 ReplicaSet 都會(huì)更新 Deployment 的修訂版本。

• 如果 Deployment 的當(dāng)前狀態(tài)不穩(wěn)定，回滾到較早的 Deployment 版本。 每次回滾都會(huì)更新 Deployment 的修訂版本。

• 擴(kuò)大 Deployment 規(guī)模以承擔(dān)更多負(fù)載。

• 暫停 Deployment 的上線 以應(yīng)用對(duì) PodTemplateSpec 所作的多項(xiàng)修改， 然后恢復(fù)其執(zhí)行以啟動(dòng)新的上線版本。

• 使用 Deployment 狀態(tài)來(lái)判定上線過(guò)程是否出現(xiàn)停滯。

• 清理較舊的不再需要的 ReplicaSet 。

創(chuàng)建Deployment

下面是一個(gè) Deployment 示例。其中創(chuàng)建了一個(gè) ReplicaSet，負(fù)責(zé)啟動(dòng)三個(gè) nginx Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

在該例中：

• 創(chuàng)建名為 nginx-deployment（由 .metadata.name 字段標(biāo)明）的 Deployment。 該名稱將成為后續(xù)創(chuàng)建 ReplicaSet 和 Pod 的命名基礎(chǔ)。
• 該 Deployment 創(chuàng)建一個(gè) ReplicaSet，并由ReplicaSet創(chuàng)建三個(gè)（由 .spec.replicas 字段標(biāo)明）Pod 副本。
• .spec.selector 字段定義所創(chuàng)建的 ReplicaSet 如何查找要管理的 Pod。 在這里，你選擇在 Pod 模板中定義的標(biāo)簽（app: nginx）。 不過(guò)，更復(fù)雜的選擇規(guī)則是也可能的，只要 Pod 模板本身滿足所給規(guī)則即可。

說(shuō)明：

.spec.selector.matchLabels 字段是 {key,value} 鍵值對(duì)映射。 在 matchLabels 映射中的每個(gè) {key,value} 映射等效于 matchExpressions 中的一個(gè)元素， 即其 key 字段是 “key”，operator 為 “In”，values 數(shù)組僅包含 “value”。 在 matchLabels 和 matchExpressions 中給出的所有條件都必須滿足才能匹配。

• template字段包含以下子字段：
  • Pod 被使用 .metadata.labels 字段打上 app: nginx 標(biāo)簽。
  • Pod 模板規(guī)約（即 .template.spec 字段）指示 Pod 運(yùn)行一個(gè) nginx 容器， 該容器運(yùn)行版本為 1.14.2 的 nginx Docker Hub 鏡像。
  • 創(chuàng)建一個(gè)容器并使用 .spec.template.spec.containers[0].name 字段將其命名為 nginx。

1. 通過(guò)運(yùn)行以下命令創(chuàng)建 Deployment ：

[root@master deployment]# kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created
[root@master deployment]# 

2. 運(yùn)行 kubectl get deployments 檢查 Deployment 是否已創(chuàng)建。 如果仍在創(chuàng)建 Deployment，則輸出類似于：

[root@master deployment]# kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           69s
[root@master deployment]#

在檢查集群中的 Deployment 時(shí)，所顯示的字段有：

• NAME 列出了名字空間中 Deployment 的名稱。
• READY 顯示應(yīng)用程序的可用的“副本”數(shù)。顯示的模式是“就緒個(gè)數(shù)/期望個(gè)數(shù)”。
• UP-TO-DATE 顯示為了達(dá)到期望狀態(tài)已經(jīng)更新的副本數(shù)。
• AVAILABLE 顯示應(yīng)用可供用戶使用的副本數(shù)。
• AGE 顯示應(yīng)用程序運(yùn)行的時(shí)間。

請(qǐng)注意期望副本數(shù)是根據(jù) .spec.replicas 字段設(shè)置 3。

3. 要查看 Deployment 上線狀態(tài)，運(yùn)行 kubectl rollout status deployment/nginx-deployment。

[root@master deployment]# kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
[root@master deployment]#

4. 幾秒鐘后再次運(yùn)行 kubectl get deployments。輸出類似于：

[root@master deployment]# kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           69s
[root@master deployment]#

注意 Deployment 已創(chuàng)建全部三個(gè)副本，并且所有副本都是最新的（它們包含最新的 Pod 模板） 并且可用。

5. 要查看 Deployment 創(chuàng)建的 ReplicaSet（rs），運(yùn)行 kubectl get rs。 輸出類似于：

[root@master deployment]# kubectl get replicaset
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-66b6c48dd5   3         3         3       4m4s
[root@master deployment]#

ReplicaSet 輸出中包含以下字段：

• NAME 列出名字空間中 ReplicaSet 的名稱；
• DESIRED 顯示應(yīng)用的期望副本個(gè)數(shù)，即在創(chuàng)建 Deployment 時(shí)所定義的值。 此為期望狀態(tài)；
• CURRENT 顯示當(dāng)前運(yùn)行狀態(tài)中的副本個(gè)數(shù)；
• READY 顯示應(yīng)用中有多少副本可以為用戶提供服務(wù)；
• AGE 顯示應(yīng)用已經(jīng)運(yùn)行的時(shí)間長(zhǎng)度。

注意 ReplicaSet 的名稱格式始終為 [Deployment 名稱]-[哈希]。 該名稱將成為所創(chuàng)建的 Pod 的命名基礎(chǔ)。 其中的哈希字符串與 ReplicaSet 上的 pod-template-hash 標(biāo)簽一致。

6. 要查看每個(gè) Pod 自動(dòng)生成的標(biāo)簽，運(yùn)行 kubectl get pods --show-labels。 輸出類似于：

[root@master deployment]# kubectl get pods --show-labels
NAME                                READY   STATUS             RESTARTS   AGE     LABELS
nginx-deployment-66b6c48dd5-fzhsr   1/1     Running            0          5m34s   app=nginx,pod-template-hash=66b6c48dd5
nginx-deployment-66b6c48dd5-g5jg4   1/1     Running            0          5m34s   app=nginx,pod-template-hash=66b6c48dd5
nginx-deployment-66b6c48dd5-l2jr7   1/1     Running            0          5m34s   app=nginx,pod-template-hash=66b6c48dd5
[root@master deployment]#

所創(chuàng)建的 ReplicaSet 確?？偸谴嬖谌齻€(gè) nginx Pod。

說(shuō)明：

你必須在 Deployment 中指定適當(dāng)?shù)倪x擇算符和 Pod 模板標(biāo)簽（在本例中為 app: nginx）。 標(biāo)簽或者選擇算符不要與其他控制器（包括其他 Deployment 和 StatefulSet）重疊。 Kubernetes 不會(huì)阻止你這樣做，但是如果多個(gè)控制器具有重疊的選擇算符， 它們可能會(huì)發(fā)生沖突執(zhí)行難以預(yù)料的操作。

Pod-template-hash 標(biāo)簽

Deployment 控制器將 pod-template-hash 標(biāo)簽添加到 Deployment 所創(chuàng)建或收留的每個(gè) ReplicaSet 。

此標(biāo)簽可確保 Deployment 的子 ReplicaSets 不重疊。 標(biāo)簽是通過(guò)對(duì) ReplicaSet 的 PodTemplate 進(jìn)行哈希處理。 所生成的哈希值被添加到 ReplicaSet 選擇算符、Pod 模板標(biāo)簽，并存在于在 ReplicaSet 可能擁有的任何現(xiàn)有 Pod 中

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-m87r0Jym-1689039436680)(D:\學(xué)習(xí)\學(xué)習(xí)筆記\圖片\118.png)]

注意：

不要更改此標(biāo)簽。

更新Deployment

說(shuō)明：

僅當(dāng) Deployment Pod 模板（即 .spec.template）發(fā)生改變時(shí)，例如模板的標(biāo)簽或容器鏡像被更新， 才會(huì)觸發(fā) Deployment 上線。其他更新（如對(duì) Deployment 執(zhí)行擴(kuò)縮容的操作）不會(huì)觸發(fā)上線動(dòng)作。

按照以下步驟更新 Deployment：

1. 先來(lái)更新 nginx Pod 以使用 nginx:1.16.1 鏡像，而不是 nginx:1.14.2 鏡像。

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

## 輸出類似于：
deployment.apps/nginx-deployment image updated

或者，可以對(duì) Deployment 執(zhí)行 edit 操作并將 .spec.template.spec.containers[0].image 從 nginx:1.14.2 更改至 nginx:1.16.1。

kubectl edit deployment/nginx-deployment

##輸出類似于：
deployment.apps/nginx-deployment edited

使用edit比較多

2. 要查看上線狀態(tài)，運(yùn)行：

kubectl rollout status deployment/nginx-deployment

## 輸出類似于：
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
或者
deployment "nginx-deployment" successfully rolled out

3. 獲取關(guān)于已更新的 Deployment 的更多信息：

• 在上線成功后，可以通過(guò)運(yùn)行 kubectl get deployments 來(lái)查看 Deployment： 輸出類似于：

[root@master deployment]# kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           117m
[root@master deployment]#

• 運(yùn)行 kubectl get rs 以查看 Deployment 通過(guò)創(chuàng)建新的 ReplicaSet 并將其擴(kuò)容到 3 個(gè)副本并將舊 ReplicaSet 縮容到 0 個(gè)副本完成了 Pod 的更新操作：

[root@master deployment]# kubectl get replicaset
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-559d658b74   3         3         3       5m48s
nginx-deployment-66b6c48dd5   0         0         0       115m
[root@master deployment]#

下次要更新這些 Pod 時(shí)，只需再次更新 Deployment Pod 模板即可。

Deployment 可確保在更新時(shí)僅關(guān)閉一定數(shù)量的 Pod。默認(rèn)情況下，它確保至少所需 Pod 的 75% 處于運(yùn)行狀態(tài)（最大不可用比例為 25%）。

Deployment 還確保僅所創(chuàng)建 Pod 數(shù)量只可能比期望 Pod 數(shù)高一點(diǎn)點(diǎn)。 默認(rèn)情況下，它可確保啟動(dòng)的 Pod 個(gè)數(shù)比期望個(gè)數(shù)最多多出 125%（最大峰值 25%）。

通過(guò)一下參數(shù)設(shè)置：

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
    
在 Kubernetes 的 Deployment 中，strategy 字段用于指定更新 Pod 的策略，其中 type 字段用于指定更新策略的類型。在 Deployment 的 strategy 字段中，type 字段可以設(shè)置為以下幾種類型：
Recreate：當(dāng)需要更新 Deployment 中的 Pod 時(shí)，先刪除舊的 Pod，然后再創(chuàng)建新的 Pod。這種更新策略會(huì)導(dǎo)致一段時(shí)間內(nèi) Deployment 中沒(méi)有可用的 Pod，因此應(yīng)該謹(jǐn)慎使用。

RollingUpdate：當(dāng)需要更新 Deployment 中的 Pod 時(shí)，按照一定的順序逐步替換舊的 Pod。這種更新策略可以保證 Deployment 中始終有可用的 Pod，因此是默認(rèn)的更新策略。
在 RollingUpdate 更新策略中，可以使用以下兩個(gè)字段來(lái)配置更新過(guò)程：
maxUnavailable：指定在更新過(guò)程中最多可以停止的 Pod 的數(shù)量。默認(rèn)值為 1，表示在更新過(guò)程中最多只能停止一個(gè) Pod。
maxSurge：指定在更新過(guò)程中最多可以啟動(dòng)的新 Pod 的數(shù)量。默認(rèn)值為 25%，表示在更新過(guò)程中最多可以啟動(dòng)舊 Pod 數(shù)量的 25% 的新 Pod。

更新總結(jié)：

第一次創(chuàng)建 Deployment 時(shí)，它創(chuàng)建了一個(gè) ReplicaSet（nginx-deployment-2035384211） 并將其直接擴(kuò)容至 3 個(gè)副本。更新 Deployment 時(shí)，它創(chuàng)建了一個(gè)新的 ReplicaSet （nginx-deployment-1564180365），并將其擴(kuò)容為 1，等待其就緒；然后將舊 ReplicaSet 縮容到 2， 將新的 ReplicaSet 擴(kuò)容到 2 以便至少有 3 個(gè) Pod 可用且最多創(chuàng)建 4 個(gè) Pod。 然后，它使用相同的滾動(dòng)更新策略繼續(xù)對(duì)新的 ReplicaSet 擴(kuò)容并對(duì)舊的 ReplicaSet 縮容。 最后，你將有 3 個(gè)可用的副本在新的 ReplicaSet 中，舊 ReplicaSet 將縮容到 0。

說(shuō)明：

Kubernetes 在計(jì)算 availableReplicas 數(shù)值時(shí)不考慮終止過(guò)程中的 Pod， availableReplicas 的值一定介于 replicas - maxUnavailable 和 replicas + maxSurge 之間。 因此，你可能在上線期間看到 Pod 個(gè)數(shù)比預(yù)期的多，Deployment 所消耗的總的資源也大于 replicas + maxSurge 個(gè) Pod 所用的資源，直到被終止的 Pod 所設(shè)置的 terminationGracePeriodSeconds 到期為止

翻轉(zhuǎn)（多 Deployment 動(dòng)態(tài)更新）

? Deployment 控制器每次注意到新的 Deployment 時(shí)，都會(huì)創(chuàng)建一個(gè) ReplicaSet 以啟動(dòng)所需的 Pod。 如果更新了 Deployment，則控制標(biāo)簽匹配 .spec.selector 但模板不匹配 .spec.template 的 Pod 的現(xiàn)有 ReplicaSet 被縮容。 最終，新的 ReplicaSet 縮放為 .spec.replicas 個(gè)副本， 所有舊 ReplicaSets 縮放為 0 個(gè)副本。

? 當(dāng) Deployment 正在上線時(shí)被更新，Deployment 會(huì)針對(duì)更新創(chuàng)建一個(gè)新的 ReplicaSet 并開(kāi)始對(duì)其擴(kuò)容，之前正在被擴(kuò)容的 ReplicaSet 會(huì)被翻轉(zhuǎn)，添加到舊 ReplicaSets 列表 并開(kāi)始縮容。

? 例如，假定你在創(chuàng)建一個(gè) Deployment 以生成 nginx:1.14.2 的 5 個(gè)副本，但接下來(lái) 更新 Deployment 以創(chuàng)建 5 個(gè) nginx:1.16.1 的副本，而此時(shí)只有 3 個(gè) nginx:1.14.2 副本已創(chuàng)建。在這種情況下，Deployment 會(huì)立即開(kāi)始?xì)⑺?3 個(gè) nginx:1.14.2 Pod， 并開(kāi)始創(chuàng)建 nginx:1.16.1 Pod。它不會(huì)等待 nginx:1.14.2 的 5 個(gè)副本都創(chuàng)建完成后才開(kāi)始執(zhí)行變更動(dòng)作。

更改標(biāo)簽選擇算符

? 通常不鼓勵(lì)更新標(biāo)簽選擇算符。建議你提前規(guī)劃選擇算符。 在任何情況下，如果需要更新標(biāo)簽選擇算符，請(qǐng)格外小心， 并確保自己了解這背后可能發(fā)生的所有事情。

說(shuō)明：

在 API 版本 apps/v1 中，Deployment 標(biāo)簽選擇算符在創(chuàng)建后是不可變的。

• 添加選擇算符時(shí)要求使用新標(biāo)簽更新 Deployment 規(guī)約中的 Pod 模板標(biāo)簽，否則將返回驗(yàn)證錯(cuò)誤。 此更改是非重疊的，也就是說(shuō)新的選擇算符不會(huì)選擇使用舊選擇算符所創(chuàng)建的 ReplicaSet 和 Pod， 這會(huì)導(dǎo)致創(chuàng)建新的 ReplicaSet 時(shí)所有舊 ReplicaSet 都會(huì)被孤立。
• 選擇算符的更新如果更改了某個(gè)算符的鍵名，這會(huì)導(dǎo)致與添加算符時(shí)相同的行為。
• 刪除選擇算符的操作會(huì)刪除從 Deployment 選擇算符中刪除現(xiàn)有算符。 此操作不需要更改 Pod 模板標(biāo)簽?，F(xiàn)有 ReplicaSet 不會(huì)被孤立，也不會(huì)因此創(chuàng)建新的 ReplicaSet， 但請(qǐng)注意已刪除的標(biāo)簽仍然存在于現(xiàn)有的 Pod 和 ReplicaSet 中。

回滾Deployment

有時(shí)，你可能想要回滾 Deployment；例如，當(dāng) Deployment 不穩(wěn)定時(shí)（例如進(jìn)入反復(fù)崩潰狀態(tài)）。 默認(rèn)情況下，Deployment 的所有上線記錄都保留在系統(tǒng)中，以便可以隨時(shí)回滾 （你可以通過(guò)修改修訂歷史記錄限制來(lái)更改這一約束）。

說(shuō)明：

Deployment 被觸發(fā)上線時(shí)，系統(tǒng)就會(huì)創(chuàng)建 Deployment 的新的修訂版本。 這意味著僅當(dāng) Deployment 的 Pod 模板（.spec.template）發(fā)生更改時(shí)，才會(huì)創(chuàng)建新修訂版本 – 例如，模板的標(biāo)簽或容器鏡像發(fā)生變化。 其他更新，如 Deployment 的擴(kuò)縮容操作不會(huì)創(chuàng)建 Deployment 修訂版本。 這是為了方便同時(shí)執(zhí)行手動(dòng)縮放或自動(dòng)縮放。 換言之，當(dāng)你回滾到較早的修訂版本時(shí)，只有 Deployment 的 Pod 模板部分會(huì)被回滾。

• 假設(shè)你在更新 Deployment 時(shí)犯了一個(gè)拼寫(xiě)錯(cuò)誤，將鏡像名稱命名設(shè)置為 nginx:1.161 而不是 nginx:1.16.1：

kubectl set image deployment/nginx-deployment nginx=nginx:1.161

輸出：
deployment.apps/nginx-deployment image updated

• 此上線進(jìn)程會(huì)出現(xiàn)停滯。你可以通過(guò)檢查上線狀態(tài)來(lái)驗(yàn)證：

kubectl rollout status deployment/nginx-deployment

輸出：
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...

• 按 Ctrl-C 停止上述上線狀態(tài)觀測(cè)。有關(guān)上線停滯的詳細(xì)信息，

• 你可以看到舊的副本有兩個(gè)（nginx-deployment-1564180365 和 nginx-deployment-2035384211）， 新的副本有 1 個(gè)（nginx-deployment-3066724191）：

kubectl get replicasset

輸出：
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   1         1         0       6s

• 查看所創(chuàng)建的 Pod，你會(huì)注意到新 ReplicaSet 所創(chuàng)建的 1 個(gè) Pod 卡頓在鏡像拉取循環(huán)中。

kubectl get pods

輸出：
NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s

說(shuō)明：

Deployment 控制器自動(dòng)停止有問(wèn)題的上線過(guò)程，并停止對(duì)新的 ReplicaSet 擴(kuò)容。 這行為取決于所指定的 rollingUpdate 參數(shù)（具體為 maxUnavailable）。 默認(rèn)情況下，Kubernetes 將此值設(shè)置為 25%。

• 獲取 Deployment 描述信息：

[root@master deployment]# kubectl describe deployment nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 05 Jun 2023 11:10:35 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 3
Selector:               app=nginx
Replicas:               3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.161
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:  nginx-deployment-559d658b74 (3/3 replicas created)
NewReplicaSet:   nginx-deployment-66bc5d6c8 (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  35m   deployment-controller  Scaled up replica set nginx-deployment-559d658b74 to 1
  Normal  ScalingReplicaSet  34m   deployment-controller  Scaled down replica set nginx-deployment-66b6c48dd5 to 2
  Normal  ScalingReplicaSet  34m   deployment-controller  Scaled up replica set nginx-deployment-559d658b74 to 2
  Normal  ScalingReplicaSet  34m   deployment-controller  Scaled down replica set nginx-deployment-66b6c48dd5 to 1
  Normal  ScalingReplicaSet  34m   deployment-controller  Scaled up replica set nginx-deployment-559d658b74 to 3
  Normal  ScalingReplicaSet  34m   deployment-controller  Scaled down replica set nginx-deployment-66b6c48dd5 to 0
  Normal  ScalingReplicaSet  65s   deployment-controller  Scaled up replica set nginx-deployment-66bc5d6c8 to 1
[root@master deployment]#

要解決此問(wèn)題，需要回滾到以前穩(wěn)定的 Deployment 版本。

檢查 Deployment 上線歷史

按照如下步驟檢查回滾歷史：

1. 首先，檢查 Deployment 修訂歷史：

kubectl rollout history deployment/nginx-deployment

輸出：
deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.161

CHANGE-CAUSE 的內(nèi)容是從 Deployment 的 kubernetes.io/change-cause 注解復(fù)制過(guò)來(lái)的。 復(fù)制動(dòng)作發(fā)生在修訂版本創(chuàng)建時(shí)。你可以通過(guò)以下方式設(shè)置 CHANGE-CAUSE 消息：

• 使用 kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1" 為 Deployment 添加注解。
• 手動(dòng)編輯資源的清單。

2. 要查看修訂歷史的詳細(xì)信息，運(yùn)行：

kubectl rollout history deployment/nginx-deployment --revision=2

輸出：
deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
  Containers:
   nginx:
    Image:      nginx:1.16.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

回滾到之前的修訂版本

按照下面給出的步驟將 Deployment 從當(dāng)前版本回滾到以前的版本（即版本 2）

1. 假定現(xiàn)在你已決定撤消當(dāng)前上線并回滾到以前的修訂版本：

kubectl rollout undo deployment/nginx-deployment

輸出類似于
deployment.apps/nginx-deployment rolled back

或者，你也可以通過(guò)使用 --to-revision 來(lái)回滾到特定修訂版本：

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Deployment 正在回滾到以前的穩(wěn)定版本。正如你所看到的，Deployment 控制器生成了回滾到修訂版本 2 的 DeploymentRollback 事件。

縮放 Deployment

1. 你可以使用如下指令縮放 Deployment

kubectl scale deployment/nginx-deployment --replicas=10 	

2. 假設(shè)集群?jiǎn)⒂昧薖od 的水平自動(dòng)縮放， 你可以為 Deployment 設(shè)置自動(dòng)縮放器，并基于現(xiàn)有 Pod 的 CPU 利用率選擇要運(yùn)行的 Pod 個(gè)數(shù)下限和上限。

kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80

輸出類似于;
deployment.apps/nginx-deployment scaled

在yaml中定義自動(dòng)縮放

在 Kubernetes 中，可以使用 Horizontal Pod Autoscaler (HPA) 來(lái)自動(dòng)擴(kuò)展 Deployment 中的 Pod 數(shù)量，以滿足應(yīng)用程序的需求。HPA 可以根據(jù) CPU 使用率、內(nèi)存使用率等指標(biāo)來(lái)動(dòng)態(tài)調(diào)整 Pod 數(shù)量，以保持應(yīng)用程序的高可用性和穩(wěn)定性。下面是一個(gè)示例 YAML 文件，可以用于定義一個(gè)名為 nginx-deployment 的 Deployment 和一個(gè)基于 CPU 使用率的 HPA：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.10
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "500m"
          requests:
            cpu: "200m"
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

在這個(gè) YAML 文件中，首先定義了一個(gè)名為 nginx-deployment 的 Deployment，其中包括 3 個(gè)副本、使用 nginx:1.19.10 鏡像、容器名稱為 nginx、容器端口為 80，并且為容器指定了 CPU 資源限制和請(qǐng)求。然后，定義了一個(gè)名為 nginx-hpa 的 HPA，它的 scaleTargetRef 字段指向 nginx-deployment 這個(gè) Deployment。HPA 中的 minReplicas 和 maxReplicas 字段分別指定了 Pod 數(shù)量的下限和上限，metrics 字段中定義了 HPA 所使用的指標(biāo)類型和目標(biāo)值，這里使用了 CPU 使用率，并且目標(biāo)值為 50%。

如果需要根據(jù)其他指標(biāo)來(lái)自動(dòng)擴(kuò)展 Deployment 中的 Pod 數(shù)量，可以修改 HPA 的 YAML 文件中的 metrics 字段來(lái)指定其他的指標(biāo)類型和目標(biāo)值。

需要注意的是，如果在創(chuàng)建 HPA 之后修改 Deployment 的 YAML 文件，可能需要手動(dòng)更新 HPA 的 scaleTargetRef 字段中的 Deployment 名稱，以確保 HPA 可以正確地調(diào)整 Pod 數(shù)量。可以使用 kubectl edit hpa 命令來(lái)編輯 HPA 的 YAML 文件，然后修改 scaleTargetRef 字段中的 Deployment 名稱，最后保存并退出編輯器即可。

比例縮放

RollingUpdate 的 Deployment 支持同時(shí)運(yùn)行應(yīng)用程序的多個(gè)版本。 當(dāng)自動(dòng)縮放器縮放處于上線進(jìn)程（仍在進(jìn)行中或暫停）中的 RollingUpdate Deployment 時(shí)， Deployment 控制器會(huì)平衡現(xiàn)有的活躍狀態(tài)的 ReplicaSets（含 Pod 的 ReplicaSets）中的額外副本， 以降低風(fēng)險(xiǎn)。這稱為 比例縮放（Proportional Scaling）。

例如，你正在運(yùn)行一個(gè) 10 個(gè)副本的 Deployment，其 maxSurge=3，maxUnavailable=2。

• 確保 Deployment 的這 10 個(gè)副本都在運(yùn)行。

kubectl get deploy

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

• 更新 Deployment 使用新鏡像，碰巧該鏡像無(wú)法從集群內(nèi)部解析。

kubectl set image deployment/nginx-deployment nginx=nginx:sometag
deployment.apps/nginx-deployment image updated

• 鏡像更新使用 ReplicaSet nginx-deployment-1989198191 啟動(dòng)新的上線過(guò)程， 但由于上面提到的 maxUnavailable 要求，該進(jìn)程被阻塞了。檢查上線狀態(tài)：

kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

• 然后，出現(xiàn)了新的 Deployment 擴(kuò)縮請(qǐng)求。自動(dòng)縮放器將 Deployment 副本增加到 15。 Deployment 控制器需要決定在何處添加 5 個(gè)新副本。如果未使用比例縮放，所有 5 個(gè)副本 都將添加到新的 ReplicaSet 中。使用比例縮放時(shí)，可以將額外的副本分布到所有 ReplicaSet。 較大比例的副本會(huì)被添加到擁有最多副本的 ReplicaSet，而較低比例的副本會(huì)進(jìn)入到 副本較少的 ReplicaSet。所有剩下的副本都會(huì)添加到副本最多的 ReplicaSet。 具有零副本的 ReplicaSets 不會(huì)被擴(kuò)容。

在上面的示例中，3 個(gè)副本被添加到舊 ReplicaSet 中，2 個(gè)副本被添加到新 ReplicaSet。 假定新的副本都很健康，上線過(guò)程最終應(yīng)將所有副本遷移到新的 ReplicaSet 中。 要確認(rèn)這一點(diǎn)，請(qǐng)運(yùn)行：

kubectl get deploy
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m

上線狀態(tài)確認(rèn)了副本是如何被添加到每個(gè) ReplicaSet 的。

kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

暫停、恢復(fù) Deployment 的上線過(guò)程

在你更新一個(gè) Deployment 的時(shí)候，或者計(jì)劃更新它的時(shí)候， 你可以在觸發(fā)一個(gè)或多個(gè)更新之前暫停 Deployment 的上線過(guò)程。 當(dāng)你準(zhǔn)備應(yīng)用這些變更時(shí)，你可以重新恢復(fù) Deployment 上線過(guò)程。 這樣做使得你能夠在暫停和恢復(fù)執(zhí)行之間應(yīng)用多個(gè)修補(bǔ)程序，而不會(huì)觸發(fā)不必要的上線操作。

• 使用如下指令暫停上線

kubectl rollout pause deployment/nginx-deployment

• 接下來(lái)更新 Deployment 鏡像：

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

deployment.apps/nginx-deployment image updated

注意：不會(huì)有新的上線被觸發(fā)

• 暫停 Deployment 上線之前的初始狀態(tài)將繼續(xù)發(fā)揮作用，但新的更新在 Deployment 上線被暫停期間不會(huì)產(chǎn)生任何效果。
• 你不可以回滾處于暫停狀態(tài)的 Deployment，除非先恢復(fù)其執(zhí)行狀態(tài)。

• 恢復(fù)Deployment

可以使用 kubectl rollout resume 命令來(lái)恢復(fù) Deployment

kubectl rollout resume deployment/nginx-deployment

如果在 Deployment 處于暫停狀態(tài)下更新了 Pod 的 YAML 文件，那么更新后的 Pod 將不會(huì)被創(chuàng)建，直到使用 kubectl rollout resume 命令恢復(fù) Deployment。

Deployment狀態(tài)

? Deployment 的生命周期中會(huì)有許多狀態(tài)。上線新的 ReplicaSet 期間可能處于 Progressing（進(jìn)行中），可能是 Complete（已完成），也可能是 Failed（失?。┮灾劣跓o(wú)法繼續(xù)進(jìn)行。

進(jìn)行中的 Deployment

執(zhí)行下面的任務(wù)期間，Kubernetes 標(biāo)記 Deployment 為進(jìn)行中（Progressing）_：

• Deployment 創(chuàng)建新的 ReplicaSet
• Deployment 正在為其最新的 ReplicaSet 擴(kuò)容
• Deployment 正在為其舊有的 ReplicaSet(s) 縮容
• 新的 Pod 已經(jīng)就緒或者可用（就緒至少持續(xù)了 MinReadySeconds 秒）。

當(dāng)上線過(guò)程進(jìn)入“Progressing”狀態(tài)時(shí)，Deployment 控制器會(huì)向 Deployment 的 .status.conditions 中添加包含下面屬性的狀況條目：

• type: Progressing
• status: "True"
• reason: NewReplicaSetCreated | reason: FoundNewReplicaSet | reason: ReplicaSetUpdated

你可以使用 kubectl rollout status 監(jiān)視 Deployment 的進(jìn)度。

完成的 Deployment

當(dāng) Deployment 具有以下特征時(shí)，Kubernetes 將其標(biāo)記為完成（Complete）;

• 與 Deployment 關(guān)聯(lián)的所有副本都已更新到指定的最新版本，這意味著之前請(qǐng)求的所有更新都已完成。
• 與 Deployment 關(guān)聯(lián)的所有副本都可用。
• 未運(yùn)行 Deployment 的舊副本。

當(dāng)上線過(guò)程進(jìn)入“Complete”狀態(tài)時(shí)，Deployment 控制器會(huì)向 Deployment 的 .status.conditions 中添加包含下面屬性的狀況條目：

• type: Progressing
• status: "True"
• reason: NewReplicaSetAvailable

這一 Progressing 狀況的狀態(tài)值會(huì)持續(xù)為 "True"，直至新的上線動(dòng)作被觸發(fā)。 即使副本的可用狀態(tài)發(fā)生變化（進(jìn)而影響 Available 狀況），Progressing 狀況的值也不會(huì)變化。

你可以使用 kubectl rollout status 檢查 Deployment 是否已完成。 如果上線成功完成，kubectl rollout status 返回退出代碼 0。

失敗的 Deployment

你的 Deployment 可能會(huì)在嘗試部署其最新的 ReplicaSet 受挫，一直處于未完成狀態(tài)。 造成此情況一些可能因素如下：

• 配額（Quota）不足
• 就緒探測(cè)（Readiness Probe）失敗
• 鏡像拉取錯(cuò)誤
• 權(quán)限不足
• 限制范圍（Limit Ranges）問(wèn)題
• 應(yīng)用程序運(yùn)行時(shí)的配置錯(cuò)誤

檢測(cè)此狀況的一種方法是在 Deployment 規(guī)約中指定截止時(shí)間參數(shù)： （.spec.progressDeadlineSeconds）。 .spec.progressDeadlineSeconds 給出的是一個(gè)秒數(shù)值，Deployment 控制器在（通過(guò) Deployment 狀態(tài)） 標(biāo)示 Deployment 進(jìn)展停滯之前，需要等待所給的時(shí)長(zhǎng)。

以下 kubectl 命令設(shè)置規(guī)約中的 progressDeadlineSeconds，從而告知控制器 在 10 分鐘后報(bào)告 Deployment 的上線沒(méi)有進(jìn)展：

kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

deployment.apps/nginx-deployment patched

超過(guò)截止時(shí)間后，Deployment 控制器將添加具有以下屬性的 Deployment 狀況到 Deployment 的 .status.conditions 中：

• type: Progressing
• status: "False"
• reason: ProgressDeadlineExceeded

這一狀況也可能會(huì)比較早地失敗，因而其狀態(tài)值被設(shè)置為 "False"， 其原因?yàn)?ReplicaSetCreateError。 一旦 Deployment 上線完成，就不再考慮其期限。

說(shuō)明：

• 除了報(bào)告 Reason=ProgressDeadlineExceeded 狀態(tài)之外，Kubernetes 對(duì)已停止的 Deployment 不執(zhí)行任何操作。更高級(jí)別的編排器可以利用這一設(shè)計(jì)并相應(yīng)地采取行動(dòng)。 例如，將 Deployment 回滾到其以前的版本。
• 如果你暫停了某個(gè) Deployment 上線，Kubernetes 不再根據(jù)指定的截止時(shí)間檢查 Deployment 上線的進(jìn)展。 你可以在上線過(guò)程中間安全地暫停 Deployment 再恢復(fù)其執(zhí)行，這樣做不會(huì)導(dǎo)致超出最后時(shí)限的問(wèn)題。

Deployment 可能會(huì)出現(xiàn)瞬時(shí)性的錯(cuò)誤，可能因?yàn)樵O(shè)置的超時(shí)時(shí)間過(guò)短， 也可能因?yàn)槠渌烧J(rèn)為是臨時(shí)性的問(wèn)題。例如，假定所遇到的問(wèn)題是配額不足。 如果描述 Deployment，你將會(huì)注意到以下部分：

kubectl describe deployment nginx-deployment

輸出類似于：
<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

如果運(yùn)行 kubectl get deployment nginx-deployment -o yaml，Deployment 狀態(tài)輸出 將類似于這樣：

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

最終，一旦超過(guò) Deployment 進(jìn)度限期，Kubernetes 將更新?tīng)顟B(tài)和進(jìn)度狀況的原因：

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

可以通過(guò)縮容 Deployment 或者縮容其他運(yùn)行狀態(tài)的控制器，或者直接在命名空間中增加配額 來(lái)解決配額不足的問(wèn)題。如果配額條件滿足，Deployment 控制器完成了 Deployment 上線操作， Deployment 狀態(tài)會(huì)更新為成功狀況（Status=True 和 Reason=NewReplicaSetAvailable）。

Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable

type: Available 加上 status: True 意味著 Deployment 具有最低可用性。 最低可用性由 Deployment 策略中的參數(shù)指定。 type: Progressing 加上 status: True 表示 Deployment 處于上線過(guò)程中，并且正在運(yùn)行， 或者已成功完成進(jìn)度，最小所需新副本處于可用。 請(qǐng)參閱對(duì)應(yīng)狀況的 Reason 了解相關(guān)細(xì)節(jié)。 在我們的案例中 reason: NewReplicaSetAvailable 表示 Deployment 已完成。

你可以使用 kubectl rollout status 檢查 Deployment 是否未能取得進(jìn)展。 如果 Deployment 已超過(guò)進(jìn)度限期，kubectl rollout status 返回非零退出代碼。

kubectl rollout status deployment/nginx-deployment

輸出類似于:
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline

kubectl rollout 命令的退出狀態(tài)為 1（表明發(fā)生了錯(cuò)誤）：

echo $?
1

Deployment清理策略

你可以在 Deployment 中設(shè)置 .spec.revisionHistoryLimit 字段以指定保留此 Deployment 的多少個(gè)舊有 ReplicaSet。其余的 ReplicaSet 將在后臺(tái)被垃圾回收。 默認(rèn)情況下，此值為 10。

說(shuō)明：

顯式將此字段設(shè)置為 0 將導(dǎo)致 Deployment 的所有歷史記錄被清空，因此 Deployment 將無(wú)法回滾。

Deployment語(yǔ)法格式

apiVersion: apps/v1
kind: Deployment
metadate:                                                ##定義deployment的描述信息
  name:                                                  ##定義deployment的名稱
  namespace:
spec:
  replicas:                            ##定義副本數(shù)量，因?yàn)槲覀冇胐eploymend的目的之一就是創(chuàng)建多pod，而這里就是指定要?jiǎng)?chuàng)建的數(shù)量。
  selector:                            ##標(biāo)簽選擇器，因?yàn)閐eployment在維護(hù)pod的時(shí)候，是不認(rèn)識(shí)哪個(gè)pod是我維護(hù)的對(duì)象
                                      的，而標(biāo)簽選擇器就是找到pod的唯一方式，需要與創(chuàng)建pod模板中定義的標(biāo)簽保持一致
    matchLabels:
  strategy:                             ##定義pod更新的策略
    type: Recreate|RollingUpdate        ##選擇策略類型，默認(rèn)是RollingUpdate
    rollingUpdate:                      ##當(dāng)選擇RollingUpdate時(shí)要指定該更新方式的參數(shù)
      maxSurge:
      maxUnavailable: 
  template:                            ##創(chuàng)建一個(gè)pod模板，讓上面定義的副本數(shù)按照這么模板來(lái)創(chuàng)建pod
    metadata:                           創(chuàng)建pod的時(shí)候語(yǔ)法一樣。
      labels:
    spec:
      containers:
       ......(與創(chuàng)建pod的語(yǔ)法一樣) 

同其他 Kubernetes 配置一樣， Deployment 需要 .apiVersion，.kind 和 .metadata 字段。

當(dāng)控制面為 Deployment 創(chuàng)建新的 Pod 時(shí)，Deployment 的 .metadata.name 是命名這些 Pod 的部分基礎(chǔ)。 Deployment 的名稱必須是一個(gè)合法的 DNS 子域值， 但這會(huì)對(duì) Pod 的主機(jī)名產(chǎn)生意外的結(jié)果。為獲得最佳兼容性，名稱應(yīng)遵循更嚴(yán)格的 DNS 標(biāo)簽規(guī)則。

Deployment 還需要 .spec 部分

Pod模板

• .spec 中只有 .spec.template 和 .spec.selector 是必需的字段。

• .spec.template 是一個(gè) Pod 模板。 它和 Pod 的語(yǔ)法規(guī)則完全相同。 只是這里它是嵌套的，因此不需要 apiVersion 或 kind。

除了 Pod 的必填字段外，Deployment 中的 Pod 模板必須指定適當(dāng)?shù)臉?biāo)簽和適當(dāng)?shù)闹匦聠?dòng)策略。 對(duì)于標(biāo)簽，請(qǐng)確保不要與其他控制器重疊。

只有 .spec.template.spec.restartPolicy 等于 Always 才是被允許的，這也是在沒(méi)有指定時(shí)的默認(rèn)設(shè)置。

副本

.spec.replicas 是指定所需 Pod 的可選字段。它的默認(rèn)值是1。

如果你對(duì)某個(gè) Deployment 執(zhí)行了手動(dòng)擴(kuò)縮操作（例如，通過(guò) kubectl scale deployment deployment --replicas=X）， 之后基于清單對(duì) Deployment 執(zhí)行了更新操作（例如通過(guò)運(yùn)行 kubectl apply -f deployment.yaml），那么通過(guò)應(yīng)用清單而完成的更新會(huì)覆蓋之前手動(dòng)擴(kuò)縮所作的變更。

如果一個(gè) HorizontalPodAutoscaler （或者其他執(zhí)行水平擴(kuò)縮操作的類似 API）在管理 Deployment 的擴(kuò)縮， 則不要設(shè)置 .spec.replicas。

恰恰相反，應(yīng)該允許 Kubernetes 控制面來(lái)自動(dòng)管理 .spec.replicas 字段。

標(biāo)簽選擇器

.spec.selector 是指定本 Deployment 的 Pod 標(biāo)簽選擇算符的必需字段。

.spec.selector 必須匹配 .spec.template.metadata.labels，否則請(qǐng)求會(huì)被 API 拒絕。

在 API apps/v1版本中，.spec.selector 和 .metadata.labels 如果沒(méi)有設(shè)置的話， 不會(huì)被默認(rèn)設(shè)置為 .spec.template.metadata.labels，所以需要明確進(jìn)行設(shè)置。 同時(shí)在 apps/v1版本中，Deployment 創(chuàng)建后 .spec.selector 是不可變的。

當(dāng) Pod 的標(biāo)簽和選擇算符匹配，但其模板和 .spec.template 不同時(shí)，或者此類 Pod 的總數(shù)超過(guò) .spec.replicas 的設(shè)置時(shí)，Deployment 會(huì)終結(jié)之。 如果 Pod 總數(shù)未達(dá)到期望值，Deployment 會(huì)基于 .spec.template 創(chuàng)建新的 Pod。

說(shuō)明：

你不應(yīng)直接創(chuàng)建與此選擇算符匹配的 Pod，也不應(yīng)通過(guò)創(chuàng)建另一個(gè) Deployment 或者類似于 ReplicaSet 或 ReplicationController 這類控制器來(lái)創(chuàng)建標(biāo)簽與此選擇算符匹配的 Pod。 如果這樣做，第一個(gè) Deployment 會(huì)認(rèn)為它創(chuàng)建了這些 Pod。 Kubernetes 不會(huì)阻止你這么做。

如果有多個(gè)控制器的選擇算符發(fā)生重疊，則控制器之間會(huì)因沖突而無(wú)法正常工作

策略

.spec.strategy 策略指定用于用新 Pod 替換舊 Pod 的策略。 .spec.strategy.type 可以是 “Recreate” 或 “RollingUpdate”?！癛ollingUpdate” 是默認(rèn)值。

重新創(chuàng)建 Deployment

• 如果 .spec.strategy.type==Recreate，在創(chuàng)建新 Pod 之前，所有現(xiàn)有的 Pod 會(huì)被殺死。

說(shuō)明：

這只會(huì)確保為了升級(jí)而創(chuàng)建新 Pod 之前其他 Pod 都已終止。如果你升級(jí)一個(gè) Deployment， 所有舊版本的 Pod 都會(huì)立即被終止。控制器等待這些 Pod 被成功移除之后， 才會(huì)創(chuàng)建新版本的 Pod。如果你手動(dòng)刪除一個(gè) Pod，其生命周期是由 ReplicaSet 來(lái)控制的， 后者會(huì)立即創(chuàng)建一個(gè)替換 Pod（即使舊的 Pod 仍然處于 Terminating 狀態(tài)）。 如果你需要一種“最多 n 個(gè)”的 Pod 個(gè)數(shù)保證，你需要考慮使用 StatefulSet。

滾動(dòng)更新 Deploymen

Deployment 會(huì)在 .spec.strategy.type==RollingUpdate時(shí)，采取 滾動(dòng)更新的方式更新 Pod。你可以指定 maxUnavailable 和 maxSurge 來(lái)控制滾動(dòng)更新 過(guò)程。

• 最大不可用

.spec.strategy.rollingUpdate.maxUnavailable 是一個(gè)可選字段，用來(lái)指定 更新過(guò)程中不可用的 Pod 的個(gè)數(shù)上限。該值可以是絕對(duì)數(shù)字（例如，5），也可以是所需 Pod 的百分比（例如，10%）。百分比值會(huì)轉(zhuǎn)換成絕對(duì)數(shù)并去除小數(shù)部分。 如果 .spec.strategy.rollingUpdate.maxSurge 為 0，則此值不能為 0。 默認(rèn)值為 25%。

例如，當(dāng)此值設(shè)置為 30% 時(shí)，滾動(dòng)更新開(kāi)始時(shí)會(huì)立即將舊 ReplicaSet 縮容到期望 Pod 個(gè)數(shù)的70%。 新 Pod 準(zhǔn)備就緒后，可以繼續(xù)縮容舊有的 ReplicaSet，然后對(duì)新的 ReplicaSet 擴(kuò)容， 確保在更新期間可用的 Pod 總數(shù)在任何時(shí)候都至少為所需的 Pod 個(gè)數(shù)的 70%。

• 最大峰值

.spec.strategy.rollingUpdate.maxSurge 是一個(gè)可選字段，用來(lái)指定可以創(chuàng)建的超出期望 Pod 個(gè)數(shù)的 Pod 數(shù)量。此值可以是絕對(duì)數(shù)（例如，5）或所需 Pod 的百分比（例如，10%）。 如果 MaxUnavailable 為 0，則此值不能為 0。百分比值會(huì)通過(guò)向上取整轉(zhuǎn)換為絕對(duì)數(shù)。 此字段的默認(rèn)值為 25%。

例如，當(dāng)此值為 30% 時(shí)，啟動(dòng)滾動(dòng)更新后，會(huì)立即對(duì)新的 ReplicaSet 擴(kuò)容，同時(shí)保證新舊 Pod 的總數(shù)不超過(guò)所需 Pod 總數(shù)的 130%。一旦舊 Pod 被殺死，新的 ReplicaSet 可以進(jìn)一步擴(kuò)容， 同時(shí)確保更新期間的任何時(shí)候運(yùn)行中的 Pod 總數(shù)最多為所需 Pod 總數(shù)的 130%。

進(jìn)度期限秒數(shù)

.spec.progressDeadlineSeconds 是一個(gè)可選字段，用于指定系統(tǒng)在報(bào)告 Deployment 進(jìn)展失敗 之前等待 Deployment 取得進(jìn)展的秒數(shù)。 這類報(bào)告會(huì)在資源狀態(tài)中體現(xiàn)為 type: Progressing、status: False、 reason: ProgressDeadlineExceeded。Deployment 控制器將在默認(rèn) 600 毫秒內(nèi)持續(xù)重試 Deployment。 將來(lái)，一旦實(shí)現(xiàn)了自動(dòng)回滾，Deployment 控制器將在探測(cè)到這樣的條件時(shí)立即回滾 Deployment。

如果指定，則此字段值需要大于 .spec.minReadySeconds 取值。

最短就緒時(shí)間

.spec.minReadySeconds 是一個(gè)可選字段，用于指定新創(chuàng)建的 Pod 在沒(méi)有任意容器崩潰情況下的最小就緒時(shí)間， 只有超出這個(gè)時(shí)間 Pod 才被視為可用。默認(rèn)值為 0（Pod 在準(zhǔn)備就緒后立即將被視為可用）。 要了解何時(shí) Pod 被視為就緒， 可參考容器探針（服務(wù)可用性檢查）。

修訂歷史限制

Deployment 的修訂歷史記錄存儲(chǔ)在它所控制的 ReplicaSets 中。

.spec.revisionHistoryLimit 是一個(gè)可選字段，用來(lái)設(shè)定出于回滾目的所要保留的舊 ReplicaSet 數(shù)量。 這些舊 ReplicaSet 會(huì)消耗 etcd 中的資源，并占用 kubectl get rs 的輸出。 每個(gè) Deployment 修訂版本的配置都存儲(chǔ)在其 ReplicaSets 中；因此，一旦刪除了舊的 ReplicaSet， 將失去回滾到 Deployment 的對(duì)應(yīng)修訂版本的能力。 默認(rèn)情況下，系統(tǒng)保留 10 個(gè)舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩(wěn)定性。

更具體地說(shuō)，將此字段設(shè)置為 0 意味著將清理所有具有 0 個(gè)副本的舊 ReplicaSet。 在這種情況下，無(wú)法撤消新的 Deployment 上線，因?yàn)樗男抻啔v史被清除了。

paused（暫停的）

.spec.paused 是用于暫停和恢復(fù) Deployment 的可選布爾字段。 暫停的 Deployment 和未暫停的 Deployment 的唯一區(qū)別是，Deployment 處于暫停狀態(tài)時(shí)， PodTemplateSpec 的任何修改都不會(huì)觸發(fā)新的上線。 Deployment 在創(chuàng)建時(shí)是默認(rèn)不會(huì)處于暫停狀態(tài)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-589747.html

現(xiàn)在主流的Pod控制器就是Deployment，關(guān)于想了解ReplicaSet和ReplicationController可參考如下鏈接：

• ReplicaSet： https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/
• ReplicationController ：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/

為 0（Pod 在準(zhǔn)備就緒后立即將被視為可用）。 要了解何時(shí) Pod 被視為就緒， 可參考容器探針（服務(wù)可用性檢查）。

修訂歷史限制

Deployment 的修訂歷史記錄存儲(chǔ)在它所控制的 ReplicaSets 中。

.spec.revisionHistoryLimit 是一個(gè)可選字段，用來(lái)設(shè)定出于回滾目的所要保留的舊 ReplicaSet 數(shù)量。 這些舊 ReplicaSet 會(huì)消耗 etcd 中的資源，并占用 kubectl get rs 的輸出。 每個(gè) Deployment 修訂版本的配置都存儲(chǔ)在其 ReplicaSets 中；因此，一旦刪除了舊的 ReplicaSet， 將失去回滾到 Deployment 的對(duì)應(yīng)修訂版本的能力。 默認(rèn)情況下，系統(tǒng)保留 10 個(gè)舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩(wěn)定性。

更具體地說(shuō)，將此字段設(shè)置為 0 意味著將清理所有具有 0 個(gè)副本的舊 ReplicaSet。 在這種情況下，無(wú)法撤消新的 Deployment 上線，因?yàn)樗男抻啔v史被清除了。

paused（暫停的）

.spec.paused 是用于暫停和恢復(fù) Deployment 的可選布爾字段。 暫停的 Deployment 和未暫停的 Deployment 的唯一區(qū)別是，Deployment 處于暫停狀態(tài)時(shí)， PodTemplateSpec 的任何修改都不會(huì)觸發(fā)新的上線。 Deployment 在創(chuàng)建時(shí)是默認(rèn)不會(huì)處于暫停狀態(tài)。

到了這里，關(guān)于【云原生|Kubernetes】13-Deployment資源控制器詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！