CN111290767B - 具有业务快速恢复功能的容器组更新方法及系统 - Google Patents

Abstract

本发明提出一种具有业务快速恢复功能的容器组更新方法及系统，包括：根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新。

Description

具有业务快速恢复功能的容器组更新方法及系统

技术领域

本发明涉及并计算机中的容器编排领域，并特别涉及一种具有业务快速恢复功能的容器组更新方法及系统。

背景技术

在云计算场景下，容器技术成为机群使用者运行各类应用的统一载体。一个基于容器方式运行的计算业务，将业务的可执行程序和其依赖的函数库打包为作业容器镜像。然而现有通过容器编排系统运行业务时，通常不能将业务本身，按照单独业务容器方式运行，一般需要与业务密不可分的依赖容器同时运行和交互，即作业容器和依赖容器必须同时运行才能保证作业正常运行。如：作业容器往往会依赖数据卷容器，否则无法保存作业运行过程中产生的数据。同时一般还依赖网络容器，网络容器为作业容器提供了网络连接功能，缺少网络容器就会使得作业容器“失联”，容器编排管理系统就无法得知作业容器运行的状态。现在的作业调度系统通常以“容器组”为调度管理单位，如：云计算容器编排系统Kubernetes就以Pod这样的容器组为单位编排调度作业，Pod 内部包含了所有密不可分的容器，如图2容器组示意图所示。容器组内部所有容器都是存在依赖密不可分的。这种以容器组为最小单位的调度方式，保证了容器组内密不可分的容器都可以同时运行，避免了容器组内各个承载业务的容器因为依赖关系问题而无法运行。

然而这种以容器组为最小调度管理单位的方式也存在问题。因为容器组粒度过大无法直接管理到容器组内的具体容器，导致容器组内容器更新和升级过程中存在冗余操作。例如，如果容器组中只有单个容器需要进行版本更新和升级。在更新容器组的时候，其他所有未发生改变的容器也需要相应地进行重启 (如图8无细粒度更新系统更新过程所示)。如：当前作业运行状态和数据备份，容器进程销毁，重新创建容器组，重新调度容器组、重新运行容器组。可见这个过程中除了更新需要进行版本升级的单个容器外，容器组内与其具有相关性的所有容器的销毁、创建、资源调度都是冗余的。除此之外，对于容器组内所有容器的冗余调度过程，不仅会因这些容器操作造成系统资源的浪费，同时容器组的重新调度过程会增加调度排队延时的风险，对在线业务会严重影响服务质量和用户体验。

发明内容

针对现有技术的不足，本发明提出一种具有业务快速恢复功能的容器组更新方法，其中包括：

步骤1、根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；

步骤2、保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新。

所述的具有业务快速恢复功能的容器组更新方法，其中该容器组中的容器之间通过管道或套接字方式，实现容器间通信，在暂停该容器组的服务时保存进程间的连接状态，按照该连接状态重建更新容器与其余容器的通信。

所述的具有业务快速恢复功能的容器组更新方法，其中该步骤1包括：

步骤11、根据该更新请求，获得业务所有的容器组副本信息列表，容器组副本信息列表包括容器组运行节点以及容器组中所有容器，遍历该容器组副本信息列表中的每一个容器组副本；

步骤12、对于该更新请求，检查用户提交的作业配置文件，并和相同作业前一个版本的作业配置文件进行对比，根据对比结果判断当前容器组副本对应容器组中的容器是否需要更新，若是则执行该步骤2，否则容器进入容器暂停状态；

步骤13、容器更新完成之后，判断是否是容器组中最后一个容器，若是则容器组进入容器重启状态，重启容器，否则，重复步骤12；

步骤14 、检查容器组是否是最后一个容器组副本，若是则生成更新完成消息，否则，重复步骤12至步骤13。

所述的具有业务快速恢复功能的容器组更新方法，其中该步骤2包括：

步骤21、检查容器镜像仓库是否存在更新后的容器镜像，若存在，则执行步骤22，否则执行步骤23；

