Day16-策略不只用在兵法 什麽是策略(Strategy)

前一章介绍了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会介绍的内容。