CN115994016A - 基于容器组状态的容器组运维变更方法及系统 - Google Patents

Abstract

本说明书实施例提供基于容器组状态的容器组运维变更方法及系统。响应于触发容器组运维变更声明，驱动容器组进入包括自定义运维变更前置状态的运维变更前置状态，随后前置状态处理器对容器组执行变更前置处理。在完成变更前置处理后，驱动容器组进入运维变更可触发状态，随后容器组运维变更触发器发起容器组运维变更。在完成容器组运维变更后，驱动容器组进入容器组变更状态来启动变更后的容器组，随后驱动变更后的容器组进入运维变更后置状态。在容器组处于运维变更后置状态时，后置状态处理器对变更后的容器组执行变更后置处理。在完成变更后置处理后，驱动变更后的容器组恢复容器组初始状态，从而完成容器组运维变更生命周期。

Description

基于容器组状态的容器组运维变更方法及系统

技术领域

本说明书实施例通常涉及容器技术领域，尤其涉及基于容器组状态的容器组运维变更方法及容器组运维变更系统。

背景技术

随着云计算技术的发展，容器技术(比如，Docker)和基于容器技术的云资源编排系统(比如，Kubernetes)得到广泛的应用，并成为行业标准。在云原生技术中，容器组(例如，Pod)是云资源编排系统的最小调度单元。一个容器组由一个或多个容器(container)组成，并且在容器组上运行应用程序。

在容器云应用实践中，会围绕容器组建立一系列资源，比如，注册流量服务、关联数据存储等。因此在容器组运维变更(如创建、删除、升级)时，周边服务(或周边资源)有可能需要执行一系列自定义操作，比如，在变更前摘网络流量、数据备份等。但在默认的云资源编排系统(比如，Kubernetes)中，负责管理容器组运维变更操作的工作负载(workload)并没有考虑这种情况。容器组运维变更请求一旦提交，就会触发容器组运维变更行为，并且运行在容器组内部的应用程序会停止运行。容器组运维变更结束后，也会立即认为整个运维变更流程结束。在这种情况下，所触发的容器组运维变更操作属于原子操作，不能实现将自定义操作编排进容器组运维变更流程中。这对保证容器组周边资源的完备性(比如，网络流量稳定性、数据使用完整性等)都带来了挑战。

发明内容

本说明书实施例提供基于容器组状态的容器组运维变更方法及容器组运维变更系统。利用该容器组运维变更方法及容器组运维变更系统，可以实现在容器组运维变更时自行编排自定义操作。

根据本说明书实施例的一个方面，提供一种基于容器组状态的容器组运维变更方法，包括：响应于容器组运维变更触发器触发容器组运维变更声明，容器组状态驱动器驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；响应于监测到所述容器组处于所述运维变更前置状态，所述运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置处理；在所有前置状态处理器完成变更前置处理后，所述容器组状态驱动器驱动所述容器组进入运维变更可触发状态；响应于监测到所述容器组处于所述运维变更可触发状态，所述容器组运维变更触发器发起对所述容器组执行容器组运维变更；在完成容器组运维变更后，所述容器组状态驱动器驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组；在所述变更后的容器组启动后，所述容器组状态驱动器驱动所述变更后的容器组进入运维变更后置状态；响应于监测到所述变更后的容器组处于所述运维变更后置状态，所述运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置处理；以及在所有后置状态处理器完成变更后置处理后，所述容器组状态驱动器驱动所述变更后的容器组恢复容器组初始状态。

可选地，在上述方面的一个示例中，所述运维变更前置状态包括用于触发变更前置检查的第一运维变更前置状态和用于触发运维变更准备的第二运维变更前置状态，所述变更前置检查包括基于前置检查规则的容器组变更准入检查，所述前置检查规则至少包括自定义前置检查规则。所述响应于监测到所述容器组处于所述运维变更前置状态，所述运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置处理包括：响应于监测到所述容器组处于所述第一运维变更前置状态，所述第一运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置检查；以及响应于监测到所述变更前置检查通过，所述第二运维变更前置状态所对应的前置状态处理器触发停用所述容器组为周边服务提供的服务。

可选地，在上述方面的一个示例中，所述前置检查规则还可以包括以下规则中的至少一种：基于服务水位的前置检查规则；基于服务资源的前置检查规则；和基于容器组重建校验的前置检查规则。

可选地，在上述方面的一个示例中，所述运维变更后置状态包括用于触发变更后置检查的第一运维变更后置状态和用于触发运维变更完成的第二运维变更后置状态，所述变更后置检查包括基于后置检查规则的容器组变更准出检查，所述后置检查规则至少包括与自定义前置检查规则对应的自定义后置检查规则。响应于监测到所述变更后的容器组处于所述运维变更后置状态，所述运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置处理包括：响应于监测到所述变更后的容器组处于所述第一运维变更后置状态，所述第一运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置检查；以及响应于监测到所述变更后置检查通过，所述第二运维变更前置状态所对应的后置状态处理器触发恢复所述变更后的容器组为周边服务提供服务。

可选地，在上述方面的一个示例中，所述第一运维变更前置状态所对应的前置状态处理器包括RuleSet状态处理器，和/或所述第一运维变更后置状态所对应的后置状态处理器包括RuleSet状态处理器。

可选地，在上述方面的一个示例中，在容器组所提供的服务包括与流量对应的服务时，所述第二运维变更前置状态所对应的前置状态处理器包括用于流量管控的状态处理器，所述第二运维变更后置状态所对应的后置状态处理器包括用于流量管控的状态处理器，以及所述容器组所提供服务的停用和恢复分别通过所述用于流量管控的状态处理器的摘流处理和挂流处理来实现。

可选地，在上述方面的一个示例中，所述容器组为周边服务提供服务的停用通过周边服务注销所述容器组并从所述容器组上删除各自的资源锁来实现，以及所述变更后的容器组为周边服务提供服务的恢复通过周边服务注册所述容器组所对应的服务实例并在所述容器组上挂载各自的资源锁来实现。

可选地，在上述方面的一个示例中，所述容器组的各个状态通过为所述容器组标注对应的状态标记来实现。

可选地，在上述方面的一个示例中，所述容器组运维变更触发器包括多个容器组运维变更触发器，如果一个或多个容器组运维变更触发器的容器组运维变更声明的发送时机在当前容器组运维变更生命周期的所述容器组运维变更完成之前，则所述一个或多个容器组运维变更触发器共享所述当前容器组运维变更生命周期来执行各自的容器组运维变更。

可选地，在上述方面的一个示例中，所述容器组运维变更方法还可以包括：响应于在所述容器组运维变更生命周期中处于所述运维变更前置状态时接收到容器组运维变更取消请求，从当前操作直接跳转到执行所述容器组状态驱动器驱动所述容器组进入容器组变更状态的操作。