步骤22、从容器镜像仓库拉取新的容器镜像，容器从运行状态进入状态保存状态，保存容器的状态信息，容器状态从状态保存变为容器更新状态，销毁待更新容器，容器状态由容器更新变为容器恢复状态，按照该状态信息重新启动新容器，容器变为容器重启状态；

步骤23、从容器信息中拉取用户提交的程序源码、环境变量和配置文件，根据环境变量编译程序代码，生成可执行文件，根据该配置文件和该可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中，执行步骤 22。

所述的具有业务快速恢复功能的容器组更新方法，其中该步骤1包括：

步骤31、暂停当前容器的运行，并将当前容器的进程持久化为文件存放在磁盘中并释放系统资源；

该步骤2包括：

步骤32、根据更新完成消息中的容器进程号，恢复该容器进程号所在容器组中所有容器，容器状态由容器暂停状态恢复为容器运行状态。

本发明还提出了一种具有业务快速恢复功能的容器组更新系统，其中包括：

模块1、根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；

模块2、保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新。

所述的具有业务快速恢复功能的容器组更新系统，其中该容器组中的容器之间通过管道或套接字方式，实现容器间通信，在暂停该容器组的服务时保存进程间的连接状态，按照该连接状态重建更新容器与其余容器的通信。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块1包括：

模块11、根据该更新请求，获得业务所有的容器组副本信息列表，容器组副本信息列表包括容器组运行节点以及容器组中所有容器，遍历该容器组副本信息列表中的每一个容器组副本；

模块12、对于该更新请求，检查用户提交的作业配置文件，并和相同作业前一个版本的作业配置文件进行对比，根据对比结果判断当前容器组副本对应容器组中的容器是否需要更新，若是则执行该模块2，否则容器进入容器暂停状态；

模块13、容器更新完成之后，判断是否是容器组中最后一个容器，若是则容器组进入容器重启状态，重启容器，否则，重复模块12；

模块14 、检查容器组是否是最后一个容器组副本，若是则生成更新完成消息，否则，重复模块12至模块13。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块2包括：

模块21、检查容器镜像仓库是否存在更新后的容器镜像，若存在，则执行模块22，否则执行模块23；

模块22、从容器镜像仓库拉取新的容器镜像，容器从运行状态进入状态保存状态，保存容器的状态信息，容器状态从状态保存变为容器更新状态，销毁待更新容器，容器状态由容器更新变为容器恢复状态，按照该状态信息重新启动新容器，容器变为容器重启状态；

模块23、从容器信息中拉取用户提交的程序源码、环境变量和配置文件，根据环境变量编译程序代码，生成可执行文件，根据该配置文件和该可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中，执行模块 22。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块1包括：

模块31、暂停当前容器的运行，并将当前容器的进程持久化为文件存放在磁盘中并释放系统资源；

该模块2包括：

模块32、根据更新完成消息中的容器进程号，恢复该容器进程号所在容器组中所有容器，容器状态由容器暂停状态恢复为容器运行状态。

由以上方案可知，本发明的优点在于：

1)更新速度快：每次更新只会原地更新容器组中需要更新的容器，减少了对其他无需更新容器，所进行的不必要销毁、打包、创建操作。2)服务保持运行状态：通过容器暂停持久化技术，可以暂停服务的运行状态，在更新完成之后服务可以恢复之前的状态继续运行。该方法就可以避免了耗时较长的业务的重复运行，避免了重复运行所造成的资源浪费。3)避免重新调度的排队开销：因为只在原地更新了需要更新容器，整个容器组的位置并没有改变，这样就避免了系统容器组因调度器重新调度而造成的作业调度等待开销。

附图说明

图1细粒度容器更新系统结构图；

图2容器组示意图；

图3细粒度更新系统原理图；

图4控制模块流程图；

图5更新模块流程图；

图6状态转移图；

图7暂停模块流程图；

图8无细粒度更新系统更新过程图；

图9细粒度容器更新过程图。

具体实施方式

