k8s滚动更新

对于Kubernetes集群来说，一个service可能有多个pod，滚动升级（Rolling update）就是指每次更新部分Pod，而不是在同一时刻将该Service下面的所有Pod shutdown，然后去更新（例如replace --force方案），逐个更新可以避免将业务中断，

在spec项中增加几个参数

spec:
  minReadySeconds: 5
  strategy:
  # indicate which strategy we want for rolling update
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

• 字段解释

minReadySeconds
Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了，所以这个可以设置的保守一些，比如我们的服务启动从3-20秒不等，我可以设置成30秒，这样防止pod启动了但是服务还没准备好导致系统不可用。

• maxSurge
  升级过程中最多可以比原先设置多出的POD数量
  例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

• maxUnavaible
  升级过程中最多有多少个POD处于无法提供服务的状态，当maxSurge不为0时，该值也不能为0，最好和maxSurge保持一致。
  例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态，可以保证有足够的pod（或者认为是足够的性能）提供服务。

完整模板

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-api
  labels:
    name: dev-api
spec:
  replicas: 2
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      name: dev-api
  template:
    metadata:
      labels:
       name: dev-api
    spec:
      containers:
      - name: dev-api
        image: nginx:1.8
        imagePullPolicy: Never
        ports:
        - containerPort: 80

• 方法1. 如果修改了yaml文件

kubectl apply -f XX.yml

• 方法2. 如果没有更改yaml文件却想要平滑重启

 kubectl rollout restart deployment <deployment>

• 查看滚动升级的状态

kubectl rollout status deployment/<deployment>

• 暂停升级

kubectl rollout pause deployment <deployment>

• 恢复升级

kubectl rollout resume deployment <deployment>

回滚

• 查看Deployment的升级历史

kubectl rollout history deployment <deployment>

• 注意:
  record类似一个栈，先执行的apply会放到记录的最下端。也就是说你的上一个版本一定是2.
  record记录的是apply的命令，所以如果每次执行的命令是一样的话，会覆盖掉。

• 查看某一次的revison信息

kubectl rollout history deployment <deployment> --revision=1

• 回滚到某一版本

kubectl rollout undo deployment <deployment> --to-revision=2
如果不写后面的--to-revision参数，默认回滚到上一个版本

• 注意坑

• 所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化，这无疑会占用etcd资源，最重要的是，时间久了，当你kubectl get rs时，会有成百上千的垃圾RS返回给你，这其实也没有太大的作用，一般保留几个版本就可以了。

我们可以通过设置Deployment的.spec.revisionHistoryLimit参数来限制最大保留的revision 数量，比如10个版本。

另外其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某个ReplicaSet，对应的rollout history就会被删除，也就是还说你无法回滚到这个revison了。