写点什么

【原创】k8s 微服务滚动发布(服务持续可用)实践笔记

作者:车江毅
  • 2022-10-20
    浙江
  • 本文字数:1742 字

    阅读完需:约 1 分钟

【原创】k8s 微服务滚动发布(服务持续可用)实践笔记

背景

     对于业务和产品来讲,随时都有紧急小版本功能上线,对于研发人员来讲,线上如果有一些紧急的 bug,都需要随时发版修正;而对于产品使用用户来讲,任何的功能和版本发布,要尽可能对用户无感知。

方案

  • 灰度发布,自动小批量流量切换。

  • 产品层面要切分小版本,研发设计细节上要向上兼容(诸如接口层面)。

  • 服务发布要实现滚动发布,发布异常要自动回滚,中间不断服。

     其中一部分是工具实现,一部分是项目管理实现,最后一部分是运维层面及架构层面要做的适配和兼容。

k8s 滚动发布方案:

1. 历史实践方案- rancher

k8s 采用 rancher 部署。

1)采用 rancher cli 客户端工具登陆 rancher,获取发布日志,扫描启动日志“成功标记位”,超过扫描周期,判定为发布失败,通知 rancher 进行回滚。

2)应用进程关闭前自动通知网关注销节点,通知 eureka 下线,关闭流量。如果关闭进程超时,则强杀!

实践心得:正常发布情况下基本可用,回滚情况下基本可用;如果出现超时,可能会出现流量少量时间异常。因为靠超时保证稳定性,所以有时发布周期较长。

 

2. 现有实践方案 - 阿里云 k8s

k8s 采用阿里云部署。

1) 采用 kubectl 工具,yml 文件部署。

2)yml 定义 readinessProbe 就绪探针实现优雅上线,preStop 关闭前事件实现优雅下线。

3)采用发布“部署结果”状态检测,如果发布超过时间(超时),则立即通知回滚上一个版本。

 

yml 定义文件如图所示:



一. 优雅上线的 http 状态请求实现

1. 基于bsf框架底层(业务统一使用的底层基础架构),内部实现基于 springboot 的生命周期,识别应用进程所处的“启动完成”,“关闭事件”,从而识别应用是否已完全启动成功以及下线后撤销就绪状态。同样业务也可以订阅生命周期事件并加入自定义逻辑,从而保证      业务特殊场景的初始化完成才“处于就绪状态”,开始接收业务流量。

2. 代码外层逻辑如下:bsf-statusFilter

java-stop.sh 文件如图所示:

二. 优雅下线的 shell 脚本实现

  1. 基于bsf框架底层(业务统一使用的底层基础架构),内部实现对于 eureka 服务的状态修改及自动下线,从而实现应用进程关闭时通知 eureka 注销自身应用服务下线。同样也会通知当前生命周期处于 stopping 状态,从而引发“就绪探针”的就绪状态失效。

  2. 代码外层逻辑如下:bsf-eurekaStatusFilter

  3. podstopsleeptime 时间为 eureka 注销后,默认 eureka 下线真正生效时间(因为 eureka 客户端可能有缓存),需要看 eureka 情况调整。比如 eureka 需要调优几个参数,其中涉及到 eureka 消费者端的订阅实例刷新的周期,eureka 实例的 eureka 服务端缓存时间。理论上手工下线后 5 秒生效,如果手工下线失效,保守时间应该是消费者端实例刷新时间+eureka 服务端实例缓存时间=生效时间;在 eureka 客户端配置如图调优后,考虑设置为 10 秒。

eureka 调优参考如下:

三. 发布异常检测逻辑实现

    核心实现基于两个关键 k8s 命令:

1. kubectl rollout status deploy {服务名} -n {namespace}

 定期检查当前发布状态,如果长时间没有发布成功,则通知回滚。(风险:假如此时有人工控制台或命令介入操作,会干预正常自动化发版)

2. kubectl -n {namespace} rollout undo deploy {服务名}

 通知服务回滚上一个版本。(风险:上一个版本可能失败,或者出现异常?不一定是程序问题,可能数据库出现异常等等?所以一般人工介入确认一下比较好。同时发出飞书通知提醒!)

发布异常检测处理逻辑如图:



四. 验证滚动发布是否有效

1. 外层网关验证

 采用全自动化全链路压测工具(自动流量录制,自动生成报告,压测效能提升10倍),设置自动化压测任务,进行长时间不间断扫描!验证发布/回滚时,流量验证是否出现中断!

    结论: 配置 2 个线程持续扫描空接口的情况下,没有出现 http 链接异常,在滚动发布的时候出现流量的波谷,但是服务没有中断。

压测工具报告如图所示:

 

2. 内部服务调用验证:

 基于 eureka 情况下,内部 rpc 调用是否有效?尚未检验。

3. 多种异常情况下的发布是否正常回滚?

 诸如常见的编译错误或者系统配置一样导致打包问题,会不会影响线上(应该是终止的)。多种服务启动错误能不能自动回滚?(有些场景下应该还是不能回滚的)

4. 内部大范围项目推广验证!!!

 待实践。

 

总结:

  此为 k8s 滚动发布实践记录,目前已初步实现滚动发布效果。细节仍然需要检验,勤做笔记,以待备忘!!!

 

by 车江毅

2022-10-20

发布于: 刚刚阅读数: 4
用户头像

车江毅

关注

某公司技术vp 2020-11-10 加入

13+互联网技术从业经历,10年左右技术架构,10年左右技术管理,获得微软mvp,开源社区作者,曾就职支付宝,担任永辉彩食鲜首席架构师

评论

发布
暂无评论
【原创】k8s 微服务滚动发布(服务持续可用)实践笔记_k8s_车江毅_InfoQ写作社区