官網(wǎng)參考地址：

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/

1. Deployment 基礎(chǔ)

1.1 什么是 Deployment

Deployment 屬于 k8s 中的一種工作負(fù)載資源，一個(gè) Deployment 為 Pod 和 ReplicaSet （副本控制器）提供聲明式的更細(xì)能力：

• 我們只需要描述 Deployment 中的目標(biāo)狀態(tài)
• Deployment 控制器以受控的速率（不間斷）更改實(shí)際狀態(tài)，使其變成我們所描述的目標(biāo)期望狀態(tài)（控制循環(huán)）
• Deployment 使 Pod 有自愈能力
• 我們部署應(yīng)用一般不會(huì)直接寫 Pod，而是部署一個(gè) Deployment

1.2 簡單體驗(yàn) Deployment

來自官網(wǎng)的一個(gè)示例文件

####deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2

我們嘗試啟動(dòng)一下：kubectl apply -f deploy-demo.yaml

1. 創(chuàng)建了一個(gè)名字為 nginx-deployment 的 Deployment，這個(gè)名稱成為后續(xù)創(chuàng)建 ReplicaSet 和 Pod 的命名基礎(chǔ)

2. Deployment 創(chuàng)建了一個(gè) ReplicaSet，由它創(chuàng)建了三個(gè) Pod 副本

3. .spec.selector 字段定義所創(chuàng)建的 ReplicaSet 如何查找要管理的 Pod。 在這里，選擇在 Pod 模板中定義的標(biāo)簽（app: nginx），建議就保持一致即可

4. template 字段里面其實(shí)就是一個(gè) Pod的模板，和之前學(xué)習(xí) Pod 寫法是一樣的

5. 一次 Deployment，產(chǎn)生了如下資源

   • Deployment 資源
   • ReplicaSet資源
   • Pod 資源

1.3 Deployment 信息描述

檢查 Deployment 信息

kubectl get deploy

• 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í)間

檢查 Deployment 上線狀態(tài)

kubectl rollout status deploy nginx-deployment

檢查 Deployment 創(chuàng)建出來的 ReplicaSet 信息

kubectl get 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í)間長度

檢查 Pod 自動(dòng)生成的標(biāo)簽信息

kubectl get pod --show-labels

1.4 如何編寫 Deployment

官網(wǎng)參考：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/deployment-v1/

• 老辦法，官網(wǎng)加命令參考如何編寫一個(gè)資源 yaml 文件：kubectl explain deploy

KIND:     Deployment
VERSION:  apps/v1DESCRIPTION:Deployment enables declarative updates for Pods and ReplicaSets.FIELDS:apiVersion   <string>APIVersion defines the versioned schema of this representation of anobject. Servers should convert recognized schemas to the latest internalvalue, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resourceskind <string>Kind is a string value representing the REST resource this objectrepresents. Servers may infer this from the endpoint the client submitsrequests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsmetadata     <Object>  ## 標(biāo)準(zhǔn)的元數(shù)據(jù)信息Standard object's metadata. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec <Object>  ## 需要我們手動(dòng)描述的行為規(guī)約Specification of the desired behavior of the Deployment.status       <Object>  ## 最近觀測到的狀態(tài)，k8s自動(dòng)更新，不需要我們描述Most recently observed status of the Deployment.

• 注意再看一下 spec 規(guī)約如何描述：kubectl explain deploy.spec

