基于灰度发布的容器应用发布方法以及管理平台

摘要

本发明公开了一种基于灰度发布的容器应用发布方法以及管理平台，该方法包括：多批发布的步骤，其中，多批发布中的第一批发布包括：新启动的deployment配置第一批发布的第一副本数目并弹出具有第一副本数目的第一批副本，当新弹出的第一pod的状态准备好后，将第一百分比的流量切换到第一pod；多批发布中的剩余的每个批发布中的包括：新启动的deployment配置与每个批发布相应的第二副本数目，弹出具有第二副本数目的第二批副本，当新弹出的第二pod的状态准备好后，将第二百分比的流量切换到第二pod，并且删除原deployment的与第二副本数目相同数量的原pod，同时摘除原pod上的流量。通过上述技术方案，本发明做到生产应用稳定升级发布。

说明书

技术领域

本发明涉及互联网技术领域，具体来说，涉及一种基于灰度发布的容器应用发布方法以及管理平台。

背景技术

支付作为互联网各行各业发展的基础支撑，目前对支付的高可用要求变得越来越高，支付不可以用的情况几乎很少出现。作为一家提供水电煤的第三方支付公司，对支付场景的要求更是非常严苛，业务需要在任何环境下24小时不间断运行，并且数据一笔不能丢弃，不能错乱。所以应用的每一次发布升级都要特别谨慎，不能有任何数据丢失，但是，kubernetes(一种用于管理云平台中多个主机上的容器化的应用)原生的rolling-update(滚动升级)滚动pod(可以创建和部署的最小也是最简的单位，pod中封装着应用的容器，有的情况下是好几个容器)升级策略并不能满足公司需求，一旦升级有问题，影响面比较大，即使快速回滚，但是全部用户也是能感知支付故障，严重影响用户体验。

目前kubernetes容器平台使用的发布策略是kubernetes原生的rolling-update升级策略，通过同一个deployment(创建和管理pod的工具)内的pod数目滚动升级，虽然可以做到平滑升级，但是无法精准控制升级的pod数目以及接入的流量，一旦升级就是全部升级，而且是全流量接入。如果全部升级完毕，验证有问题，一段时间支付系统不可以使用，就会引入生产故障，这是不被允许的。

虽然使用istio(一个开源项目，能够为微服务架构提供流量管理机制)可以配置应用不同版本的流量接入比例，但是无法使用公司原有的服务发现以及注册中心，而且控制精度也无法达到公司需求。

发明内容

针对相关技术中的上述问题，本发明提出一种基于灰度发布的容器应用发布方法以及管理平台，能够避免同一个deployment内pod的滚动升级一旦升级就是全部升级，而且是全流量接入。

本发明的技术方案是这样实现的：

根据本发明的一个方面，提供了一种基于灰度发布的容器应用发布方法，该方法包括多批发布的步骤。其中，多批发布中的第一批发布包括：新启动的deployment配置第一批发布的第一副本数目并弹出具有第一副本数目的第一批副本，当新弹出的第一pod的状态准备好后，将第一百分比的流量切换到第一pod；

多批发布中的剩余的每个批发布中的包括：新启动的deployment配置与每个批发布相应的第二副本数目，弹出具有第二副本数目的第二批副本，当新弹出的第二pod的状态准备好后，将第二百分比的流量切换到第二pod，并且删除原deployment的与第二副本数目相同数量的原pod，同时摘除原pod上的流量。

根据本发明的实施例，在第一批发布中，只有新启动的deployment弹出pod，原deployment不进行缩减。

根据本发明的实施例，在剩余的每个批发布中，新启动的deployment弹出k个副本，原deployment缩减k个副本，其中，k为正整数，新启动的deployment的pod总数大于等于原deployment的pod总数。

根据本发明的实施例，对于剩余的每个批发布，相应的第二副本数目和第二百分比的流量可以分别不同。

根据本发明的实施例，第二副本数目越多，切换的第二百分比的流量越小。

根据本发明的实施例，在第一批发布中，当新弹出的第一pod的状态未准备好时，进行发布重试；在剩余的每个批发布中，当新弹出的第二pod的状态未准备好时，进行发布重试。

