Kubernetes滚动更新速率控制解读

 云平台容器团队 360云计算 

女主宣言

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

PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！

1

含义

服务在滚动更新时，deployment控制器的目的是：给旧版本(old_rs)副本数减小至0、给新版本(new_rs)副本数量增至指望值(replicas)。你们在使用时，一般容易忽视控制速率的特性，如下是kubernetes提供的两个参数：

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

2

取值范围

数值

1. maxUnavailable: [0, 副本数]maxSurge: [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。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。

3

自定义策略

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

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

举例：若是指望副本数是10，指望能有至少80%数量的副本能稳定工做，因此:maxUnavailable = 2，maxSurge = 2 (可自定义，建议与maxUnavailable保持一致)

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

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

4

总结

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

后续文章会带来deployment controller在多版本(replicaset)下控制滚动更新的原理，并分析其相应源码实现逻辑。