本发明加快容器组更新的核心构思是：通过对容器组更加细粒度的控制，对容器组中需要更新的容器“原地”更新，来消除容器重复创建、调度等操作，缩短由于容器组更新而带来的业务中断时间，进而加快业务恢复功能。“原地”更新是指在运行业务更新前的计算节点上，运行业务更新后的业务容器。整个方法详细过程为：在容器组中某个容器更新的时候，首先暂停该容器组的服务，通过容器暂停持久化技术将正在运行的其他无需更新的容器全都暂停，并将无需更新的容器进程持久化到磁盘，完全释放系统资源。然后记录需要更新容器的运行时状态，并在原地销毁正在运行且需要更新的容器，即对于容器组中需要更新的容器会原地销毁并更新。对于容器组中无需更新的容器会暂停运行。最后，根据记录的运行时状态重新创建需要更新的容器，更新完成之后恢复暂停运行的容器(如图9细粒度容器更新过程所示)。因为所保存的运行时状态和更新之前完全相同，这样的容器更新过程保证了更新后的容器能够和容器组中其他容器继续保持连接和服务。

其中释放系统资源是释放容器组占用的资源。释放是因为更新的过程中容器组无法工作，所以没有必要占用资源。不释放会导致资源闲置，得不到充分利用。

本发明提供了一种具有业务快速恢复功能的容器组更新系统。包括对容器组的控制模块，容器暂停模块，以及容器更新模块。

容器组的控制模块，首先将用户对容器组的更新请求和容器组当前状态进行比较，并找出需要更新的容器。根据请求中需要更新的容器镜像文件构建新的容器镜像。然后保存现有容器的运行时状态，销毁现有容器。最后重新运行新的容器镜像。

容器暂停模块，对于容器组中无需更新的容器，通过用户态中断技术暂停容器的运行。之后使用进程持久化技术，将容器进程持久化为磁盘文件并释放系统资源。在需更新容器完成更新之后，再重新将持久化的容器进行进程恢复，恢复整个容器组的正常运行。

容器更新模块，容器组中的容器之间可通过管道或套接字等方式，实现容器间通信。为了保证更新后的容器可以和其他容器继续保持连接，就需要保存容器间的连接状态，并在更新容器的时候完全按照保存的状态重建容器。

为让本发明的上述特征和效果能阐述的更明确易懂，下文特举实施例，并配合说明书附图作详细说明如下。

发明包括三个子模块：包括对容器组的控制模块，容器暂停模块，以及容器更新模块。

针对容器更新模块，发明提供一种具有变更检查和容器组细粒度更新的方法，具有如下特征：

1)并发滚动更新保证服务不中断：控制模块同时并发遍历所有容器组副本尝试更新。同时为了保证服务不中断，控制器会保持一定比例(可配置参数，记为P％)的服务运行。对于每个容器组，如果更新该容器组会使得在线运行容器组比例少于容器组总数的P％就暂停更新该容器组。控制模块等待正在更新的容器组完成更新，恢复运行之后继续更新。

发明提出了一种细粒度容器更新控制方法，如图4控制模块流程图所示，详细步骤如下：

步骤11:对于用户提交的更新请求，控制模块首先与集群控制器通信获得该业务所有的容器组副本信息列表，包括容器组运行节点，容器组中所有容器的列表。然后遍历列表中的每一个容器组副本。因为很多服务并非只有一个实例。比如机器学习模型推理服务一般会部署多个实例。实例之间互为副本。这样做主要是为了保证用户请求负载可以均衡地分配到多个实例副本上。同时服务也可以根据请求量动态地扩缩容，多副本也保证了服务的高可用性。

步骤12:对于每个容器组，控制模块遍历检查每一个容器组。为了保证服务不中断，控制模块会保持一定比例(可配置参数，记为P％)的服务运行。如果更新该容器组会使得在线运行容器组比例少于容器组总数的P％就暂停更新该容器组。控制模块等待正在更新的容器组完成更新，恢复运行之后继续更新。

步骤13:对于用户提交的更新请求，控制模块首先检查用户提交的作业配置文件，并和相同作业上一个版本的作业配置文件进行对比，得到新版本中需要更新的容器。然后判断当前容器是否需要更新。

