一种在Kubernetes系统中实施蓝绿发布的系统

本发明涉及计算机，尤其涉及一种在kubernetes系统中实施蓝绿发布的系统。

背景技术：

1、在微服务和云原生应用日益普及的背景下，如何安全、高效地发布新版本成为了一个重要的挑战。蓝绿发布作为一种成熟的发布策略，能够减少了系统升级时用户访问中断的时间，提高系统的可用性和稳定性。现有技术中，在kubernetes系统中实现蓝绿发布时，通常需要创建额外的工作负载(比如flagger等工具)，这不仅会增加系统的资源负担，也给部署流程复杂度挑战，增加了运维开销。另一方面，argo rollouts等工具使用自定义的工作负载支持蓝绿发布，但由于发布策略与工作负载紧密耦合，用户在无法使用kubernetes原生工作负载(如deployment)，必须迁移负载，导致了用户学习成本和发布流程的不透明性。

技术实现思路

1、为至少一定程度上解决现有技术中存在的技术问题之一，本发明的目的在于提供一种在kubernetes系统中实施蓝绿发布的系统。

2、本发明所采用的技术方案是：

3、一种在kubernetes系统中实施蓝绿发布的系统，包括：

4、蓝绿发布自定义资源；

5、工作负载的webhook模块，用于监测新版本发布，并为工作负载进行蓝绿发布做前置处理；

6、自定义资源控制器，用于根据蓝绿发布自定义资源，对相应的工作负载执行发布控制逻辑，以达到期望的蓝绿发布行为；

7、其中，当webhook模块监测到发布新版本时，检查本次发布是否应该被允许，如果允许，则将发布新版本置于短暂的暂停状态，以便之后自定义资源控制器进行发布管理。

8、进一步地，所述蓝绿发布自定义资源，包括：

9、自定义资源定义(rollout crd)，所述自定义资源定义旨在于通过kubernetes系统的api服务器(api server)注册新的资源类型，即rollout资源，以此来扩展kubernetes的功能，贯彻蓝绿发布策略；

10、自定义资源(rollout cr)，依托于自定义资源定义，用户能够创建名为rollout的自定义资源的实例，该实例允许用户详细配置蓝绿发布过程；

11、自定义资源的webhook，用于在资源的创建操作、更新操作发生时，进行配置的合法性审查以及防止不当修改，以确保发布策略的准确性与系统的稳定性。

12、进一步地，所述工作负载的webhook模块的工作方式具体如下：

13、a1、检测工作负载是否有新版本发布，若发现新版本发布，执行下一步骤；

14、a2、检查rollout资源是否存在，判断是否应该进行蓝绿发布，若是，则执行下一步骤，若否，本次发布不采用蓝绿策略，返回步骤a1；

15、a3、保存工作负载的部分信息到注释；这一步骤的目的是，蓝绿发布过程中会对工作负载的部分字段进行更新，保存原本的信息以便发布完成后恢复原本的配置，保证蓝绿发布前后工作负载的一致性；

16、a4、暂停工作负载；这一步骤的目的是，防止工作负载的原生控制器的逻辑对蓝绿发布造成干扰；在rollout的控制器开始执行蓝绿发布逻辑后，工作负载会从暂停状态中恢复；

17、a5、webhook工作结束，之后蓝绿发布的过程由自定义资源控制器负责。

18、进一步地，所述自定义资源控制器包括分批发布模块、流量切换模块、度量分析模块和回滚模块；

19、所述分批发布模块用于分批发布新版本的pod；

20、所述流量切换模块用于实现蓝绿发布过程中流量的分批切换，以及保障切换过程中流量的无损；

21、所述度量分析模块用于检验发布的新版本是否达到了预设的性能和稳定性标准，以此来确定发布过程是否可以继续进行或者应该被终止；

22、所述回滚模块用于检测到版本更新不满足预期时，将应用状态回退至上一个稳定版本，以确保业务的连续性和服务的稳定性。

23、进一步地，所述分批发布模块的工作方式具体如下：

24、b1、配置工作负载的minreadyseconds为无穷大，配置maxunavailale为0，并且将工作负载从暂停状态中恢复；