根据本说明书的实施例的另一方面，提供一种用于基于容器组状态的容器组运维变更的方法，包括：响应于容器组运维变更触发器触发容器组运维变更声明，驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；在所述运维变更前置状态所对应的所有前置状态处理器完成变更前置处理后，驱动所述容器组进入运维变更可触发状态，所述前置状态处理器响应于监测到所述容器组处于所述运维变更前置状态而对所述容器组执行变更前置处理；在完成所述容器组运维变更触发器所发起的容器组运维变更后，驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组，所述容器组运维变更触发器响应于监测到所述容器组处于所述运维变更可触发状态而发起对所述容器组执行容器组运维变更；在所述变更后的容器组启动后，驱动所述变更后的容器组进入运维变更后置状态；以及在所述运维变更后置状态所对应的所有后置状态处理器完成变更后置处理后，驱动所述变更后的容器组恢复容器组初始状态，所述后置状态处理器响应于监测到所述变更后的容器组处于所述运维变更后置状态而对所述变更后的容器组执行变更后置处理。

根据本说明书的实施例的另一方面，提供一种基于容器组状态的容器组运维变更系统，包括：容器组运维变更触发器，触发容器组运维变更声明，以及响应于监测到所述容器组处于运维变更可触发状态，发起对所述容器组执行容器组运维变更；前置状态处理器，响应于监测到所述容器组处于运维变更前置状态而对所述容器组执行变更前置处理；后置状态处理器，响应于监测到变更后的容器组处运维变更后置状态而对所述变更后的容器组执行变更后置处理；以及容器组状态驱动器，响应于所述容器组运维变更触发器触发容器组运维变更声明，驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；在所述运维变更前置状态所对应的所有前置状态处理器完成变更前置处理后，驱动所述容器组进入运维变更可触发状态；在完成所述容器组运维变更触发器所发起的容器组运维变更后，驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组；在所述变更后的容器组启动后，驱动所述变更后的容器组进入运维变更后置状态；以及在所述运维变更后置状态所述对应的所有后置状态处理器完成变更后置处理后，驱动所述变更后的容器组恢复容器组初始状态。

根据本说明书的实施例提供一种基于容器组状态的容器组运维变更系统，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上所述的基于容器组状态的容器组运维变更方法。

根据本说明书的实施例提供一种用于基于容器组状态的容器组运维变更的装置，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上所述的用于基于容器组状态的容器组运维变更的方法。

根据本说明书的实施例提供一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如上所述的基于容器组状态的容器组运维变更方法或者如上所述的用于基于容器组状态的容器组运维变更的方法。

根据本说明书的实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如上所述的基于容器组状态的容器组运维变更方法或者如上所述的用于基于容器组状态的容器组运维变更的方法。

附图说明

通过参照下面的附图，可以实现对于本说明书内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。

图1示出了容器云技术应用中的用户访问服务的示例流程示意图。

图2示出了容器组运维变更前的流量切换过程的示例流程示意图。

图3示出了根据本说明书的实施例的容器组运维变更生命周期的示例示意图。

图4示出了根据本说明书的实施例的基于容器组状态的容器组运维变更系统的示例框架图。

图5示出了根据本说明书的实施例的基于容器组状态的容器组运维变更方法的示例流程图。

图6示出了根据本说明书的实施例的基于容器组状态的容器组运维变更过程的示例示意图。

图7示出了根据本说明书的实施例的基于计算机系统实现的容器组运维变更系统的示例示意图。

图8示出了根据本说明书的实施例的基于计算机系统实现的容器组状态驱动装置的示例示意图。

具体实施方式

现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

本说明书中使用的流程图示出了根据本说明书中的一些实施例的系统实现的操作。应该清楚地理解，流程图的操作可以不按顺序实现。相反，操作可以以反转顺序或同时实现。此外，可以向流程图添加一个或多个其他操作，和/或可以从流程图中移除一个或多个操作。

容器云是通过Docker技术在集群服务器上部署容器服务实现的云服务产品。容器云以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建、发布和运行分布式应用的平台。在容器云中，容器组为最小调度单元，每个容器组由一个或多个容器组成。例如，Pod是云资源编排系统Kubernetes(k8s)创建或部署的最小单位。一个Pod封装一个或多个容器、存储资源(volume)、一个独立的网络IP以及管理控制容器运行方式的策略选项(比如，如何运行容器的规范)。容器组中的容器具有共享的存储资源和网络资源。

在容器组中运行应用程序来为周边服务提供服务，例如，提供用户访问服务。为了保证高可靠性，一个周边服务通常由多个容器组共同提供服务。图1示出了容器云技术应用中的用户访问服务的示例流程示意图。如图1所示，在用户发起用户访问服务，该访问服务流量会经由某个流量入口流入容器云环境，并被流量负载均衡设备spanner随机导入到多个容器组中的一个容器组，例如，图1中所示的容器组Pod3，由容器组Pod3提供服务。在由容器组Pod3提供服务时，需要围绕容器组Pod3建立一系列资源，比如，注册流量服务、关联数据存储等。如果在容器组Pod3提供用户访问服务期间对容器组Pod3进行容器组运维变更(比如，创建、删除、升级或重启等)，则会导致用户访问服务失败。

为了确保持续提供用户访问服务，需要在对容器组Pod3进行容器组运维变更之前，周边资源需要执行一些自定义操作来将用户访问流量从待变更的容器组Pod3切换到共同提供用户访问服务的其它容器组，比如容器组Pod1和Pod2，由此在对容器组Pod3进行容器组运维变更期间，由容器组Pod1和Pod2来持续提供用户访问服务而不发生用户访问服务中断或失败。周边资源所执行的自定义操作例如可以包括变更前的摘网络流量、数据备份等。

图2示出了容器组运维变更前的流量切换过程的示例流程示意图。如图2所示，在对容器组Pod3进行容器组运维变更时，在容器组运维变更生命周期的变更准备(Prepare)阶段，将用户访问流量从容器组Pod3摘流，并由spanner将该流量导入到共同提供用户访问服务的容器组Pod1和/或Pod2。在将流量导入到共同提供用户访问服务的容器组Pod1和/或容器组Pod2后，对容器组Pod3执行容器组运维变更操作。在这种情况下，在容器组Pod3进行容器组运维变更期间，可以由容器组Pod1或Pod2继续提供用户访问服务，从而不会发生用户访问服务中断或失败。

然而，在云资源编排系统(比如，Kubernetes)的原生解决方案中，由工作负载(Workload)负责管理容器组运维变更操作。工作负载所执行的容器组运维变更操作属于原子操作。运维变更请求一旦提交就会触发容器组变更行为，并且运行在容器组内部的应用程序会收到通知立即停止运行。容器组变更结束后，也会认为整个变更流程结束。在这种原生解决方案中，没有能力在容器组运维变更操作中编排例如上述流量切换的自定义操作。