步骤14:控制模块判断容器是否需要更新，如果容器需要更新，控制模块就给更新模块发送容器更新信息。更新模块收到消息后尝试更新该容器。容器进入“状态保存”状态。

步骤15:控制模块判断容器是否需要更新，如果容器需要不需要更新，控制模块就与容器暂停模块通信，该容器进入“容器暂停”状态。

步骤16:控制模块系统在容器更新完成之后，进入“容器重启”状态，向更新模块发送重启信号尝试重启容器。控制模块判断是否是最后一个容器。如果不是，控制模块重复步骤12至步骤16。

步骤17:控制模块检查容器组是否是最后一个容器组副本，如果不是，更新控制模块重复步骤11至步骤17。

更新模块有以下特征：

1)对容器组更新粒度更细：对于用户对容器组的更新请求，本方法的细粒度更新区别于现有常见的容器组全量更新模式。如图2所示，一个容器组中包含了用户需要运行的业务容器和依赖的监控容器、共享的网络组件容器，日志采集容器等，使得容器组占有的资源通常较大。而通常对于容器组的更新需求中，只需要更新容器组内占用资源较少的少数容器，绝大部分情况下只需更新一个容器即可。所以本方法是对容器组中容器进行更加细粒度的更新，从而可以有效减少更新时间。

2)原地更新：细粒度容器更新过程是在需要更新的容器所在的机器“原地”销毁并更新容器。原地更新减少了系统重复销毁重建容器组的开销，加快了更新速度。保证了容器更新后的运行环境与更新前一致。

3)避免重复调度：现有系统以容器组为单位进行调度管理的初衷，是为了保证容器组内部密不可分的容器都可以同时运行。如图2所示，容器组需要同时监控业务容器运行状态、采集业务容器生成的日志、保持业务容器的网络连接。在容器组第一次调度运行之后，说明容器组已经运行在了合适的计算节点上。这个时候更新模块会原地更新容器并在更新完成之后恢复容器的运行，这个过程避免了调度，无需调度器参与，从而减少了调度器的负担和重复调度的时间开销。

发明提出了容器组细粒度更新的方法，如图5更新模块流程图所示，具体步骤如下：

步骤21:更新模块收到控制模块发送的需要更新的容器信息。更新模块检查容器镜像仓库是否存在更新后的容器镜像。

步骤22:更新模块发现需要更新的容器镜像还不存在，就从控制模块发送的容器信息中拉取用户提交的程序源码、环境变量和配置文件Dockerfile。

步骤23:更新模块根据环境变量编译程序代码。生成可执行文件。

步骤24:更新模块根据配置文件Dockerfile和程序可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中。

步骤25:控制模块从容器镜像仓库拉取新的容器镜像。容器从运行状态进入“状态保存”状态。

步骤26:更新模块保存容器的状态，包括文件卷挂载位置，网络端口号等。并将状态信息发送给控制模块。容器状态从“状态保存”变为“容器更新”状态。

步骤27：更新模块销毁容器。更新模块给控制模块发送容器销毁完成消息，容器状态由“容器更新”变为“容器恢复”状态。

步骤28:控制模块收到销毁完成消息后就向更新模块发送容器的状态信息。更新模块收到状态信息后，就按照状态信息重新启动新容器。

步骤29:更新模块向控制模块发送更新完成消息。容器变为“容器重启”状态。至此，容器已经原地更新完成。

暂停模块有以下特征：

1)保持作业执行进度：在作业执行过程中如果发生了容器组更新事件，传统的更新方式会销毁业务容器。销毁业务容器后，当前作业的执行进度也会完全丢失，必须在更新之后重新开始。而细粒度容器更新技术会暂停业务容器并在更新完成之后恢复运行，这样业务容器中作业就可以从暂停前的进度开始重新执行。从而减少了重复执行相同作业的开销。

发明提出了一种暂停容器的方法，如图7暂停模块流程图所示，具体步骤如下：

步骤31:暂停模块接收到控制模块发送的暂停容器消息就记录当前容器的进程号并发送至控制器保存。容器状态由“容器运行”状态变为“容器暂停”状态。

