最小就緒時間：
配置時，用戶可以使用Deplpoyment控制器的spec.minReadySeconds屬性來控制應用升級的速度。新舊更替過程中，新創建的Pod對象一旦成功響應就緒探測即被視作可用，而后即可立即開始下一輪的替換操作。而spec.minReadySeconds能夠定義在新的Pod對象創建后至少要等待多久才會將其視作就緒，在此期間，更新操作會被阻塞。因此，它可以用來讓Kubernetes在每次創建出Pod資源后都要等上一段時長后再開始下一輪的更替，這個時間長度的理想值是等到Pod對象中的應用已經可以接受並處理請求流量。
更新策略
2.1 重新創建：先刪除現有的Pod對象，而后由控制器基於新模板重新創建出新版本資源對象。通常，只應該在應用的新舊版本不兼容時運行時才會使recreate策略，因為它會導致應用替換期間暫時不可用，好處在於它不存在中間狀態，用戶訪問到的要么是應用的新版本，要么是舊版本。
2.2 滾動更新：默認的更新策略，在刪除一部分舊版本Pod資源的同時，補充創建一部分新版本的Pod對象進行應用升級，其優勢是升級期間，容器中應用提供的服務不會中斷，但要求應用程序能夠應對新舊版本同時工作作的情形。不過，更新操作期間，不同客戶端得到的響應內容可能會來自不同版本的應用。
Deployment控制器的滾動更新操作並非在同一個ReplicaSet控制器對象下刪除並創建Pod資源，而是將它們分置於兩個不同的控制器之下：舊控制器的Pod對象數量不斷減少的同時，新控制器的Pod對象數量不斷增加，直到舊控制器不再擁有Pod對象，而新控制器的副本數量變得完全符合期望值為止。
滾動更新時，應用升級期間還要確保可用的Pod對象數量不低於某閾值以確保可以持續處理客戶端的服務請求，變動的方式和Pod對象的數量范圍將通過最大超出副本數(spec.strategy.rollingUpdate.maxSurg)和最大不可用副本數(spec.strategy.rollingUpdate.maxUnavailable)兩個屬性協同進行定義。
- maxSurge：指定升級期間存在的總Pod對象數量最多可超出期望值的個數，其值可以是0或正整數，也可以是一個期望值的百分比。例如，如果期望值為3，當前的屬性值為1，則表示Pod對象的總數不能超過4個。
- maxUnavailable：升級期間正常可用的Pod副本數（包括新舊版本）最多不能低於期望數值的個數，其值可以是0或正整數，也可以是一個期望值的百分比；默認值為1，該值意味着如果期望值是3，則升級期間至少要有兩個Pod對象處於正常提供服務的狀態。
注意：maxSurge和maxUnavailable屬性的值不可同時為0，否則Pod對象的副本數量在符合用戶期望的數量后無法做出合理變動以進行滾動更新操作。
歷史版本數量
Deployment控制器也支持用戶保留其滾動更新歷史中的舊ReplicaSet對象版本。這賦予了控制器進行應用回滾的能力：用戶可按需回滾到指定的歷史版本。控制器可保存的歷史版本數量由“spec.revisionHistoryLimit”屬性進行定義。當然，也只有保存於revision歷史中的ReplicaSet版本可用於回滾。
為了保存版本升級的歷史，需要在創建Deployment對象時於命令中使⽤“--record”選項。"kubectl apply -f myapp-deploy.yaml --record"