鉴于上述，本说明书的实施例提供一种基于容器组状态的容器组运维变更方法及容器组运维变更系统。在该容器组运维变更方案中，将容器组运维变更生命周期扩展成容器组初始阶段，变更前置阶段，运维变更阶段以及变更后置阶段。此外，在变更前置阶段和变更后置阶段分别扩展包含用于触发自定义操作的运维变更前置状态以及包含用于触发自定义操作的运维变更后置状态。在一次容器组运维变更过程中，通过容器组运维变更系统中的容器组状态驱动器根据当前容器组状态以及容器组当前状态的处理情况确定是否允许将容器组运维变更生命周期推进到下一个容器组状态，从而推动容器组从服务可用阶段开始顺序经历上述四个阶段，并最终返回到容器组初始阶段。利用上述容器组运维变更方案，通过在容器组运维变更生命周期中扩展加入用于触发自定义操作的运维变更前置状态以及用于触发自定义操作的运维变更后置状态，从而可以在容器组运维变更前后插入必要的前/后置动作，由此保证周边资源的完备性。此外，由于容器组运维变更生命周期由容器组状态驱动器根据当前容器组状态以及容器组当前状态的处理情况推进，从而可以保证容器组变更状态流转的完备性。而且，在上述容器组运维变更方案中，将容器组运维变更操作解耦为由三个相互独立的组件容器组状态驱动器，容器组运维变更触发器以及容器组状态处理器(前置状态处理器/后置状态处理器)三个组件分别执行部分操作，从而使得容器组运维变更操作不再是原子操作，由此可以支持针对容器组运维变更的各种自适应调整。

下面参照附图描述根据本说明书的实施例的基于容器组状态的容器组运维变更方法及容器组运维变更系统。

在进行容器组运维变更方案描述之前，首先介绍根据本说明书的实施例的容器组运维变更生命周期。

图3示出了根据本说明书的实施例的容器组运维变更生命周期的示例示意图。

在图3例示的容器组运维变更生命周期示例中，容器组运维变更生命周期包括容器组初始状态阶段，变更前置处理阶段，运维变更阶段以及变更后置处理阶段。此外，在变更前置处理阶段和变更后置处理阶段还分别包含用于触发自定义操作的运维变更前置阶段以及包含用于触发自定义操作的运维变更后置阶段。例如，如图3所示，在一些实施例中，变更前置处理阶段例如可以包括运维变更前置检查阶段(PreCheck)和变更准备阶段(Preparing)。变更后置处理阶段例如可以包括运维变更后置检查(PostCheck)阶段和变更完成阶段(Completing)。运维变更前置检查阶段和运维变更后置检查阶段可以触发自定义操作。

在容器组初始状态阶段，容器组处于容器组初始状态，例如，ServiceAvailable状态。ServiceAvailable状态是容器组初始状态，每次容器组运维变更完成后都会恢复到该状态。在容器组初始状态阶段，容器组内部的业务进程已经完成启动，并且流量已经完全恢复，可以为周边服务提供正常服务。例如，在容器组初始状态阶段，各周边服务陆续注册容器组对应的服务实例，并将各自的资源锁(例如，Finalizer)都挂载到容器组上。可选地，可以为处于ServiceAvailable状态的容器组打上标记(label)“service-available”。

如图3中所示，在容器组处于容器组运维变更前置状态时，会进入变更前置处理阶段。在变更前置处理阶段，会基于容器组运维变更前置状态触发对应的变更前置处理。容器组运维变更前置状态可以包括运维变更前置检查(PreCheck状态)和运维变更准备(Preparing)状态。PreCheck状态是第一个容器组运维变更前置状态。响应于容器组运维变更生命周期推进到PreCheck状态，会进入运维变更前置检查(PreCheck)阶段。在PreCheck阶段，触发对应的前置状态处理器在容器组运维变更前对容器组执行一系列的变更前置检查。PreCheck状态可以至少包括用户可自定义的运维变更前置状态，该自定义运维变更前置状态用于触发用户的自定义操作。用于执行变更前置检查的前置状态处理器例如可以包括RuleSet状态处理器。

在本说明书中，变更前置检查是针对是否符合容器组变更准入条件的变更准入检查。变更前置检查可以基于前置检查规则执行。所述前置检查规则至少包括自定义前置检查规则，该自定义前置检查规则可以对应于一种自定义运维变更前置状态，以用于执行对应的自定义操作。自定义前置检查规则例如可以包括用户扩展的自定义前置检查规则。比如，用户可以在PreCheck阶段设置自定义规则“将容器组当前在处理的数据做一个临时备份”。相应地，在PostCheck阶段设置对应的自定义规则“进行数据恢复”。如果变更前置检查未通过，则会拒绝继续执行当前容器组运维变更操作。

前置检查规则还可以包括以下规则中的至少一种：基于服务水位的前置检查规则；基于服务资源的前置检查规则；和基于容器组重建校验的前置检查规则。基于服务水位的前置检查规则例如可以包括根据整体服务水位来确定是否允许变更。如图2中所示，如果容器组Pod1挂了，那么当前只有容器组Pod2和容器组Pod3在提供服务，此时整体服务水位太低，如果允许对容器组Pod3进行运维变更，则当前只有容器组Pod2在提供服务。由于原三个Pod的用户请求全集中在一个Pod上，超过实际承载能力，从而影响服务质量。由此，在这种情况下，不允许对容器组Pod3进行运维变更，即，变更前置检查未通过。

基于服务资源的前置检查规则例如可以包括根据服务资源是否足够支持运维变更来确定是否允许容器组运维变更。例如，假设当前容器组运维变更是从2G内存修改为4G内存，然而当前集群服务器(k8s集群)的可用资源不足以额外提供2G内存增量，从而在这种情况下会拒绝容器组运维变更，即，变更前置检查未通过。

基于容器组重建校验的前置检查规则例如可以包括根据容器组所提供服务是否允许容器组重建来确定是否允许容器组运维变更。例如，对于容器组所提供的一些服务，不允许对容器组进行重建。在这种情况下，如果当前容器组运维变更会引起容器组重建，则会拒绝容器组运维变更，即，变更前置检查未通过。

Preparing状态是第二个容器组变更前置状态。响应于容器组运维变更生命周期推进到Preparing状态，会进入运维变更准备(Preparing)阶段。在Preparing阶段，可以触发对应的前置状态处理器在容器组运维变更前执行例如服务停用操作的运维变更准备处理。在一些实施例中，例如可以通过周边服务注销容器组并从容器组上删除各自的资源锁(例如，Finalizer)来实现停用容器组为周边服务所提供的服务。在一些涉及流量访问服务的示例中，响应于容器组运维变更生命周期推进到Preparing状态，可以触发各种流量管控相关的前置状态处理器来完成对应流量的摘流处理，以保证在容器组运维变更时不会影响到用户的访问流量。

要说明的是，Preparing状态也可以包括用于触发用户的自定义操作的自定义变更准备状态。例如，针对有些用户，需要在容器组变更前摘除自己管控的一些流量，比如，函数计算会在一个容器组内运行多个函数，每个函数都有自己单独的流量，因此用户会在Preparing阶段自定义流量控制逻辑来摘除每个函数的流量。