步骤32:暂停模块暂停当前容器的运行。暂停将进程持久化为文件存放在磁盘中并释放系统资源。

步骤33:暂停模块等待控制器发送更新完成消息。

步骤34:控制模块接收到更新模块发送的更新完成消息。此时容器组已经可以恢复运行，控制模块就向暂停模块发送更新完成恢复容器的消息并附带所有需要恢复运行的容器进程号。

步骤35:更新模块收到需要恢复运行的容器进程号后恢复所有的容器。容器状态由“容器暂停”状态恢复为“容器运行”状态。

以下为与上述方法实施例对应的系统实施例，本实施方式可与上述实施方式互相配合实施。上述实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在上述实施方式中。

本发明还提出了一种具有业务快速恢复功能的容器组更新系统，其中包括：

模块1、根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；

模块2、保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新。

所述的具有业务快速恢复功能的容器组更新系统，其中该容器组中的容器之间通过管道或套接字方式，实现容器间通信，在暂停该容器组的服务时保存进程间的连接状态，按照该连接状态重建更新容器与其余容器的通信。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块1包括：

模块11、根据该更新请求，获得业务所有的容器组副本信息列表，容器组副本信息列表包括容器组运行节点以及容器组中所有容器，遍历该容器组副本信息列表中的每一个容器组副本；

模块12、对于该更新请求，检查用户提交的作业配置文件，并和相同作业前一个版本的作业配置文件进行对比，根据对比结果判断当前容器组副本对应容器组中的容器是否需要更新，若是则执行该模块2，否则容器进入容器暂停状态；

模块13、容器更新完成之后，判断是否是容器组中最后一个容器，若是则容器组进入容器重启状态，重启容器，否则，重复模块12；

模块14 、检查容器组是否是最后一个容器组副本，若是则生成更新完成消息，否则，重复模块12至模块13。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块2包括：

模块21、检查容器镜像仓库是否存在更新后的容器镜像，若存在，则执行模块22，否则执行模块23；

模块22、从容器镜像仓库拉取新的容器镜像，容器从运行状态进入状态保存状态，保存容器的状态信息，容器状态从状态保存变为容器更新状态，销毁待更新容器，容器状态由容器更新变为容器恢复状态，按照该状态信息重新启动新容器，容器变为容器重启状态；

模块23、从容器信息中拉取用户提交的程序源码、环境变量和配置文件，根据环境变量编译程序代码，生成可执行文件，根据该配置文件和该可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中，执行模块 22。

所述的具有业务快速恢复功能的容器组更新系统，其中该模块1包括：

模块31、暂停当前容器的运行，并将当前容器的进程持久化为文件存放在磁盘中并释放系统资源；

该模块2包括：

模块32、根据更新完成消息中的容器进程号，恢复该容器进程号所在容器组中所有容器，容器状态由容器暂停状态恢复为容器运行状态。

Claims (8)

1.一种具有业务快速恢复功能的容器组更新方法，其特征在于，包括：

步骤1、根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；

步骤2、保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新；

该步骤1包括：

步骤11、根据该更新请求，获得业务所有的容器组副本信息列表，容器组副本信息列表包括容器组运行节点以及容器组中所有容器，遍历该容器组副本信息列表中的每一个容器组副本；

步骤12、对于该更新请求，检查用户提交的作业配置文件，并和相同作业前一个版本的作业配置文件进行对比，根据对比结果判断当前容器组副本对应容器组中的容器是否需要更新，若是则执行该步骤2，否则容器进入容器暂停状态；

步骤13、容器更新完成之后，判断是否是容器组中最后一个容器，若是则容器组进入容器重启状态，重启容器，否则，重复步骤12；

步骤14 、检查容器组是否是最后一个容器组副本，若是则生成更新完成消息，否则，重复步骤12至步骤13。

2.如权利要求1所述的具有业务快速恢复功能的容器组更新方法，其特征在于，该容器组中的容器之间通过管道或套接字方式，实现容器间通信，在暂停该容器组的服务时保存进程间的连接状态，按照该连接状态重建更新容器与其余容器的通信。