根据本发明的实施例，容器应用发布方法还包括：确定多批发布的批次数n以符合以下公式：2

根据本发明的实施例，灰度发布是属于一个分区内部的灰度分布。

根据本发明的实施例，通过mesh来切换第一百分比的流量和第二百分比的流量。

根据本发明的另一方面，提供了一种基于灰度发布的容器应用发布管理平台，包括用于多批发布的依次连接的多个发布模块。其中，多个发布模块中的第一发布模块用于：新启动deployment，新启动的deployment配置第一批发布的第一副本数目并弹出具有第一副本数目的第一批副本，当新弹出的第一pod的状态准备好后，将第一百分比的流量切换到第一pod；

多个发布模块中的剩余的每个发布模块用于：弹出具有与每个批发布相应的第二副本数目的第二批副本，其中，新启动的deployment配置第二副本数目，当新弹出的第二pod的状态准备好后，将第二百分比的流量切换到第二pod，并且删除原deployment的与第二副本数目相同数量的原pod，同时摘除原pod上的流量。

本发明通过批次算法可以很好的兼顾业务流量，又可以做到灰度批次不会太多，实践验证，满足各种业务场景，和常规的rolling-update升级相比，虽然，灰度算法多了第一批的pod资源，但是总体资源和原来相比基本没有差别，并且可以很好的控制发布的步骤，发布流量的切换时机以及切换比例，新版本发布有问题，不会把故障引入生产，可以做到业务升级，客户真正的无感，出现故障也可以快速回滚。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的容器应用发布管理平台及其应用发布过程的示意图；

图2是根据本发明实施例的容器应用发布方法的第一批发布的过程示意图；

图3是根据本发明实施例的容器应用发布方法的第二批发布的过程示意图；

图4是根据本发明实施例的容器应用发布方法的第三批发布的过程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

根据本发明的实施例，提供了一种基于灰度发布的容器应用发布方法。本发明的方法包括多批发布的步骤。为了便于说明，以4副本的应用发布为例来说明和展示本发明发布的过程。

本发明的容器应用发布方法可以首先进行步骤S101，在步骤S101处，配置发布模板，选择灰度发布模式，如图1所示。

然后进行到步骤S102，模板提交审核，应用负责人审核通过，发布模板可以发布应用。

在该步骤S102处，可以首先确定灰度发布批次。在一些实施例中，可以根据发布批次n的计算公式：2

其次，配置发布模板，审批发布模板；

最后，按照既定批次发布应用。

发布提交发布确认后，进入发布页面，开始第一批发布的步骤S103。图2示出了图1中的步骤S103处的第一批发布的过程示意图。其中，deployment-A表示原deployment，deployment-B表示新启动的deployment。如图2所示，新启动的deployment-B会根据模板配置第一批的副本数目，弹出1副本，新弹出的pod状态ready(准备好)后，mesh网络切换一定百分比(例如10％)的流量到v2版本的新pod。如果新弹出的pod状态一直为not ready(未准备好)，则可以进行发布重试。如果业务验证流量没有问题，则第一批发布确认，然后进入第二批发布的步骤S104(图1)。如果业务验证有问题，可以进行发布回滚；

图3示出了图1中的步骤S104处的第二批发布的过程示意图。如图3所示，开始第二批发布，deployment-B会根据模板配置第二批的副本数目，弹出2副本，新弹出的pod状态ready后，mesh切换一定百分比(例如50％)的流量到v2版本的新pod，删除原deployment-A的两个pod，mesh同时会摘除原两个pod上面的流量，如果新弹出的pod状态一直为notready，则可以进行发布重试。如果业务验证流量没有问题，则第二批发布确认，进入第三批发布的步骤S105(图1)，如果业务验证有问题，可以进行发布回滚。

图4示出了图1中的步骤S105处的第三批发布的过程示意图。如图4所示，开始第三批发布，deployment-B会根据模板配置第三批的副本数目，弹出1副本，mesh负责把业务流量的100％接入新的四个pod上，删除原deployment-A的一个pod，mesh同时会摘除该pod上面的流量。如果新弹出的pod状态一直为not ready，则可以进行发布重试。如果业务验证流量没有问题，则进行第三批发布确认，同时删除原deployment-A，摘除原deployment-A上的流量。如果上面业务验证有问题，则可以进行发布回滚，一键回滚到原deployment-A。