25、b2、根据rollout资源，配置当前批次的maxsurge；

26、b3、判断新版本的pod是否都处于就绪状态，若是，继续判断度量分析模块是否允许进入下一阶段，若否，判定新版本pods创建失败，此次发布被标记为失败，之后调用回滚模块重置本次发布；

27、b4、根据rollout资源，重复执行步骤b2-b3，直到maxsurge配置为100％；

28、b5、发布完成，从工作负载的注释中恢复其原本的配置，包括minreadyseconds，maxunavailale，maxsurge；稳定版本将被缩容，将新版本作为新的稳定版本。

29、进一步地，所述流量切换模块的工作方式具体如下：

30、c1、模块进行初始化工作；

31、c2、流量逐步切换，根据当前批次配置的路由策略，动态更新网络配置对象的路由策略，所述路由策略包括基于权重，请求头和cookie；

32、c3、判断度量分析模块是否允许进入下一阶段，若是则继续执行步骤c4；若否，此次发布被标记为失败，之后会调用回滚模块重置本次发布；

33、c4、发布完成，模块进行收尾工作。

34、进一步地，所述步骤c1，包括：

35、1)检查所需service资源以及网络配置资源存在且配置正确；

36、2)更新网络配置资源，保证全部流量路由到稳定版本；

37、3)取决于不同网络配置资源，配置service对象，使它只选中旧版本pods，或者使它只选中新版本pods。

38、进一步地，所述步骤c4，包括：

39、1)更新网络配置资源，确保全部流量路由到新版本；

40、2)缩容稳定版本；

41、3)复原service资源；

42、4)复原网络配置资源。

43、进一步地，所述度量分析模块的工作方式具体如下：

44、d1、初始化度量分析环境，工作负载在进入度量分析阶段前，需要确保所有相关监控和度量工具都处于活动状态，并且能够正常捕获和反馈数据；

45、d2、进行实时监控和度量，系统将根据预设的metrics指标，实时收集数据，这些数据将成为后面步骤的决策依据；

46、d3、根据rollout资源中定义的成功条件和失败条件，评估收集到的metrics数据；

47、d4、确定是否满足进入下一发布阶段的条件，如果当前步骤的分析结果满足用户配置的策略，则度量分析模块会允许更新进入下一个发布批次；如果不符合，则触发回滚机制；

48、d5、记录和可视化度量分析结果。

49、进一步地，所述回滚模块的工作方式具体如下：

50、e1、判定回滚触发条件：在度量分析模块决定当前新版本不满足发布标准，或是用户主动终止发布流程时，回滚模块被激活并准备执行回滚任务；

51、e2、执行分批回滚策略：按照rollout资源所配置的批次，系统将逐步将流量从新版本导回到稳定版本，此过程中不涉及对新旧版本的pods数量调整，仅针对流量进行操作，以期实现迅速的服务质量恢复，同时减少突然的流量切换产生的网络波动；

52、e3、完成流量切换与状态检查：在所有流量成功切回稳定版本后，用户能够选择继续观察应用状态以排查问题，或立即进行全局回滚以缩容有问题的新版本；

53、e4、执行全局回滚：用户通过重新部署稳定版本的工作负载来触发全局回滚，系统检测到该操作后，将启动全局回滚流程，全局回滚不会按照rollout资源所配置的批次，而是回滚所有与新版本有关的改动，包括流量路由和工作负载的缩容；

54、e5、执行其它清理与恢复：完成回滚操作后，系统将清理所有与发布新版本相关的资源和配置，包括相应的路由规则以及相关的监控设置，确保应用资源和配置的准确性与整洁性，避免潜在的配置混乱和资源浪费。

55、本发明的有益效果是：本发明以旁路式的方式对目标工作负载进行蓝绿发布，发布前后不会变更工作负载的元信息；不需要创建额外的工作负载，简化了发布过程的管理，且支持对存量工作负载进行。另外，本发明还支持流量秒级切换，版本快速回滚，以及可选的多批发布，连续发布等策略，降低了发布新版本所带来的业务风险。