在运维变更阶段，容器组处于运维变更(Upgrading)状态。Upgrading状态也可以称为容器组运维变更可触发状态或运维变更可触发状态。当所有前置状态处理器都完成变更前置处理(例如，针对待变更的容器组完成所有摘流工作)后，容器组状态会修改为Upgrading状态，并且进入运维变更阶段。在运维变更阶段，各个容器组运维变更触发器会发起对容器组执行对应的运维变更，比如，更新代码(即容器镜像)、更新资源配置(如2G内存改为4G内存)，也有一些运维操作是单纯的重启运行服务进程(类似重启电脑操作)等等。针对容器组的运维变更通常由云资源编排系统自身所具有的能力完成。

此外，在容器组运维变更生命周期中，所维护的容器组状态还可以包括“容器组变更状态”。在容器组运维变更触发器都完成容器组运维变更后，容器组状态进入“容器组变更状态”。响应于容器组状态进入“容器组变更状态”，在变更后的运维条件下启动变更后的容器组。在一些实施例中，变更后的容器组例如可以是原有容器组保持不变但其运维条件发生变更。在一些实施例中，变更后的容器组例如可以是重新创建的新容器组。

如图3中所示，在容器组处于容器组运维变更后置状态时，会进入变更后置处理阶段。在变更后置处理阶段，会基于容器组运维变更后置状态触发对应的变更后置处理。容器组运维变更后置状态可以包括运维变更后置检查(PostCheck)状态和运维变更完成(Completing)状态。

PostCheck状态是进入第一个容器组变更后置状态。在变更后的容器组内的容器都完成启动后，进入PostCheck状态。响应于容器组运维变更生命周期推进到PostCheck状态，会触发对应的后置状态处理器在变更后的容器组气候后对容器组执行一系列的变更后置检查。PostCheck状态可以至少包括用户可自定义的运维变更后置状态，该自定义运维变更后置状态用于触发用户的自定义操作。PostCheck状态所触发的自定义操作可以是与PreCheck状态所触发的自定义操作对应的操作。用于执行变更后置检查的后置状态处理器例如可以包括RuleSet状态处理器。在本说明书中，变更后置检查是针对是否符合容器组变更准出条件的变更准出检查。变更后置检查可以基于后置检查规则执行。后置检查规则可以与前置检查规则相对应。例如，如果前置检查规则包括用户将容器组当前处理的数据迁移到另一容器组临时存储，则后置检查规则可以包括容器组数据恢复，即，在PostCheck阶段，将数据从另一容器组迁回变更后的容器组)。

Completing状态是第二个容器组变更后置状态。响应于容器组运维变更生命周期推进到Completing状态，可以触发对应的后置状态处理器在通过所有变更后置检查后执行例如服务恢复操作的运维变更完成处理。在一些实施例中，例如，可以通过周边服务注册容器组所对应的服务实例并在容器组上挂载各自的资源锁(例如，Finalizer)来实现服务恢复操作。在一些涉及流量访问服务的示例中，响应于容器组运维变更生命周期推进到Completing状态，可以触发各种流量管控相关的后置状态处理器来完成对应流量的挂流处理，以使得变更后的容器组可以继续接受用户的请求流量。当所有流量都恢复后，容器组恢复到例如ServiceAvailable的容器组初始状态。

要说明的是，Completing状态也可以包括用于触发用户的自定义操作的自定义变更完成状态。例如，针对有些用户，需要在容器组变更后挂载自己管控的一些流量，比如，函数计算会在一个容器组内运行多个函数，每个函数都有自己单独的流量，因此用户会在Completing阶段自定义流量控制逻辑来挂载每个函数的流量。

在一些实施例中，容器组的各个容器组状态可以通过标注不同的状态标记来分别标识出。

图4示出了根据本说明书的实施例的基于容器组状态的容器组运维变更系统400的示例框架图。如图4所示，容器组运维变更系统400包括容器组运维变更触发器410、容器组状态驱动器420、前置状态处理器430和后置状态处理器440。

容器组运维变更触发器410是容器组运维变更过程的发起方。容器组运维变更触发器410也可以称为容器组运维变更触发装置。在需要对容器组进行运维变更时，容器组运维变更触发器410触发容器组运维变更声明。例如，在一些实施例中，在容器组运维变更触发器410需要对容器组进行运维变更时，容器组运维变更触发器410可以通过在容器组上打上用于指示容器组运维变更的标记来触发容器组运维变更声明。容器组状态驱动器420可以持续监测容器组标记。一旦监测到容器组被标记用于指示容器组运维变更的标记，则可以知悉容器组运维变更触发器410触发容器组运维变更声明。在一些实施例中，容器组运维变更触发器410可以通过向容器组状态驱动器420发送容器组变更消息(例如，REST请求)来触发容器组运维变更声明。所发送的容器组变更消息可以指定所要变更的容器组。容器组变更消息的示例例如可以是：{"kind":"Pod","apiVersion":"v1","name":"pod-name","operationType":"Upgrade"}。

容器组运维变更触发器410在触发针对容器组的首次容器组运维变更状后，会一直等待容器组推进到“运维变更可触发状态”，例如，持续监测容器组的容器组状态。开始对容器组执行运维变更。容器组运维变更触发器410响应于监测到容器组处于运维变更可触发状态，对容器组执行容器组运维变更，并且在容器组运维变更完成后通知给容器组状态驱动器420。

在一些实施例中，容器组运维变更触发器410可以被实现为云资源编排系统中的工作负载(Workload)。Workload是对云资源编排系统上资源和相关操作的一种封装，以对用户提供足够的原子性和封装性，对Workload的操作最终会通过其封装的逻辑反映到底层资源上。比如，k8s原生的Workload Deployment就是对容器组对应资源和相关运维变更的封装。Workload的示例例如可以包括但不限于CafeDeployment、OperationJob、ResourceDecoration等。CafeDeployment是负责对容器组进行升级的Workload，具体包括容器组内容器的镜像、环境变量、服务启动命令等配置的变更。OperationJob是负责对容器组进行运维的Workload，具体包括容器组内容器的重启、上线、下线等变更。ResourceDecoration是负责对容器组添加附加配置的Workload，具体包括sidecar配置、调度相关配置、容器组打标等变更。

容器组状态驱动器420负责容器组状态的管理，并且被配置为其根据当前容器组状态以及容器组当前状态的处理情况推动容器组运维变更生命周期中的状态推进，即，根据当前容器组状态以及容器组当前状态的处理情况判断是否满足进入下一容器组状态的条件，从而推动容器组运维变更生命周期中的容器组状态推进。例如，在满足进入下一容器组状态的条件时，将容器组运维变更生命周期中的容器组状态修改为下一容器组状态，由此推动容器组运维变更生命周期向前演进。容器组状态驱动器420也可以称为容器组状态驱动装置。

容器组状态驱动器420与容器组运维变更触发器410、前置状态处理器430和后置状态处理器440协作来执行容器组运维变更过程。

具体地，响应于从容器组运维变更触发器410触发容器组运维变更声明，容器组状态驱动器420驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态。