3.如权利要求1所述的具有业务快速恢复功能的容器组更新方法，其特征在于，该步骤2包括：

步骤21、检查容器镜像仓库是否存在更新后的容器镜像，若存在，则执行步骤22，否则执行步骤23；

步骤22、从容器镜像仓库拉取新的容器镜像，容器从运行状态进入状态保存状态，保存容器的状态信息，容器状态从状态保存变为容器更新状态，销毁待更新容器，容器状态由容器更新变为容器恢复状态，按照该状态信息重新启动新容器，容器变为容器重启状态；

步骤23、从容器信息中拉取用户提交的程序源码、环境变量和配置文件，根据环境变量编译程序代码，生成可执行文件，根据该配置文件和该可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中，执行步骤22。

4.如权利要求1所述的具有业务快速恢复功能的容器组更新方法，其特征在于，该步骤1包括：

步骤31、暂停当前容器的运行，并将当前容器的进程持久化为文件存放在磁盘中并释放系统资源；

该步骤2包括：

步骤32、根据更新完成消息中的容器进程号，恢复该容器进程号所在容器组中所有容器，容器状态由容器暂停状态恢复为容器运行状态。

5.一种具有业务快速恢复功能的容器组更新系统，其特征在于，包括：

模块1、根据对容器组的更新请求，暂停该容器组的服务，通过比较更新请求和容器组当前状态，确定该容器组中待更新容器，并将该容器组中除该待更新容器以外的容器全都暂停，并将除该待更新容器以外的容器的进程持久化到磁盘；

模块2、保存该待更新容器的运行状态，根据该更新请求中需要更新的容器镜像文件构建新的容器镜像，销毁该待更新容器后根据该运行状态重新运行新的容器镜像，得到更新容器，恢复运行该容器组以完成对该容器组的更新；

该模块1包括：

模块11、根据该更新请求，获得业务所有的容器组副本信息列表，容器组副本信息列表包括容器组运行节点以及容器组中所有容器，遍历该容器组副本信息列表中的每一个容器组副本；

模块12、对于该更新请求，检查用户提交的作业配置文件，并和相同作业前一个版本的作业配置文件进行对比，根据对比结果判断当前容器组副本对应容器组中的容器是否需要更新，若是则执行该模块2，否则容器进入容器暂停状态；

模块13、容器更新完成之后，判断是否是容器组中最后一个容器，若是则容器组进入容器重启状态，重启容器，否则，重复模块12；

模块14 、检查容器组是否是最后一个容器组副本，若是则生成更新完成消息，否则，重复模块12至模块13。

6.如权利要求5所述的具有业务快速恢复功能的容器组更新系统，其特征在于，该容器组中的容器之间通过管道或套接字方式，实现容器间通信，在暂停该容器组的服务时保存进程间的连接状态，按照该连接状态重建更新容器与其余容器的通信。

7.如权利要求5所述的具有业务快速恢复功能的容器组更新系统，其特征在于，该模块2包括：

模块21、检查容器镜像仓库是否存在更新后的容器镜像，若存在，则执行模块22，否则执行模块23；

模块22、从容器镜像仓库拉取新的容器镜像，容器从运行状态进入状态保存状态，保存容器的状态信息，容器状态从状态保存变为容器更新状态，销毁待更新容器，容器状态由容器更新变为容器恢复状态，按照该状态信息重新启动新容器，容器变为容器重启状态；

模块23、从容器信息中拉取用户提交的程序源码、环境变量和配置文件，根据环境变量编译程序代码，生成可执行文件，根据该配置文件和该可执行文件构建新的容器镜像，并且将新的容器镜像存入容器镜像仓库中，执行模块22。

8.如权利要求5所述的具有业务快速恢复功能的容器组更新系统，其特征在于，该模块1包括：

模块31、暂停当前容器的运行，并将当前容器的进程持久化为文件存放在磁盘中并释放系统资源；

该模块2包括：

模块32、根据更新完成消息中的容器进程号，恢复该容器进程号所在容器组中所有容器，容器状态由容器暂停状态恢复为容器运行状态。

Images