一种基于kubernetes的微服务无感知上下线方法技术

本申请公开了一种基于kubernetes的微服务无感知上下线方法，包括：在kubernetes中将应用代码打包成docker镜像，并在deployment中引用；检测kubernetes中容器是否就绪；若所述容器未就绪，则继续检测所述容器是否就绪，直至所述容器就绪为止；在kubernetes中，在容器停止前，调用微服务方法，将所述容器从服务注册平台下线；使用Nacos处理所述容器停止前发送的请求，完成上下线切换。本方案，可满足微服务无感知上下线。务无感知上下线。务无感知上下线。

【技术实现步骤摘要】
一种基于kubernetes的微服务无感知上下线方法


[0001]本申请涉及软件开发
，具体而言，涉及一种基于kubernetes的微服务无感知上下线方法。

技术介绍

[0002]应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。蓝绿发布分析如下：项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。特点：如果出问题，影响范围较大；发布策略简单；用户无感知，平滑过渡；升级/回滚速度快。缺点：需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；短时间内浪费一定资源成本；基础设施无改动，增大升级稳定性。蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低灰度发布分析如下：灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来特点：保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；用户无感知，平滑过渡。缺点：自动化要求高；部署过程：从LB摘掉灰度服务器，升级成功后再加入LB；少量用户流量到新版本；如果灰度服务器测试成功，升级剩余服务器；灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。滚动发布分析如下：滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。根据现有的更新升级方式，现有方式无法满足微服务无感知上下线，因此专利技术人提出一种基于kubernetes的微服务无感知上下线方法。

技术实现思路