前置状态处理器430持续监测容器组状态。响应于监测到容器组处于运维变更前置状态，前置状态处理器430对容器组执行变更前置处理。前置状态处理器430也可以称为前置状态处理装置。

在一些实施例中，运维变更前置状态可以包括用于触发变更前置检查的第一运维变更前置状态和用于触发运维变更准备的第二运维变更前置状态。这里，变更前置检查包括基于前置检查规则的容器组变更准入检查。在这种情况下，响应于监测到容器组处于所述第一运维变更前置状态，第一运维变更前置状态所对应的前置状态处理器对容器组执行变更前置检查。要说明的是，第一运维变更前置状态所对应的前置状态处理器可以包括一个或多个前置状态处理器。前置检查规则至少包括自定义前置检查规则，该自定义前置检查规则可以对应于一种自定义运维变更前置状态，以用于执行对应的自定义操作。自定义前置检查规则例如可以包括用户扩展的自定义前置检查规则。如果变更前置检查未通过，则会拒绝继续执行当前容器组运维变更操作。前置检查规则还可以包括以下规则中的至少一种：基于服务水位的前置检查规则；基于服务资源的前置检查规则；和基于容器组重建校验的前置检查规则。

在一些实施例中，第一运维变更前置状态所对应的前置状态处理器例如可以包括RuleSet状态处理器。响应于监测到容器组处于运维变更前置状态，RuleSet状态处理器基于前置检查规则执行对应的变更前置检查，例如，应用的服务水位保护、服务资源额度是否充足等检查。待基于这些前置检查规则的变更前置检查都完成后，RuleSet状态处理器例如可以在容器组上标记用于指示变更前置检查已经完成的标记。

响应于监测到所有变更前置检查通过，第二运维变更前置状态所对应的前置状态处理器可以触发停用容器组为周边服务提供的服务。例如，周边服务注销容器组并从容器组上删除各自的资源锁(例如，Finalizer)。同样，第二运维变更前置状态所对应的前置状态处理器可以包括一个或多个前置状态处理器。在一些涉及流量访问服务的示例中，第二运维变更前置状态所对应的前置状态处理器例如可以包括各种流量管控相关的状态处理器。响应于容器组运维变更生命周期推进到Preparing状态，可以触发各种流量管控相关的状态处理器来完成对应流量的摘流处理，以保证在容器组运维变更时不会影响到用户的访问流量。

在运维变更前置状态所对应的所有前置状态处理器都完成变更前置处理后，容器组状态驱动器420驱动容器组进入运维变更可触发状态。容器组运维变更触发器410响应于容器组状态进入运维变更可触发状态而发起执行容器组运维变更，以由云资源编排系统完成容器组运维变更。在完成容器组运维变更后，容器组状态驱动器420驱动容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组。在变更后的容器组启动后，容器组状态驱动器420驱动容器组进入运维变更后置状态。

后置状态处理器440持续监测容器组状态。响应于监测到容器组处于运维变更后置状态，后置状态处理器440对容器组执行变更后置处理。后置状态处理器440也可以称为后置状态处理装置。

在运维变更后置状态所对应的所有后置状态处理器完成变更后置处理后，容器组状态驱动器420驱动容器组恢复服务可用状态。

在一些实施例中，运维变更后置状态可以包括用于触发变更后置检查的第一运维变更后置状态和用于触发运维变更完成的第二运维变更后置状态，所述变更后置检查包括基于后置检查规则的容器组变更准出检查，所述后置检查规则至少包括与自定义前置检查规则对应的自定义后置检查规则。

响应于监测到容器组处于第一运维变更后置状态，第一运维变更后置状态所对应的后置状态处理器对容器组执行变更后置检查。要说明的是，第一运维变更后置状态所对应的后置状态处理器可以包括一个或多个后置状态处理器。第一运维变更后置状态可以至少包括用户可自定义的运维变更后置状态，该自定义运维变更后置状态用于触发用户的自定义操作。第一运维变更后置状态所触发的自定义操作可以是与第一运维变更前置状态所触发的自定义操作对应的操作。用于执行变更后置检查的后置状态处理器例如可以包括RuleSet状态处理器。

响应于监测到所有变更后置检查通过，第二运维变更后置状态所对应的后置状态处理器触发恢复容器组为周边服务提供的服务。例如，周边服务注册容器组所对应的服务实例并在容器组上挂载各自的资源锁(例如，Finalizer)。同样，第二运维变更后置状态所对应的后置状态处理器可以包括一个或多个后置状态处理器。在一些涉及流量访问服务的示例中，响应于容器组运维变更生命周期推进到第二运维变更后置状态，可以触发各种流量管控相关的后置状态处理器来完成对应流量的挂流处理，以使得变更后的容器组可以继续接受用户的请求流量。

图5示出了根据本说明书的实施例的基于容器组状态的容器组运维变更方法500的示例流程图。

如图5所示，在501，在需要对容器组进行运维变更时，容器组运维变更触发器触发容器组运维变更声明。例如，在一些实施例中，在容器组运维变更触发器需要对容器组进行运维变更时，容器组运维变更触发器可以通过在容器组上打上用于指示容器组运维变更的标记来触发容器组运维变更声明。容器组状态驱动器可以持续监测容器组标记。一旦监测到容器组被标记用于指示容器组运维变更的标记，则可以知悉容器组运维变更触发器触发容器组运维变更声明。在一些实施例中，容器组运维变更触发器可以通过向容器组状态驱动器发送容器组变更消息(例如，REST请求)来触发容器组运维变更声明。

响应于容器组运维变更触发器触发容器组运维变更声明，在502，容器组状态驱动器驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态。

在503，容器组状态驱动器基于运维变更前置状态触发对应的变更前置处理。响应于监测到容器组处于运维变更前置状态，在504，前置状态处理器对容器组执行变更前置处理。

在一些实施例中，运维变更前置状态可以包括用于触发变更前置检查的第一运维变更前置状态和用于触发运维变更准备的第二运维变更前置状态。这里，变更前置检查包括基于前置检查规则的容器组变更准入检查。在这种情况下，响应于监测到容器组处于所述第一运维变更前置状态，第一运维变更前置状态所对应的前置状态处理器对容器组执行变更前置检查。前置检查规则至少包括自定义前置检查规则，该自定义前置检查规则可以对应于一种自定义运维变更前置状态，以用于执行对应的自定义操作。自定义前置检查规则例如可以包括用户扩展的自定义前置检查规则。如果变更前置检查未通过，则会拒绝继续执行当前容器组运维变更操作。前置检查规则还可以包括以下规则中的至少一种：基于服务水位的前置检查规则；基于服务资源的前置检查规则；和基于容器组重建校验的前置检查规则。

响应于监测到所有变更前置检查通过，第二运维变更前置状态所对应的前置状态处理器可以触发停用容器组为周边服务提供的服务。例如，周边服务注销容器组并从容器组上删除各自的资源锁。在一些涉及流量访问服务的示例中，第二运维变更前置状态所对应的前置状态处理器例如可以包括各种流量管控相关的状态处理器。响应于容器组运维变更生命周期推进到变更准确状态，可以触发各种流量管控相关的状态处理器来完成对应流量的摘流处理，以保证在容器组运维变更时不会影响到用户的访问流量。

