服务在滚动更新时，deployment控制器的目的是：给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)。大家在使用时，通常容易忽视控制速率的特性，以下是kubernetes提供的两个参数：

maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
取值范围
数值

• maxUnavailable: [0, 副本数]
• maxSurge: [0, 副本数]

注意：两者不能同时为0。

比例

• maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
• maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；

注意：两者不能同时为0。

建议配置

• maxUnavailable == 0
• maxSurge == 1

这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。

自定义策略

Deployment controller调整replicaset数量时，严格通过以下公式来控制发布节奏。所以，如需快速发布，可根据实际情况去调整这两个值：

(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)
举例：如果期望副本数是10，期望能有至少80%数量的副本能稳定工作，所以:maxUnavailable = 2，maxSurge = 2 (可自定义，建议与maxUnavailable保持一致)

8 <= 线上实际Ready副本数 <= 12
这样，更新过程中，线上能够正常提供服务的pod数总会保持在这个区间内。

现象（maxUnavailable = 1，maxSurge = 1）

我这里跟新了镜像然后应用，也就是滚动更新

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

可以看到是先删除一个旧版本，待新版本创建并且running再删除一个旧版本

[root@k8s-master ~]# kubectl get ep -w
NAME         ENDPOINTS                                             AGE
kubernetes   192.168.179.102:6443                                  29d
web          10.244.169.141:80,10.244.169.142:80,10.244.36.78:80   8m8s

web          10.244.169.141:80,10.244.36.78:80                     8m58s
web          10.244.169.141:80,10.244.36.78:80                     10m
web          10.244.169.141:80,10.244.169.143:80,10.244.36.78:80   10m
web          10.244.169.143:80,10.244.36.78:80                     10m
web          10.244.169.143:80,10.244.36.78:80                     10m
web          10.244.169.143:80,10.244.169.144:80,10.244.36.78:80   10m
web          10.244.169.143:80,10.244.169.144:80                   10m
web          10.244.169.143:80,10.244.169.144:80                   11m
web          10.244.169.143:80,10.244.169.144:80,10.244.36.79:80   11m

[root@k8s-master ~]# kubectl get pod -w
NAME                   READY   STATUS    RESTARTS   AGE
web-655569c6d8-96kmp   1/1     Running   0          15m
web-655569c6d8-n8nvk   1/1     Running   0          15m
web-655569c6d8-vmnj6   1/1     Running   0          15m

web-7cf4f6bf9f-kktpq   0/1     Pending   0          0s
web-7cf4f6bf9f-kktpq   0/1     Pending   0          0s
web-655569c6d8-n8nvk   1/1     Terminating   0          15m
web-7cf4f6bf9f-bbchz   0/1     Pending       0          0s
web-7cf4f6bf9f-bbchz   0/1     Pending       0          1s
web-655569c6d8-n8nvk   1/1     Terminating   0          15m
web-655569c6d8-n8nvk   0/1     Terminating   0          15m
web-655569c6d8-n8nvk   0/1     Terminating   0          15m
web-655569c6d8-n8nvk   0/1     Terminating   0          15m
web-7cf4f6bf9f-bbchz   0/1     Pending       0          15s
web-7cf4f6bf9f-bbchz   0/1     ContainerCreating   0          15s
web-7cf4f6bf9f-bbchz   0/1     ContainerCreating   0          18s
web-7cf4f6bf9f-bbchz   0/1     Running             0          63s
web-7cf4f6bf9f-bbchz   1/1     Running             0          75s
web-655569c6d8-vmnj6   1/1     Terminating         0          16m
web-7cf4f6bf9f-rgq9w   0/1     Pending             0          0s
web-7cf4f6bf9f-rgq9w   0/1     Pending             0          0s
web-655569c6d8-vmnj6   1/1     Terminating         0          16m
web-655569c6d8-vmnj6   0/1     Terminating         0          16m
web-655569c6d8-vmnj6   0/1     Terminating         0          16m
web-655569c6d8-vmnj6   0/1     Terminating         0          16m
web-7cf4f6bf9f-kktpq   0/1     Pending             0          79s
web-7cf4f6bf9f-kktpq   0/1     ContainerCreating   0          80s
web-7cf4f6bf9f-kktpq   0/1     ContainerCreating   0          81s
web-7cf4f6bf9f-kktpq   0/1     Running             0          82s
web-7cf4f6bf9f-kktpq   1/1     Running             0          92s
web-655569c6d8-96kmp   1/1     Terminating         0          17m
web-655569c6d8-96kmp   1/1     Terminating         0          17m
web-655569c6d8-96kmp   0/1     Terminating         0          17m
web-655569c6d8-96kmp   0/1     Terminating         0          17m
web-655569c6d8-96kmp   0/1     Terminating         0          17m
web-7cf4f6bf9f-rgq9w   0/1     Pending             0          19s
web-7cf4f6bf9f-rgq9w   0/1     ContainerCreating   0          19s
web-7cf4f6bf9f-rgq9w   0/1     ContainerCreating   0          21s
web-7cf4f6bf9f-rgq9w   0/1     Running             0          59s
web-7cf4f6bf9f-rgq9w   1/1     Running             0          68s

总结
本文解释了kubernetes最易忽略的“滚动更新策略中控制更新速率”的特性：maxUnavailable与maxSurge，希望能对你在发布版本时有所帮助。

Kubectl 滚动更新命令

## 查看历史
kubectl rollout history deployment/anyops-devopsdocker-ui

## 查看具体某一个历史版本信息
kubectl rollout history deployment/anyops-devopsdocker-ui --revision=2

## 回滚上个版本 
kubectl rollout undo deployment/anyops-devopsdocker-ui -n anyops

## 回滚指定版本
kubectl rollout undo deployment/nginx --to-revision=2