Kubernetes 灰度/滚动发布 滚动更新速率控制解读 maxUnavailable，maxSurge

利用kubernetes的滚动更新时，可能经常遇到发布“太快不稳定”或“太慢体验差”的情况。本文将介绍kubernetes滚动更新控制速率的特性。

金丝雀发布

---

金丝雀发布这个术语源自20世纪初期，当时英国的煤矿工人在下井采矿之前，会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类表现的更加敏感快速，金丝雀中毒之后，煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前，先发布给部分用户，用真实的客户流量来测试，以保证软件不会出现严重问题，降低发布风险。

在实践中，金丝雀发布一般会先发布到一个小比例的机器，比如 2% 的服务器做流量验证，然后从中快速获得反馈，根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统，通过监控指标，观察金丝雀机器的健康状况。如果金丝雀测试通过，则把剩余的机器全部升级成新版本，否则回滚代码。

优势：
    1、 对用户体验影响较小，在金丝雀发布过程中，只有少量用户会受影响
    2、 发布安全能够得到保障

劣势：
    1、 金丝雀的机器数量比较少, 有一些问题并不能够暴露出来

适用场景：
    1、 监控比较完备且与发布系统集成

灰度/滚动发布

---

灰度发布是金丝雀发布的延伸，是将发布分成不同的阶段/批次，每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再增加用户数量进入下一个阶段，直至扩展到全部用户。

灰度发布可以减小发布风险，是一种零宕机时间的发布策略。它通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本。整个发布过程会持续比较长的时间, 在这段时间内，新旧代码共存，所以在开发过程中，需要考虑版本之间的兼容性，新旧代码共存不能影响功能可用性和用户体验。当新版本代码出现问题时，灰度发布能够比较快的回滚到老版本的代码上。

结合特性开关等技术，灰度发布可以实现更复杂灵活的发布策略。

优势：
    1、 用户体验影响比较小, 不需要停机发布
    2、 能够控制发布风险

劣势：
    1、 发布时间会比较长
    2、 需要复杂的发布系统和负载均衡器
    3、 需要考虑新旧版本共存时的兼容性

适用场景：
    1、 适合可用性较高的生产环境发

含义

---

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

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

取值范围

---

数值
1. maxUnavailable: [0, 副本数]
2. maxSurge: [0, 副本数]
注意：两者不能同时为0。

比例
1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
注意：两者不能同时为0。

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

自定义策略
Deployment controller调整replicaset数量

(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)

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

8 <= 线上实际Ready副本数 <= 12

这样，更新过程中，线上能够正常提供服务的pod数总会保持在这个区间内。

比如：
maxSurge: 1 表示滚动升级时会先启动1个pod
maxUnavailable: 1 表示滚动升级时允许的最大Unavailable的pod个数
由于replicas为3,则整个升级,pod个数在3-1 ~ 3+1个之间
 
比如：
maxSurge: 1 表示滚动升级时会先启动1个pod
maxUnavailable: 50% 表示滚动升级时允许的最大Unavailable的pod个数
由于replicas为3,则整个升级,pod个数在3*50% ~ 3+1个之间，也就是3*50%=1.5，maxUnavailable向下取整，就是1，所以1~4个之间

现象（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