在所有前置状态处理器都完成变更前置处理(505)后，在506容器组状态驱动器驱动容器组进入运维变更可触发状态，并且在507，触发容器组运维变更触发器执行容器组运维变更。在一些实施例中，在运维变更前置状态所对应的所有前置状态处理器都完成变更前置处理后，前置状态处理器例如可以向容器组状态处理器发送变更前置处理完成通知，以通知所有前置状态处理器都完成变更前置处理。在一些实施例，可以通过为容器组标注用于指示变更前置处理完成的标记来通知变更前置处理完成。

响应于容器组状态进入运维变更可触发状态，在508，容器组运维变更触发器发起执行容器组运维变更，以由云资源编排系统完成容器组运维变更。

响应于容器组运维变更完成(509)，在510，容器组状态驱动器驱动容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组。在一些实施例中，在完成变更运维变更处理后，容器组运维变更触发器例如可以向容器组状态处理器发送运维变更处理完成通知，以通知运维变更处理完成。在一些实施例，可以通过为容器组标注用于指示运维变更处理完成的标记来通知运维变更处理完成。

在变更后的容器组启动后，在511，容器组状态驱动器驱动变更后的容器组进入运维变更后置状态，并且在512，触发后置状态处理器执行变更后置处理。

响应于监测到容器组处于运维变更后置状态，在513，后置状态处理器对变更后的容器组执行变更后置处理。

在一些实施例中，运维变更后置状态可以包括用于触发变更后置检查的第一运维变更后置状态和用于触发运维变更完成的第二运维变更后置状态，所述变更后置检查包括基于后置检查规则的容器组变更准出检查，所述后置检查规则至少包括与自定义前置检查规则对应的自定义后置检查规则。

响应于监测到容器组处于第一运维变更后置状态，第一运维变更后置状态所对应的后置状态处理器对容器组执行变更后置检查。第一运维变更后置状态可以至少包括用户可自定义的运维变更后置状态，该自定义运维变更后置状态用于触发用户的自定义操作。第一运维变更后置状态所触发的自定义操作可以是与第一运维变更前置状态所触发的自定义操作对应的操作。响应于监测到所有变更后置检查通过，第二运维变更后置状态所对应的后置状态处理器触发恢复容器组为周边服务提供的服务。

在运维变更后置状态所对应的所有后置状态处理器完成变更后置处理(514)后，在515，容器组状态驱动器驱动容器组恢复容器组初始状态，从而完成当前容器组运维变更处理。在一些实施例中，在运维变更后置状态所对应的所有后置状态处理器都完成变更后置处理后，后置状态处理器例如可以向容器组状态处理器发送变更后置处理完成通知，以通知所有后置状态处理器都完成变更后置处理。在一些实施例，可以通过为容器组标注用于指示变更后置处理完成的标记来通知变更后置处理完成。

此外，可选地，在一些实施例中，多个容器组运维变更触发器可以同时发起容器组运维变更。对于一个容器组运维变更触发器已经触发的当前容器组运维变更生命周期，如果一个或多个在后容器组运维变更触发器所触发的容器组运维变更声明的发送时机在当前容器组运维变更生命周期的容器组运维变更完成之前，则该一个或多个在后容器组运维变更触发器共享当前容器组运维变更生命周期来执行各自的容器组运维变更。

此外，可选地，在一些实施例中，如果在容器组运维变更生命周期中处于述运维变更前置状态时接收到容器组运维变更取消请求，则可以从当前操作直接跳转到执行容器组状态驱动器驱动容器组进入容器组重启状态的操作，即，不执行当前操作到进入容器组重启状态的操作之间的所有操作，被跳过执行的操作至少包括容器组运维变更操作，从而取消针对容器组的运维变更。

如上参照图5描述了根据本说明书的实施例的基于容器组状态的容器组运维变更方法。下面采用具体示例来进一步描述根据本说明书的实施例的基于容器组状态的容器组运维变更方法。

图6示出了根据本说明书的实施例的基于容器组状态的容器组运维变更过程的示例示意图。在图6的示例中，容器组运维变更触发器包括CafeDeployment、OperationJob和ResourceDecoration，容器组状态处理器包括PodOpsLifecycleController，以及前置/后置状态处理器都由RuleSet和流量控制器实现。

当CafeDeployment、OperationJob、ResourceDecoration中的某几个容器组运维变更触发器需要执行容器组运维变更时，会触发容器组运维变更声明，从而触发一次容器组运维变更生命周期(步骤1)。例如，可以通过在容器组上标注标记的方式触发容器组运维变更声明。在接收容器组运维变更声明后，PodOpsLifecycleController会根据当前容器组状态以及容器组当前状态的处理情况推动容器组运维变更生命周期中的状态推进，即，根据当前容器组状态以及容器组当前状态的处理情况判断是否满足进入下一容器组状态的条件，从而推动容器组运维变更生命周期中的容器组状态推进。状态推进方式可以通过PodOpsLifecycleController在容器组上打上用于指示对应容器组状态的标记来实现。

容器组运维变更系统的各个组件持续监测容器组上的标记。如果监测到自己所关注的标记，即容器组进入用于指示组件工作的特定容器组状态，则对应的组件执行相应的处理。在组件完成处理后，通过标注标记的方式来通知针对容器组的处理完成。PodOpsLifecycleController会在监测到容器组被打上用于指示处理完成的标记后，驱动容器组进入下一容器组状态。

具体地，容器组状态首先从“服务可用”进入“前置检查”状态(步骤2)。前置检查状态会触发RuleSet基于一系列前置检查规则来执行前置检查，比如，应用的服务水位保护、应用服务资源额度是否充足等检查(步骤3)。待这些前置检查均通过后，RuleSet在容器组上标记用于指示前置检查通过的标记。随后，PodOpsLifecycleController会推进容器组状态进入“变更准备”状态。

在监测到进入“变更准备”状态后，各流量控制组件开始工作来为当前容器组进行摘流处理。待所有的流量控制组件都完成摘流处理后，会在容器组上标记用于指示摘流处理完成的标记。PodOpsLifecycleController根据容器组的标记发现容器组的流量组件都完成摘流处理后，会推进容器组进入“运维变更”状态。

在监测到进入“运维变更”状态后，CafeDeployment、OperationJob、ResourceDecoration都会监测容器组的状态符合运维变更条件，从而触发执行各自的容器组运维变更。在各容器组运维变更触发器完成其容器组运维变更后，会通过修改容器组标记的方式来指示其容器组运维变更已经完成(步骤4.1)。这时PodOpsLifecycleController会观察到容器组满足状态推进条件，从而推进容器组进入“后置检查”状态。

