pod的升級和回滾

若是pod是經過Deployment建立的，則用戶能夠在運行時修改Deployment的pod定義（sepc.template）或鏡像名稱，並應用到Deployment對象上，系統便可完成Deployment的自動更新操做。若是在更新過程當中發生了錯誤，則還能夠經過回滾操做恢復Pod的版本。

Deployment的升級

以Deployment nginx爲例：

kubectl create -f nginx-deployment.yaml --record=true

apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:

• name: nginx
  image: nginx:1.7.9
  ports:
  • containerPort: 80

如今pod鏡像須要被更新爲 nginx:1.9.1，咱們能夠經過kubectl set image 命令爲Deployment設置新的鏡像名稱：

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

另一種方法是使用kubectl edit命令直接修改Deployment的配置，將image從nginx:1.7.9更改成nginx:1.9.1。

kubectl edit deployment/nginx-deployment

一旦鏡像名發生了修改，則將觸發系統完成Deployment全部運行pod的滾動升級操做，可使用kubectl rollout status 命令查看Deployment的更新過程：

kubectl rollout status deployment/nginx-deployment

運行kubectl get rs 命令，能夠看到兩個ReplicaSet的最終狀態：

更新策略：

在deployment的定義中，能夠經過spec.strategy指定pod更新的策略，目前支持兩種策略：Recreate（重建）和RollingUpdate（滾動更新）策略，默認值爲RollingUpdate。

Recreate：設置spec.strategy.type=Recreate，表示Deployment在更新pod時，會先殺掉全部正在運行的pod，而後建立新的pod。

RollingUpdate：設置spec.strategy.type=RollingUpdate，表示Deployment會以滾動更新的方式來逐個更新pod。同時，能夠經過設置spec.strategy.rollingUpdate下的兩個參數（maxUnavailable和maxSurge）來控制滾動更新的過程。

Deployment是如何完成Pod更新的呢？經過kubectl describe deployment nginx-deployment 能夠看到詳細的事件信息：

spec.strategy.rollingUpdate.maxUnavailable：用於指定Deployment在更新過程當中不可用狀態的pod數量的上限。該參數的數值能夠是絕對值（例如5）或pod指望的副本數的百分比（例如10%），若是被設置爲百分比，那麼系統會先以向下取整的方式計算出絕對值。而當另外一個參數maxSurge被設置爲0時，maxUnavailable則必須被設置爲絕對值大於0。默認值爲25%。

spec.strategy.rollingUpdate.maxSurge：用於指定Deployment在更新過程當中pod總數超過pod指望副本數部分的最大值，該maxSurge的數值能夠是絕對值（例如5）或pod指望副本數的百分比（例如10%），若是設置爲百分比，那麼系統會先按照向上取整的方式計算出絕對值。默認值爲25%

多重更新（Rollover）的狀況

若是deployment的上一次更新正在進行，此時用戶再次發起deployment的更新操做，那麼deployment會爲每一次更新都建立一個ReplicaSet，而每次在新的ReplicaSet建立成功後，會逐個增長pod副本數，同時將以前正在擴容的ReplicaSet中止擴容更新，並將其加入舊版本ResplicaSet列表中，而後開始縮容至0的操做。

假設咱們建立了一個deployment，這個deployment開始建立了5個nginx:1.7.9的pod副本，在這個建立pod動做還沒有完成時，咱們又將deployment進行更新，在副本數量不變的狀況下將pod模板中的鏡像修改成nginx:1.9.1，又假設此時deployment已經建立了3個nginx:1.7.9的pod副本，則deployment會當即殺掉已建立的3個nginx:1.7.9 pod，並開始建立nginx:1.9.1 pod。deployment不會在等待nginx:1.7.9的pod建立到5個以後再進行更新操做。

Deployment的回滾

kubectl create -f nginx-deployment.yaml --record=true

在建立deployment時使用--record=true參數，就能夠在歷史命令中看到每一個版本所執行的命令了

假如咱們在更新deployment鏡像時，將容器鏡像名稱設置錯誤爲nginx:1.7（一個不存在的鏡像），則部署過程會卡在拉取鏡像過程當中。

這時，咱們須要回滾到以前穩定版本的deployment。

首先，使用kubectl rollout history命令查看deployment部署的歷史記錄：

kubectl rollout history deployment nginx-deployment

若是須要查看某一條命令的詳細信息，則能夠加上--reversion=<N>參數

kubectl rollout history deployment nginx-deployment --reversion=3

咱們能夠看到image的版本是nginx1.7，並不存在此鏡像！！！

如今咱們決定撤銷本次發佈並回滾到上一個部署版本：

kubectl rollout undo deployment nginx-deployment

也可使用--to-revision參數指定回滾到的部署版本號：

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

這樣就能夠回滾到以前的穩定版本了。