[0003]本申请的主要目的在于提供一种基于kubernetes的微服务无感知上下线方法，以改善相关技术中的问题。为了实现上述目的，本申请提供了一种基于kubernetes的微服务无感知上下线方法，包括：
在kubernetes中将应用代码打包成docker镜像，并在deployment中引用；检测kubernetes中容器是否就绪；若所述容器未就绪，则继续检测所述容器是否就绪，直至所述容器就绪为止；在kubernetes中，在容器停止前，调用微服务方法，将所述容器从服务注册平台下线；使用Nacos处理所述容器停止前发送的请求，完成上下线切换。在本申请的一种实施例中，在kubernetes中将应用代码打包成docker镜像的方法包括：输入预先设置的文档库构建方式；通过所述文档库构建方式，将所述应用代码打包成docker镜像。在本申请的一种实施例中，所述检测kubernetes中容器是否就绪的方法包括：向所述容器中输入测试命令；在容器内执行所述测试命令，若所述测试命令执行成功则确定所述容器就绪；若所述测试命令执行不成功，则所述容器未就绪。在本申请的一种实施例中，所述检测kubernetes中容器是否就绪的方法包括：对所述容器进行初始化处理；在所述容器被初始化处理成功的第一数量秒后开始第一次就绪探测；如果容器未就绪，则每隔第二数量秒的时间进行周期性的就绪探测。在本申请的一种实施例中，在所述容器被初始化处理成功的第一数量秒后开始第一次就绪探测的方法包括：检测所述容器是否被初始化成功，若初始化成功，则每隔第三数量秒后再次检测所述容器是否被初始化成功；若检测到所述容器初始化失败，则继续对所述容器进行初始化处理，直至检测到所述容器被初始化成功后，执行下一步骤。在本申请的一种实施例中，所述第一数量秒设置为180秒。在本申请的一种实施例中，所述在容器内执行预设的测试命令，若所述测试命令执行成功则确定容器就绪的方法包括：检测测试命令退出状态码；若所述测试命令退出状态码为0，则所述容器准备就绪；若所述测试命令退出状态码不为0，则所述容器未准备就绪。在本申请的一种实施例中，在容器停止前，调用微服务方法，将所述容器从服务注册平台下线的方法包括：检测所述容器是否停止，若未停止，调用Lifecycle；使用Lifecycle将所述容器从服务注册平台下线，并通知其它系统。在本申请的一种实施例中，使用Nacos处理所述容器停止前发送的请求的方法包括：检测并识别所述容器停止前发送的请求；通过Nacos将即将停止的容器下线处理；调用新启动的容器，使所述新启动的容器可正常使用。
在本申请的一种实施例中，调用新启动的容器，使所述新启动的容器可正常使用的方法包括：将新启动的容器IP权重置提高，并设置为暂时不调用状态；对新启动的容器进行健康检查，检查不合格，则修改新启动的容器；新启动的容器被检测合格后，将新启动的容器设置为可调用状态。与现有技术相比，本申请的有益效果是：将Nacos内部心跳设置为30秒，所以kubernetes自带的滚动更新不足以实现真正意义上的无感知更新升级，采用通过在容器停止前，调用微服务方法，将所述容器从服务注册平台下线，在使用Nacos处理所述容器停止前发送的请求，完成上下线切换，即可实现真正意义上的微服务无感知更新升级，真正提高用户体验度。
附图说明
[0004]图1为根据本申请实施例提供的基于kubernetes的微服务无感知上下线方法的流程示意图；图2为根据本申请实施例提供的在kubernetes中将应用代码打包成docker镜像的方法的流程示意图；图3为为根据本申请实施例提供的检测kubernetes中容器是否就绪的方法的流程示意图；图4为根据本申请实施例提供的所述检测kubernetes中容器是否就绪的方法的流程示意图；图5为根据本申请实施例提供的在所述容器被初始化处理成功的第一数量秒后开始第一次就绪探测的方法的流程示意图；图6为根据本申请实施例提供的在容器内执行所述测试命令，若所述测试命令执行成功则确定所述容器就绪所述在容器内执行预设的测试命令，若所述测试命令执行成功则确定容器就绪的方法的流程示意图；图7为根据本申请实施例提供的在容器停止前，调用微服务方法，将所述容器从服务注册平台下线的方法的流程示意图；图8为lifecycle配置具体参数示意图；图9为根据本申请实施例提供的使用Nacos处理所述容器停止前发送的请求的方法的流程示意图；图10为根据本申请实施例提供的调用新启动的容器，使所述新启动的容器可正常使用的方法的流程示意图。
具体实施方式
[0005]为了使本
的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种基于kubernetes的微服务无感知上下线方法，其特征在于，包括：在kubernetes中将应用代码打包成docker镜像，并在deployment中引用；检测kubernetes中容器是否就绪；若所述容器未就绪，则继续检测所述容器是否就绪，直至所述容器就绪为止；在kubernetes中，在容器停止前，调用微服务方法，将所述容器从服务注册平台下线；使用Nacos处理所述容器停止前发送的请求，完成上下线切换。2.如权利要求1所述的一种基于kubernetes的微服务无感知上下线方法，其特征在于，在kubernetes中将应用代码打包成docker镜像的方法包括：输入预先设置的文档库构建方式；通过所述文档库构建方式，将所述应用代码打包成docker镜像。3.如权利要求1所述的一种基于kubernetes的微服务无感知上下线方法，其特征在于，所述检测kubernetes中容器是否就绪的方法包括：向所述容器中输入测试命令；在容器内执行所述测试命令，若所述测试命令执行成功则确定所述容器就绪；若所述测试命令执行不成功，则所述容器未就绪。4.如权利要求3所述的一种基于kubernetes的微服务无感知上下线方法，其特征在于，所述检测kubernetes中容器是否就绪的方法包括：对所述容器进行初始化处理；在所述容器被初始化处理成功的第一数量秒后开始第一次就绪探测；如果容器未就绪，则每隔第二数量秒的时间进行周期性的就绪探测。5.如权利要求4所述的一种基于kubernetes的微服务无感知上下线方法，其特征在于，在所述容器被初始化处理成功的第一数量秒后开始第一次就绪探测的方法包括：检测所述容器是否被初始化成功，若初始化成功，则每隔第三数量秒...

【专利技术属性】
技术研发人员：华张辉，
申请(专利权)人：中教云智数字科技有限公司，
类型：发明
国别省市：