在进入“后置检查”状态后，触发RuleSet基于一系列后置检查规则来执行后置检查。在所有后置检查都通过后，RuleSet在容器组上标记用于指示后置检查通过的标记。。这时PodOpsLifecycleController会观察到容器组满足状态推进条件，从而推进容器组进入“变更完成”状态。

在进入“变更完成”状态后，各流量控制组件开始工作来为当前容器组进行挂流处理。待所有的流量控制组件都完成挂流处理后，会在容器组上标记用于指示挂流处理完成的标记(步骤5)。PodOpsLifecycleController根据容器组的标记发现容器组的流量组件都完成挂流处理后，推进容器组恢复到容器组初始状态，即，“服务可用”状态，从而完成一次容器组运维变更生命周期(步骤6)。

在容器组运维变更生命周期内，如果某个容器组变更触发器需要变更，那么它会触发容器组运维变更声明来发起一次容器组运维变更生命周期。如果此时该容器组已经在容器组运维变更生命周期内，所以该容器组变更触发器会共享当前容器组运维变更生命周期。比如，CafeDeployment触发一次容器组运维变更后，OperationJob也需要去运维该容器组，如果OperationJob发起容器组运维变更声明的触发时机是在当前容器组运维变更生命周期的“运维变更”状态或是“运维变更”状态之前的容器组状态，那么OperationJob共享当前的生命周期，并且OperationJob会和CafeDeployment一样，在容器组处于“运维变更”状态时发起自己的容器组运维变更。如果OperationJob发起容器组运维变更声明的触发时机是在当前容器组运维变更生命周期的“运维变更”状态之后的容器组状态，则由于当前容器组运维变更生命周期已经过了“运维变更”状态，容器组已经完成运维变更，从而OperationJob不能共享当前容器组运维变更生命周期，而需要需要等待当前变更生命周期结束后，重新触发新的容器组运维变更生命周期后进行运维变更。

此外，如图6所示，如果在“前置检查”状态和“变更准备”状态时接收到运维变更取消请求，即，CafeDeployment等容器组变更触发器删除容器组上的对应标记，则将容器组状态直接推进到“容器组变更状态”，换言之，从当前操作直接跳转到执行容器组状态驱动器驱动容器组进入容器组变更状态的操作，即，不执行当前操作到进入容器组变更状态的操作之间的所有操作。随后将容器组状态继续推进到“服务可用”状态。

利用上述容器组运维变更方案，通过在容器组运维变更生命周期中扩展加入用于触发自定义操作的运维变更前置状态以及用于触发自定义操作的运维变更后置状态，从而可以在容器组运维变更前后插入必要的前/后置动作，由此保证周边资源的完备性。

此外，由于容器组运维变更生命周期由容器组状态驱动器根据当前容器组状态以及容器组当前状态的处理情况推进，从而可以保证容器组变更状态流转的完备性。

而且，在上述容器组运维变更方案中，将容器组运维变更操作解耦为由三个相互独立的组件容器组状态驱动器，容器组运维变更触发器以及容器组状态处理器(前置状态处理器/后置状态处理器)三个组件分别执行部分操作，从而使得容器组运维变更操作不再是原子操作，由此可以支持针对容器组运维变更的各种自适应调整。

如上参照图1到图6，对根据本说明书实施例的容器组运维变更方法、容器组状态驱动装置以及容器组运维变更系统进行了描述。上面的容器组状态驱动装置和容器组运维变更系统可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图7示出了根据本说明书的实施例的基于计算机系统实现的容器组运维变更系统700的示例示意图。如图7所示，容器组运维变更系统700可以包括至少一个处理器710、存储器(例如，非易失性存储器)720、内存730和通信接口740，并且至少一个处理器710、存储器720、内存730和通信接口740经由总线760连接在一起。至少一个处理器710执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器710：响应于容器组运维变更触发器触发容器组运维变更声明，容器组状态驱动器驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；响应于监测到容器组处于运维变更前置状态，运维变更前置状态所对应的前置状态处理器对容器组执行变更前置处理；在所有前置状态处理器完成变更前置处理后，容器组状态驱动器驱动容器组进入运维变更可触发状态；响应于监测到容器组处于运维变更可触发状态，容器组运维变更触发器发起对容器组执行容器组运维变更；在完成容器组运维变更后，容器组状态驱动器驱动容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组；在变更后的容器组启动后，容器组状态驱动器驱动容器组进入运维变更后置状态；响应于监测到容器组处于运维变更后置状态，运维变更后置状态所对应的后置状态处理器对容器组执行变更后置处理；以及在所有后置状态处理器完成变更后置处理后，容器组状态驱动器驱动容器组恢复容器组初始状态。

应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器710进行本说明书的各个实施例中以上结合图1-图6描述的各种操作和功能。

图8示出了根据本说明书的实施例的基于计算机系统实现的容器组状态驱动装置800的示例示意图。如图8所示，容器组状态驱动装置800可以包括至少一个处理器810、存储器(例如，非易失性存储器)820、内存830和通信接口840，并且至少一个处理器810、存储器820、内存830和通信接口840经由总线860连接在一起。至少一个处理器810执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器810：响应于容器组运维变更触发器触发到容器组运维变更声明，驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；在运维变更前置状态所对应的所有前置状态处理器完成变更前置处理后，驱动容器组进入运维变更可触发状态，前置状态处理器响应于监测到容器组处于所述运维变更前置状态而对容器组执行变更前置处理；在完成容器组运维变更触发器所发起的容器组运维变更后，驱动容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组，容器组运维变更触发器响应于监测到容器组处于运维变更可触发状态而发起对容器组执行容器组运维变更；在变更后的容器组启动后，驱动容器组进入运维变更后置状态；以及在运维变更后置状态所对应的所有后置状态处理器完成变更后置处理后，驱动变更后的容器组恢复容器组初始状态，后置状态处理器响应于监测到变更后的容器组处于所述运维变更后置状态而对变更后的容器组执行变更后置处理。

应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器810进行本说明书的各个实施例中以上结合图1-图6描述的各种操作和功能。

根据一个实施例，提供了一种比如机器可读介质(例如，非暂时性机器可读介质)的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-图6描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

根据一个实施例，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序当被处理器执行时，使得处理器执行本说明书的各个实施例中以上结合图1-图6描述的各种操作和功能。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (16)

1.一种基于容器组状态的容器组运维变更方法，包括：

响应于容器组运维变更触发器触发容器组运维变更声明，容器组状态驱动器驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；

响应于监测到所述容器组处于所述运维变更前置状态，所述运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置处理；

在所有前置状态处理器完成变更前置处理后，所述容器组状态驱动器驱动所述容器组进入运维变更可触发状态；

响应于监测到所述容器组处于所述运维变更可触发状态，所述容器组运维变更触发器发起对所述容器组执行容器组运维变更；

在完成容器组运维变更后，所述容器组状态驱动器驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组；

在所述变更后的容器组启动后，所述容器组状态驱动器驱动所述变更后的容器组进入运维变更后置状态；

响应于监测到所述变更后的容器组处于所述运维变更后置状态，所述运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置处理；以及

