技术领域
[0001] 本发明涉及多集群应用灰度升级技术领域,尤其涉及一种多集群应用灰度升级方法、系统及装置。
相关背景技术
[0002] K8s(Kubernetes)是当前广泛使用的容器编排系统,用于自动部署、扩缩容和管理容器化应用程序等。K8s提供了多种标准化工作负载资源,如deployment很适合用来部署管理K8s集群上的无状态应用。同时为减少应用响应用户请求时间,一般会依据不同地域划分,部署多套K8s集群,并借助cdn内容加速等相关技术,提升请求服务质量。
[0003] K8s标准工作负载及其控制器,通过滚动更新模式,对单K8s集群内应用灰度提供了有限支持。但是该模式在升级过程中,需要运维人员使用kubectl命令进行较多的主观操作,这会导致如下问题:
[0004] 1)、极度依赖于运维人员的相关经验,在生产环境,任何误操作都可能引发比较严重的线上事故;
[0005] 2)、运维人员手工操作的灰度模式,会导致灰度升级过程不平滑,应用pod更新速度慢等问题。
[0006] 3)、K8s集群数量较多时,每个集群都需要手工操作,容易导致灰度升级过程操作繁琐,效率低下等问题。
具体实施方式
[0040] 为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合说明书附图对本发明的具体实施方式做详细的说明。
[0041] 在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是本发明还可以采用其他不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本发明内涵的情况下做类似推广,因此本发明不受下面公开的具体实施例的限制。
[0042] 其次,此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例,也不是单独的或选择性的与其他实施例互相排斥的实施例。
[0043] 再其次,本发明结合示意图进行详细描述,在详述本发明实施例时,为便于说明,表示器件结构的剖面图会不依一般比例作局部放大,而且所述示意图只是示例,其在此不应限制本发明保护的范围。此外,在实际制作中应包含长度、宽度及深度的三维空间尺寸。
[0044] 参照图1‑图2,为本发明的一个实施例,提供了一种多集群应用灰度升级方法,其包括以下步骤:
[0045] S1:用户登录容器管理平台,创建并发起应用灰度升级请求,由于需支持多个K8s集群及集群内灰度,因此:创建请求时,需指定所有集群灰度升级分为几个集群间批次,每个集群间批次应至少包含一个集群,另外创建请求时,需指定每个应用所在集群的灰度批次。因此,应用部署在多个kubernetes底座集群上:k8s1,k8s2,……,k8sn;容器管理平台可直接管控上述容器底座集群;灰度请求批次信息:每一个或多个k8s集群作为一个集群间升级批次;并且还要为每个集群设置集群内批次数。
[0046] 例如:应用在k8s集群中设置的灰度批次5,则代表k8s集群内每次升级该应用20%的pod。应用在k8s集群中部署的副本数小于灰度批次也是允许的,资源控制器能正确处理该情形。
[0047] 灰度升级请求还应包括的关键参数有:
[0048] 1)自动部署执行下一批次的间隔时间,监控模块会采集分析该时间间隔内应用负载的各项指标。
[0049] 2)服务质量监控阈值,包括cpu、内存使用率波动,响应耗时波动,异常响应率等。
[0050] S2:容器管理平台将灰度升级请求下发给灰度升级控制模块;
[0051] S3:灰度升级控制模块依据灰度批次信息管控所有的灰度升级过程,按照集群内灰度、集群间灰度的顺序,依次下发应用升级信息到容器管理平台;
[0052] 每个集群内灰度升级时,控制更新的pod数量为:副本总数/集群内批次总数*批次序号(批次序号从1开始),四舍五入。
[0053] S4:容器管理平台根据(灰度升级控制模块下发过来的)应用升级信息,控制K8s底座集群内应用升级、更新。
[0054] 优选的,灰度升级过程,容器管理平台生成新的应用负载版本信息,并根据升级进度,动态更新应用负载不同版本在不同集群的部署分布情况。
[0055] S5:升级期间,由于新版本、旧版本服务共存,因此需要较为精细的流量分发控制。升级前,路由规则控制全部流量转发的旧服务;升级期间每次控制灰度升级pod时,统计新服务pod占比,并改写路由规则设置新服务权重值,此时系统对应百分比的流量会转发到新服务。此外,还可以在路由规则中设置根据用户信息、地域等内容对流量进行转发。
[0056] 为了描述方便,假定服务的pod规格一样、各个pod承担的流量相差无几,如容器管理平台控制10%比例的pod升级新版本成功后,改写路由规则设置新版本服务权重为10,并根据升级进度逐步加大新版本服务权重,逐步切换导入流量到新服务;即使各个pod承担的流量差异较大,监控模块亦能统计感知升级前各个pod的流量情况,从而在灰度升级过程中为新版本服务设定合适的权重值;
[0057] 而且容器管理平台还支持用户手动更改路由规则,设置根据用户信息、地域等内容对流量进行转发
[0058] 在S1中容器管理平台为CaaS平台,CaaS容器管理平台被用来同时管理多个分布在不同区域的容器底座集群。
[0059] 在S2和S3中的灰度升级控制模块,被用来分析控制不同升级批次容器底座集群内、不同容器底座集群间应用升级过程中的pod升级数量、升级顺序等。
[0060] 在S4中的容器底座集群为K8s集群,在S5中的流量分发控制,被用来控制升级过程中,通过流量百分比、用户信息、地域等特征将流量转发到新版本、旧版本服务。
[0061] 本实施例中的监控系统,能实时采集和监控应用服务、容器底座集群本身运行过程的各项指标,并进行度量分析,可视化展示。若在灰度升级过程中,出现监控指标、服务异常等情形,则拦截停止灰度过程并自动回滚应用到上一版本,并向升级请求人、运维人员、管理员推送告警信息。如果一段监控时间窗口内,系统各项指标都正常,容器管理平台向灰度升级控制模块发送调度信号,接收(灰度升级控制模块返回的)下一批次的升级信息,并控制容器底座集群完成该批次升级。直到所有集群内批次、集群间批次灰度升级完成。
[0062] 本发明提供了一种多集群应用灰度升级系统,包括容器管理平台、容器底座集群、用户侧、监控系统,流量分发控制,灰度升级控制平台;
[0063] 容器管理平台既面向用户侧,用于创建应用灰度升级请求;
[0064] 容器管理平台同时管控不同的集群底座集群,根据(灰度升级控制模块下发过来的)应用升级信息,控制K8s底座集群内应用升级、更新;
[0065] 灰度升级控制模块,被用来分析控制不同升级批次容器底座集群内、不同容器底座集群间应用升级过程中的pod升级数量、升级顺序等。
[0066] 容器管理平台同时可以控制升级过程中的流量转发分配,通过改写路由规则将部分百分比随机流量转发到新版本服务,亦可设定根据用户信息、地域特征将特定流量转发到新版本服务。
[0067] 监控系统实时监控灰度升级过程中关键指标,若有明显异常,则自动停止整个升级过程并回滚。
[0068] 本发明提供了一种多集群应用灰度升级装置,包括:
[0069] 存储器、处理器和存储在所述存储器上的计算机程序,上述处理器执行所述计算机程序时实现权利要求中任一项所述的多集群应用灰度升级方法的步骤。
[0070] 应说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。