然后，方法可以进行到发布单结束的步骤，无法再回滚和重试。

综上所述，本发明提供了一种基于灰度发布的容器应用发布方法，该方法包括多批发布的步骤。其中，多批发布中的第一批发布包括：新启动的deployment配置第一批发布的第一副本数目并弹出具有第一副本数目的第一批副本，当新弹出的第一pod的状态准备好后，将第一百分比的流量切换到第一pod。多批发布中的剩余的每个批发布中的包括：新启动的deployment配置与每个批发布相应的第二副本数目，弹出具有第二副本数目的第二批副本，当新弹出的第二pod的状态准备好后，将第二百分比的流量切换到第二pod，并且删除原deployment的与第二副本数目相同数量的原pod，同时摘除原pod上的流量。

本发明的上述技术方案通过新启动的deployment来实现应用的灰度发布，新启动的deployment弹出几个pod状态ready后，流量切换成功，原deployment才摘除流量，缩减几个pod，，为了防止业务验证过程中，出现原有pod数目减少引发无法承载原有流量，第一批灰度发布不进行pod缩减，以保证业务发布期间的高可用，同时使用批次计算公式，可以快速确定合适的发布批次以及每批的发布数目，mesh控制业务流量的切换百分比，不单纯的依靠pod数目进行固定流量的切换，做到发布升级过程中，业务流量的精细化控制，有问题可以快速回滚，真正做到生产故障零泄露。

根据本发明的实施例，在第一批发布中，只有新启动的deployment弹出pod，而原deployment不进行缩减。

根据本发明的实施例，在除第一批发布之外的剩余的每个批发布中，新启动的deployment弹出k个副本，原deployment缩减k个副本，k为正整数。新启动的deployment的pod总数大于等于原deployment的pod总数。

对于除第一批发布之外的剩余的每个批发布，相应的第二副本数目和第二百分比的流量可以分别不同。例如，上述第二批和第三批发布中，副本数目分别为2和1，流量的百分比分别为50％和100％。此外，流量切换百分比可以自行调整，副本数和流量切换百分比没有绝对对应关系。副本数目越多，流量切换百分比越小。

根据本发明的实施例，如图2至图4所示，灰度发布是属于一个分区内部的灰度分布。也就是说，不可以跨分区的进行灰度发布。

在另一实施例中，本发明的方法包括：按照既定灰度分批算法公式、确定灰度发布的批次、配置应用发布模板；使用配置模板开始灰度发布，获取灰度第一批发布的pod副本数1，新启动的deployment-B弹出1个pod，mesh接入指定的5％的到新pod中，确认5％的流量到新pod上，业务验证，验证通过，第一批发布确认，进入第二批发布；获取第二批副本数，新启动的deployment-B弹出k个副本，mesh会接入指定的50％的到新pod中，原deployment-A缩减k副本，mesh摘除缩减pod上的流量，进行业务验证，验证通过，进行第二批次发布确认，进入下一批发布。通过上述技术方案，本发明做到生产应用稳定升级发布。

根据本发明的另一个方面，还提供了一种基于灰度发布的容器应用发布管理平台，用于执行本发明的容器应用发布方法。容器应用发布管理平台包括用于多批发布的依次连接的多个发布模块。其中，多个发布模块中的第一发布模块用于进行上述第一批发布：新启动deployment，新启动的deployment配置第一批发布的第一副本数目并弹出具有第一副本数目的第一批副本，当新弹出的第一pod的状态准备好后，将第一百分比的流量切换到第一pod；

多个发布模块中的剩余的每个发布模块用于进行除第一批发布之外的剩余的每个批发布：弹出具有与每个批发布相应的第二副本数目的第二批副本，其中，新启动的deployment配置第二副本数目，当新弹出的第二pod的状态准备好后，将第二百分比的流量切换到第二pod，并且删除原deployment的与第二副本数目相同数量的原pod，同时摘除原pod上的流量。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。