在所有后置状态处理器完成变更后置处理后，所述容器组状态驱动器驱动所述变更后的容器组恢复容器组初始状态。

2.如权利要求1所述的容器组运维变更方法，其中，所述运维变更前置状态包括用于触发变更前置检查的第一运维变更前置状态和用于触发运维变更准备的第二运维变更前置状态，所述变更前置检查包括基于前置检查规则的容器组变更准入检查，所述前置检查规则至少包括自定义前置检查规则，

所述响应于监测到所述容器组处于所述运维变更前置状态，所述运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置处理包括：

响应于监测到所述容器组处于所述第一运维变更前置状态，所述第一运维变更前置状态所对应的前置状态处理器对所述容器组执行变更前置检查；以及

响应于监测到所述变更前置检查通过，所述第二运维变更前置状态所对应的前置状态处理器触发停用所述容器组为周边服务提供服务。

3.如权利要求2所述的容器组运维变更方法，其中，所述前置检查规则还包括以下规则中的至少一种：

基于服务水位的前置检查规则；

基于服务资源的前置检查规则；和

基于容器组重建校验的前置检查规则。

4.如权利要求2所述的容器组运维变更方法，其中，所述运维变更后置状态包括用于触发变更后置检查的第一运维变更后置状态和用于触发运维变更完成的第二运维变更后置状态，所述变更后置检查包括基于后置检查规则的容器组变更准出检查，所述后置检查规则至少包括与自定义前置检查规则对应的自定义后置检查规则，

响应于监测到所述变更后的容器组处于所述运维变更后置状态，所述运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置处理包括：

响应于监测到所述变更后的容器组处于所述第一运维变更后置状态，所述第一运维变更后置状态所对应的后置状态处理器对所述变更后的容器组执行变更后置检查；以及

响应于监测到所述变更后置检查通过，所述第二运维变更前置状态所对应的后置状态处理器触发恢复所述变更后的容器组为周边服务提供服务。

5.如权利要求4所述的容器组运维变更方法，其中，所述第一运维变更前置状态所对应的前置状态处理器包括RuleSet状态处理器，和/或所述第一运维变更后置状态所对应的后置状态处理器包括RuleSet状态处理器。

6.如权利要求4所述的容器组运维变更方法，其中，在容器组所提供的服务包括与流量对应的服务时，所述第二运维变更前置状态所对应的前置状态处理器包括用于流量管控的状态处理器，所述第二运维变更后置状态所对应的后置状态处理器包括用于流量管控的状态处理器，以及所述容器组所提供服务的停用和恢复分别通过所述用于流量管控的状态处理器的摘流处理和挂流处理来实现。

7.如权利要求4所述的容器组运维变更方法，其中，所述容器组为周边服务提供服务的停用通过周边服务注销所述容器组并从所述容器组上删除各自的资源锁来实现，以及所述变更后的容器组为周边服务提供服务的恢复通过周边服务注册所述变更后的容器组所对应的服务实例并在所述变更后的容器组上挂载各自的资源锁来实现。

8.如权利要求1所述的容器组运维变更方法，其中，所述容器组的各个状态通过为所述容器组标注对应的状态标记来实现。

9.如权利要求1所述的容器组运维变更方法，其中，所述容器组运维变更触发器包括多个容器组运维变更触发器，如果一个或多个容器组运维变更触发器的容器组运维变更声明的发送时机在当前容器组运维变更生命周期的所述容器组运维变更完成之前，则所述一个或多个容器组运维变更触发器共享所述当前容器组运维变更生命周期来执行各自的容器组运维变更。

10.如权利要求1所述的容器组运维变更方法，还包括：

响应于在所述容器组运维变更生命周期中处于所述运维变更前置状态时接收到容器组运维变更取消请求，从当前操作直接跳转到执行所述容器组状态驱动器驱动所述容器组进入容器组变更状态的操作。

11.一种用于基于容器组状态的容器组运维变更的方法，包括：

响应于容器组运维变更触发器触发容器组运维变更声明，驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；

在所述运维变更前置状态所对应的所有前置状态处理器完成变更前置处理后，驱动所述容器组进入运维变更可触发状态，所述前置状态处理器响应于监测到所述容器组处于所述运维变更前置状态而对所述容器组执行变更前置处理；

在完成所述容器组运维变更触发器所发起的容器组运维变更后，驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组，所述容器组运维变更触发器响应于监测到所述容器组处于所述运维变更可触发状态而发起对所述容器组执行容器组运维变更；

在所述变更后的容器组启动后，驱动所述变更后的容器组进入运维变更后置状态；以及

在所述运维变更后置状态所对应的所有后置状态处理器完成变更后置处理后，驱动所述变更后的容器组恢复容器组初始状态，所述后置状态处理器响应于监测到所述变更后的容器组处于所述运维变更后置状态而对所述变更后的容器组执行变更后置处理。

12.一种基于容器组状态的容器组运维变更系统，包括：

容器组运维变更触发器，触发容器组运维变更声明，以及响应于监测到所述容器组处于运维变更可触发状态，发起对所述容器组执行容器组运维变更；

前置状态处理器，响应于监测到所述容器组处于运维变更前置状态而对所述容器组执行变更前置处理；

后置状态处理器，响应于监测到变更后的容器组处于运维变更后置状态而对所述变更后的容器组执行变更后置处理；以及

容器组状态驱动器，

响应于所述容器组运维变更触发器触发容器组运维变更声明，驱动待变更的容器组从所触发的容器组运维变更生命周期的容器组初始状态进入运维变更前置状态，

所述运维变更前置状态至少包括用于触发自定义操作的自定义运维变更前置状态；

在所述运维变更前置状态所对应的所有前置状态处理器完成变更前置处理后，驱动所述容器组进入运维变更可触发状态；

在完成所述容器组运维变更触发器所发起的容器组运维变更后，驱动所述容器组进入容器组变更状态，以在变更后的运维条件下启动变更后的容器组；

在所述变更后的容器组启动后，驱动所述变更后的容器组进入运维变更后置状态；以及

在所述运维变更后置状态所述对应的所有后置状态处理器完成变更后置处理后，驱动所述变更后的容器组恢复容器组初始状态。

13.一种基于容器组状态的容器组运维变更系统，包括：

至少一个处理器，

与所述至少一个处理器耦合的存储器，以及

存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求1到10中任一所述的基于容器组状态的容器组运维变更方法。

14.一种用于基于容器组状态的容器组运维变更的装置，包括：

至少一个处理器，

与所述至少一个处理器耦合的存储器，以及

存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求11所述的用于基于容器组状态的容器组运维变更的方法。

15.一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如权利要求1到10中任一所述的基于容器组状态的容器组运维变更方法或者如权利要求11所述的用于基于容器组状态的容器组运维变更的方法。

16.一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如权利要求1到10中任一所述的基于容器组状态的容器组运维变更方法或者如权利要求11所述的用于基于容器组状态的容器组运维变更的方法。

Images