FIELDS:minReadySeconds      <integer> ##Pod就緒后被視為可用的時(shí)間，默認(rèn)為0Minimum number of seconds for which a newly created pod should be readywithout any of its container crashing, for it to be considered available.Defaults to 0 (pod will be considered available as soon as it is ready)paused       <boolean> ## 暫停部署Indicates that the deployment is paused.progressDeadlineSeconds      <integer> ## deployment部署的最大秒數(shù)，默認(rèn)600s，超過就報(bào)錯(cuò)誤了The maximum time in seconds for a deployment to make progress before it isconsidered to be failed. The deployment controller will continue to processfailed deployments and a condition with a ProgressDeadlineExceeded reasonwill be surfaced in the deployment status. Note that progress will not beestimated during the time a deployment is paused. Defaults to 600s.replicas     <integer>  ##pod數(shù)量（副本數(shù)），默認(rèn)是1 `RS`控制器實(shí)現(xiàn)的Number of desired pods. This is a pointer to distinguish between explicitzero and not specified. Defaults to 1.revisionHistoryLimit <integer>  ##保留允許回滾的舊 ReplicaSet 的數(shù)量。默認(rèn)10The number of old ReplicaSets to retain to allow rollback. This is apointer to distinguish between explicit zero and not specified. Defaults to10.selector     <Object> -required- ##指定要控制的pod的標(biāo)簽Label selector for pods. Existing ReplicaSets whose pods are selected bythis will be the ones affected by this deployment. It must match the podtemplate's labels.strategy     <Object>  ## 更新策略The deployment strategy to use to replace existing pods with new ones.rollingUpdate	<Object> ## 指定滾動(dòng)更新策略maxSurge	<string> ## 【最大增量】一次最多新建幾個(gè)Pod。 百分比和數(shù)字都可以MaxUnavailable：為0 的時(shí)候， maxSurge不能為0maxUnavailable ## 【最大不可用量】最大不可用的Pod數(shù)量,最多殺幾個(gè)podtype	<string>: Recreate/RollingUpdate（默認(rèn)）template     <Object> -required- ## 必須描述項(xiàng)，描述將要?jiǎng)?chuàng)建的Pod，這個(gè)里面的寫法就是我們之前學(xué)過的pod的寫法Template describes the pods that will be created.

• 小小的驗(yàn)證幾下：

##我有這么一個(gè)deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2

2. Deployment 簡單特性

2.1 賦予 Pod 故障轉(zhuǎn)移和自愈能力

Deployment 賦予了 Pod 故障轉(zhuǎn)移和自愈能力

• 我們部署一個(gè)測試 yaml

##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2

• 嘗試刪除一些 Pod，并在另一個(gè)控制臺(tái)觀察一下狀態(tài)：會(huì)自愈

kubectl get pod -owide -w

• 我們直接將k8s-03關(guān)機(jī)，看一下狀態(tài)：在特定的時(shí)間內(nèi)，會(huì)在其他節(jié)點(diǎn)啟動(dòng)故障的 Pod

2.2 更新 Deployment

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

更新上線動(dòng)作原理： 創(chuàng)建新的 rs，準(zhǔn)備就緒后，替換舊的 rs（此時(shí)不會(huì)刪除，因?yàn)?code>revisionHistoryLimit 指定了保留幾個(gè)版本）

更新 Pod 鏡像

• 現(xiàn)在我們有一個(gè)示例文件在運(yùn)行

##我有這么一個(gè)deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2

• 我們先來更新一下 Pod 的鏡像為：nginx

##可以直接改yaml文件進(jìn)行更新
##我有這么一個(gè)deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx  ##修改鏡像

• 再執(zhí)行一次：kubectl apply -f deploy-demo.yaml

• 查看一下上線狀態(tài)：kubectl rollout status deploy nginx-deployment

• 查看一下 ReplicaSet 的信息：kubectl get rs

通過創(chuàng)建新的 ReplicaSet 并將其擴(kuò)容到 3 個(gè)副本并將舊 ReplicaSet 縮容到 0 個(gè)副本完成了 Pod 的更新操作

1. 更新時(shí)會(huì)關(guān)閉一定數(shù)量的 Pod，默認(rèn)情況下確保至少所需 Pod 的75%處于運(yùn)行狀態(tài)（最大比例為25%）
2. 還確保僅所創(chuàng)建 Pod 數(shù)量只可能比期望 Pod 數(shù)高一點(diǎn)點(diǎn)。 默認(rèn)情況下，它可確保啟動(dòng)的 Pod 個(gè)數(shù)比期望個(gè)數(shù)最多多出 125%（最大峰值 25%）。

再觀測一下更新狀態(tài)

• 啟動(dòng)一個(gè)測試

##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 2 ### 更新期間任何時(shí)間運(yùn)行的Pod總數(shù)最多為預(yù)期Pod數(shù)量7個(gè)maxUnavailable: 2 ##更新期間可能不可用的最大Pod數(shù)量2個(gè)template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2

• 更新它

##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 2 ### 更新期間任何時(shí)間運(yùn)行的Pod總數(shù)最多為預(yù)期Pod數(shù)量7個(gè)maxUnavailable: 2 ##更新期間可能不可用的最大Pod數(shù)量2個(gè)template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.6-alpine

• 追蹤狀態(tài)

停止2個(gè)，啟動(dòng)4個(gè)

最終更新到一個(gè)期待狀態(tài)

• 獲取一下 Deployment 的信息

kubectl describe deploy nginx-deployment

