在實際應用中，升級是一個常見的場景，Deployment、StatefulSet和DaemonSet都能夠很方便的支撐應用升級。
設置不同的升級策略，有如下兩種。
- RollingUpdate：滾動升級，即逐步創建新Pod再刪除舊Pod，為默認策略。
- Recreate：替換升級，即先把當前Pod刪掉再重新創建Pod。
![]()
升級參數說明
- 最大浪涌（maxSurge）
與spec.replicas相比，可以有多少個Pod存在，默認值是25%，比如spec.replicas為 4，那升級過程中就不能超過5個Pod存在，即按1個的步伐升級，實際升級過程中會換算成數字，且換算會向上取整。這個值也可以直接設置成數字。
僅Deployment支持配置。
- 最大無效實例數（maxUnavailable）
與spec.replicas相比，可以有多少個Pod失效，也就是刪除的比例，默認值是25%，比如spec.replicas為4，那升級過程中就至少有3個Pod存在，即刪除Pod的步伐是1。同樣這個值也可以設置成數字。
僅Deployment支持配置。
- 實例可用最短時間（minReadySeconds）
指定新創建的Pod 在沒有任意容器崩潰情況下的最小就緒時間， 只有超出這個時間 Pod 才被視為可用。默認值為 0（Pod 在準備就緒后立即將被視為可用）。
- 最大保留版本數（revisionHistoryLimit）
用來設定出于回滾目的所要保留的舊** **ReplicaSet 數量。 這些舊 ReplicaSet 會消耗 etcd 中的資源，并占用 kubectl get rs 的輸出。 每個 Deployment 修訂版本的配置都存儲在其 ReplicaSets 中；因此，一旦刪除了舊的 ReplicaSet， 將失去回滾到 Deployment 的對應修訂版本的能力。 默認情況下，系統保留 10 個舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩定性。
- 升級最大時長（progressDeadlineSeconds）
指定系統在報告Deployment 進展失敗 之前等待 Deployment 取得進展的秒數。 這類報告會在資源狀態中體現為 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器將持續重試 Deployment。 將來，一旦實現了自動回滾，Deployment 控制器將在探測到這樣的條件時立即回滾 Deployment。
如果指定，則此字段值需要大于.spec.minReadySeconds 取值。
- 縮容時間窗（terminationGracePeriodSeconds）：
優雅刪除時間，默認為30秒，刪除Pod時發送SIGTERM終止信號，然后等待容器中的應用程序終止執行，如果在terminationGracePeriodSeconds時間內未能終止，則發送SIGKILL的系統信號強行終止。
升級示例
Deployment的升級可以是聲明式的，也就是說只需要修改Deployment的YAML定義即可，比如使用kubectl edit命令將上面Deployment中的鏡像修改為nginx:alpine。修改完成后再查詢ReplicaSet和Pod，發現創建了一個新的ReplicaSet，Pod也重新創建了。
$ kubectl edit deploy nginx$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-6f9f58dffd 2 2 2 1m
nginx-7f98958cdf 0 0 0 48m$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m
nginx-6f9f58dffd-tesqr 1/1 Running 0 1m
Deployment可以通過maxSurge和maxUnavailable兩個參數控制升級過程中同時重新創建Pod的比例，這在很多時候是非常有用，配置如下所示。
spec:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都為默認值25%，那實際升級過程中，maxSurge允許最多3個Pod存在（向上取整，21.25=2.5，取整為3），而maxUnavailable則不允許有Pod Unavailable（向上取整，20.75=1.5，取整為2），也就是說在升級過程中，一直會有2個Pod處于運行狀態，每次新建一個Pod，等這個Pod創建成功后再刪掉一個舊Pod，直至Pod全部為新Pod。
回滾
回滾也稱為回退，即當發現升級出現問題時，讓應用回到老的版本。Deployment可以非常方便的回滾到老版本。
例如上面升級的新版鏡像有問題，可以執行kubectl rollout undo命令進行回滾。
$ kubectl rollout undo deployment nginx
deployment.apps/nginx rolled back
Deployment之所以能如此容易的做到回滾，是因為Deployment是通過ReplicaSet控制Pod的，升級后之前ReplicaSet都一直存在，Deployment回滾做的就是使用之前的ReplicaSet再次把Pod創建出來。Deployment中保存ReplicaSet的數量可以使用revisionHistoryLimit參數限制，默認值為10。
