访问应用测试

更新策略

...
spec:
  replicas: 2	#指定Pod副本数
  selector:		#指定Pod的选择器
    matchLabels:
      app: eladmin-api
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate		#指定更新方式为滚动更新，默认策略，通过get deploy yaml查看
    ...

策略控制：

maxSurge：最大激增数, 指更新过程中, 最多可以比replicas预先设定值多出的pod数量, 可以为固定值或百分比,默认为desired Pods数的25%。计算时向上取整(比如0.5，取1)，更新过程中最多会有replicas + maxSurge个pod
maxUnavailable：指更新过程中, 最多有几个pod处于无法服务状态 , 可以为固定值或百分比，默认为desired Pods数的25%。计算时向下取整(比如0.5，取0)

在Deployment rollout时，需要保证Available(Ready) Pods数不低于 replicas - maxUnavailable; 保证所有的非异常状态Pods数不多于 replicas + maxSurge。

以eladmin-api为例，使用默认的策略，更新过程:

maxSurge 25%，2个实例，向上取整，则maxSurge为1，意味着最多可以有2+1=3个Pod，那么此时会新创建1个ReplicaSet，RS-new，把副本数置为1，此时呢，副本控制器就去创建这个新的Pod
同时，maxUnavailable是25%，副本数2*25%，向下取整，则为0，意味着，滚动更新的过程中，不能有少于2个可用的Pod，因此，旧的Replica（RS-old）会先保持不动，等RS-new管理的Pod状态Ready后，此时已经有3个Ready状态的Pod了，那么由于只要保证有2个可用的Pod即可，因此，RS-old的副本数会有2个变成1个，此时，会删掉一个旧的Pod
删掉旧的Pod的时候，由于总的Pod数量又变成2个了，因此，距离最大的3个还有1个Pod可以创建，所以，RS-new把管理的副本数由1改成2，此时又会创建1个新的Pod，等RS-new管理了2个Pod都ready后，那么就可以把RS-old的副本数由1置为0了，这样就完成了滚动更新

#查看滚动更新事件
$ kubectl -n luffy describe deploy eladmin-api

$ kubectl get rs

除了滚动更新以外，还有一种策略是Recreate，直接在当前的pod基础上先删后建：

...
  strategy:
    type: Recreate
...

我们课程中的mysql服务应该使用Recreate来管理：

$ kubectl -n luffy edit deploy mysql
...
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: mysql
...

服务回滚

通过滚动升级的策略可以平滑的升级Deployment，若升级出现问题，需要最快且最好的方式回退到上一次能够提供正常工作的版本。为此K8S提供了回滚机制。

revision：更新应用时，K8S都会记录当前的版本号，即为revision，当升级出现问题时，可通过回滚到某个特定的revision，默认配置下，K8S只会保留最近的几个revision，可以通过Deployment配置文件中的spec.revisionHistoryLimit属性增加revision数量，默认是10。

查看当前：

$ kubectl -n luffy rollout history deploy eladmin-api ##CHANGE-CAUSE为空
$ kubectl delete -f deployment-eladmin-api.yaml    ## 方便演示到具体效果，删掉已有deployment

记录回滚：

$ kubectl apply -f deployment-eladmin-api.yaml --record

$ kubectl -n luffy edit deploy eladmin-api --record=true

查看deployment更新历史：

$ kubectl -n luffy rollout history deploy eladmin-api
deployment.apps/eladmin-api
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment-eladmin-api.yaml --record=true
2         kubectl edit  deployment eladmin-api --record=true

回滚到具体的REVISION:

$ kubectl -n luffy rollout undo deploy eladmin-api --to-revision=1
deployment.apps/eladmin-api rolled back

# 访问应用测试

更新策略​

服务回滚​

更新策略

服务回滚