最開始創(chuàng)建的時(shí)候，`Deployment`創(chuàng)建了 `RS`并將直接擴(kuò)容到5個(gè)副本
更新的時(shí)候，創(chuàng)建一個(gè)新的 `RS`，并將其擴(kuò)容為2，等待其就緒
舊的 `RS` 縮容到3
新的 `RS` 擴(kuò)容到4
繼續(xù)對(duì) `RS` 擴(kuò)縮容
最終5個(gè)可用的副本在新的 `RS` 中
舊的 `RS` 縮容為0

加深一下這個(gè)地方的理解

      maxSurge: 3 ### 更新期間任何時(shí)間運(yùn)行的Pod總數(shù)最多為預(yù)期Pod數(shù)量8個(gè)maxUnavailable: 4 ##更新期間可能不可用的最大Pod數(shù)量4個(gè)

創(chuàng)建了一個(gè)新的 `RS`擴(kuò)容到3，就緒準(zhǔn)備
舊的 `RS` 縮容到1，以便最大不可用數(shù)量有4個(gè)
將新的 `RS` 擴(kuò)容到5
將舊的 `RS` 縮容到0

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

比例縮放圖示

2.3 回滾 Deployment

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

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ì)被回滾。

模擬一下錯(cuò)誤滾動(dòng)升級(jí)

• 準(zhǔn)備一個(gè)測試 yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1

• 模擬一下錯(cuò)誤升級(jí)

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.1555

• 查看一下狀態(tài)

• 查看一下上線狀態(tài)

kubectl rollout status deployment/nginx-deployment

###上線處于一個(gè)停滯狀態(tài)
[root@k8s-01 k8s-yaml]# kubectl rollout status deployment/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 5 new replicas have been updated...

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

回滾操作

• 檢查 Deployment 修訂歷史：kubectl rollout history deployment/nginx-deployment

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

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

• 查看修訂歷史的詳細(xì)信息：kubectl rollout history deployment/nginx-deployment --revision=2

• 回滾到之前的修訂版本：我們要回滾到版本1：kubectl rollout undo deployment/nginx-deployment --to-revision=1

撤消當(dāng)前上線回滾到以前的修訂版本：

kubectl rollout undo deployment/nginx-deployment

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

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

• 一個(gè)測試

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1

• 修改 yaml 文件暫停上線

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暫停上線，默認(rèn)falsereplicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1

• 修改 yaml 更新鏡像

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暫停上線，默認(rèn)falsereplicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx

• 從可觀測的狀態(tài)來看，這次更新并沒有產(chǎn)生新的上線動(dòng)作，也不會(huì)產(chǎn)生新的 RS

• 我們?cè)俅涡薷母乱幌络R像

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暫停上線，默認(rèn)falsereplicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.6-alpine

• 修改 .spec.paused ，恢復(fù)上線

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: false ##true表示暫停上線，默認(rèn)falsereplicas: 5  ## 5個(gè)副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滾動(dòng)更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.6-alpine

• 看一下狀態(tài)：正常上線

不可以回滾處于暫停狀態(tài)的 Deployment，除非先恢復(fù)其執(zhí)行狀態(tài)。

2.5 Deployment 規(guī)約描述

Pod 模板

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

副本數(shù)

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

選擇算符

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

策略

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

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

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

最大不可用

.spec.strategy.rollingUpdate.maxUnavailable 是一個(gè)可選字段，用來指定更新過程中不可用的 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)更新開始時(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è)可選字段，用來指定可以創(chuàng)建的超出期望 Pod 個(gè)數(shù)的 Pod 數(shù)量。此值可以是絕對(duì)數(shù)（例如，5）或所需 Pod 的百分比（例如，10%）。 如果 MaxUnavailable 為 0，則此值不能為 0。百分比值會(huì)通過向上取整轉(zhuǎn)換為絕對(duì)數(shù)。 此字段的默認(rèn)值為 25%。

例如，當(dāng)此值為 30% 時(shí)，啟動(dòng)滾動(dòng)更新后，會(huì)立即對(duì)新的 ReplicaSet 擴(kuò)容，同時(shí)保證新舊 Pod 的總數(shù)不超過所需 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。 將來，一旦實(shí)現(xiàn)了自動(dòng)回滾，Deployment 控制器將在探測到這樣的條件時(shí)立即回滾 Deployment。

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

最短就緒時(shí)間

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

修訂歷史版本限制

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

.spec.revisionHistoryLimit 是一個(gè)可選字段，用來設(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)定性。

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

暫停

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