[发明专利]具有业务快速恢复功能的容器组更新方法及系统

说明书

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

技术领域

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

背景技术

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

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

发明内容

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

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

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

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

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

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

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