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)下控制滚动更新的原理,并分析其相应源码实现逻辑。
更多相关文章
- 统住UOS系统更新后软件运行异常,回退系统
- 微信PC版重磅更新!2个困扰多年的大麻烦,这次终于解决了
- 万岳知识付费系统更新内容 v 1.0.6
- 如何在Mac上更新Chrome?
- 618大促,苏宁如何通过citus打造分布式数据库抗住DB高负载
- 时隔三年再更新!绝对良心工具,免费好用
- 最新版 IDEA激活码_idea激活码2021 免费提取_更新于2021-03-17
- HDFS学习:HDFS机架感知与副本放置策略
- Kafka源码系列之topic创建分区分配及leader选举