本篇文章为你整理了【原创】k8s 微服务滚动发布（服务持续可用）实践笔记（k8s部署微服务案例spring）的详细内容，包含有k8s微服务架构图 k8s部署微服务案例spring k8s微服务之间如何访问 k8s docker 微服务 【原创】k8s 微服务滚动发布（服务持续可用）实践笔记，希望能帮助你了解 【原创】k8s 微服务滚动发布（服务持续可用）实践笔记。

　　 使用阿里云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脚本实现

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

　　代码外层逻辑如下：bsf-eurekaStatusFilter

　　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个服务变成2个服务吞吐量降低1/3，中间服务稳定没有异常！

　　压测工具报告如图所示：

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

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

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

　　 待实践。

　　 此为k8s滚动发布实践记录，目前已初步实现滚动发布效果。细节仍然需要检验，勤做笔记，以待备忘（帮运维打工的日子）！！！

　　by 车江毅

　　2022-10-20

　　
开源是一种态度，分享是一种精神，学习仍需坚持，进步仍需努力，.net生态圈因你我更加美好。

　　以上就是【原创】k8s 微服务滚动发布（服务持续可用）实践笔记（k8s部署微服务案例spring）的详细内容，想要了解更多 【原创】k8s 微服务滚动发布（服务持续可用）实践笔记的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。