前一章介紹了Deployment如何建立，以及產生ReplicaSet後，可以看到pod是怎麼被建立起來的。
不同的建立方式是看strategy，不同的strategy會讓pod以不同的規則建立起來，預設都會使用RollingUpdate，也就是先建立新的pod，再將舊的pod下掉。那麼有哪些strategy可以使用呢？就讓我們在下面介紹。

RollingUpdate

第一個升級策略(strategy)是RollingUpdate，就像前面敘述一樣，會先建立新的pod，再將舊的pod下掉，再來讓我們看向範例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollingupdate-strategy-example
  labels:
    app: nginx
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

首先建立個yaml叫rolling.yaml，然後把上面的內容複製進去
特別要注意的點在於這些設定：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

type:
代表會用RollingUpdate的方式來更新pod
maxSurge:
表示會等建立兩個新pod後才刪除一個舊pod，假設replicas為3，代表過程中會出現3+2個pod，可以填數量也 可以填百分比，預設是25%。
maxUnavailable:
最多可以有幾個pod在無法使用狀態，在這邊是一個，預設也是25%。

要檢驗RollingUpdate，可以使用前面幾章提到的指令

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

這時pod就會用rollingupdate的方式升級了。

Recreate

另一個升級策略是Recreate，跟RollingUpdate不同，Recreate會先將pod都關閉，再建立新的pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollingupdate-strategy-example
  labels:
    app: nginx
spec:
  strategy:
    type: Recreate

由於其特性，就不像RollingUpdate需要設定maxSurge和maxUnavailable了，測試方式跟上面一樣使用

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

雖然通常會使用的策略是RollingUpdate，不過在某些情況之下也會使用Recreate，讓pod全部關閉後再建立新的pod，端看使用情境，不過這兩種方式建立出來的pod，內容都是全新的，假如使用的是mysql或是redis，裡面的資料都會在更新pod時被清空，那麼要如何將資料保存下來呢？
這也是下一章StatefulSets會介紹的內容。