CN111857761A

CN111857761A - 一种容器集群服务应用程序升级的方法及设备

Info

Publication number: CN111857761A
Application number: CN201910349424.1A
Authority: CN
Inventors: 马晓光
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Group Henan Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Group Henan Co Ltd
Priority date: 2019-04-28
Filing date: 2019-04-28
Publication date: 2020-10-30

Abstract

本发明公开了容器集群服务应用程序升级的方法及设备，其中，方法包括：接收构建包含多个第二容器的备用容器集群的第一操作信息，并根据第一操作信息构建相应的备用容器集群；接收针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息；根据第二操作信息对第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将备用容器集群切换至为前端的应用程序提供服务的容器集群。本方案，升级失败时，通过修改服务端口将备用容器集群切换至为前端的客户端提供服务的容器集群，因此，本方案有效缩短了升级失败时的回滚时间，除此之外，本方案有效保障了后台服务的质量。

Description

一种容器集群服务应用程序升级的方法及设备

技术领域

本发明涉及后台服务升级的技术领域，尤其涉及一种容器集群服务应用程序升级的方法及设备。

背景技术

现有技术方案中，基于前端的用户端的需求逐渐升高，或者是后台提供服务的范围逐步扩大，对后台服务应用程序进行升级是极其常见的事情。

然而，现有方案中，会选择在前端的应用程序的用户的数量较少的时间段，对后台服务应用程序进行升级，以最大限度的降低由于升级对前端的用户造成的影响，如通信公司的流量查询平台，对囊括巨大流量数据的后台服务应用程序进行升级，一般选择凌晨等查询流量的用户较少的时间段。

由于现有技术方案针对后台服务应用程序而言，若升级失败，则需回滚至升级前的版本，而回滚需要浪费较长的时间，低至半个小时至一个小时，高至几个小时；除此之外，即使升级的过程没有问题，若升级成功后，前端的客户端用户的体验较差时，为了保证容器集群服务对前端的用户的服务质量及维护良好的口碑，也需要将后台服务回滚至升级前的版本，也需要浪费较长的回滚时间。

综上所述，现有技术方案中缺少一种既使升级不成功也无需花费过多的时间以回滚至原来的版本的升级方案。

发明内容

本发明实施例提供一种容器集群服务应用程序升级的方法及设备，以解决现有技术中缺少一种既使升级不成功也无需花费过多的时间以回滚至原来的版本的升级方案的技术问题。

为了解决上述技术问题，本发明是这样实现的：

第一方面，根据本发明实施例提供的一种容器集群服务应用程序升级的方法，包括：

接收构建包含多个第二容器的备用容器集群的第一操作信息，并根据所述第一操作信息构建相应的备用容器集群；其中，所述备用容器集群中包含预设数量的第二容器，所述第二容器中包含运行的第一服务应用程序；

接收针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息；

根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的第三操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群；

其中，所述备用容器集群与所述主容器集群为所述前端的应用程序提供相同的服务。

优选的，在根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级之前，还包括：

将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序，并进行测试；其中，所述第二服务应用程序为所述第一服务应用程序升级后的版本；

当针对所述第二容器中的第二服务应用程序的测试结果满足要求，则将所述第二容器中运行的第二后台应用服务程序恢复至所述第一后台应用服务程序；

所述根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，包括：

当针对第二服务应用程序的测试结果满足要求，则将所述第一容器中运行的第一服务应用程序升级为所述第二服务应用程序。

优选的，所述主容器集群中的第一容器之间相互隔离，所述根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，包括：

每次升级预设数量的第一容器中运行的第一服务应用程序，以完成对主容器集群中包含的第一容器中的运行的第一服务应用程序进行升级。

优选的，将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序，并进行测试，包括：

将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序后，采用预设应用程序与升级后的备用集群进行通信；

根据所述备用服务集群向所述预设应用程序反馈的响应消息的内容，和/或所述预设应用程序接收到所述响应消息所需要的时间确定是否通过测试；其中，所述响应消息是所述备用集群在接收到所述预设应用程序发送的通信数据后反馈的消息。

优选的，所述第二容器之间相互隔离，

所述将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序，包括：

每次升级第二数量的第二容器中运行的第一服务应用程序，以完成对备用容器集群中包含的第二容器中的运行的第一服务应用程序进行升级；

所述将所述第二容器中运行的第二后台应用服务程序恢复至所述第一后台应用服务程序，包括：

每次恢复第三数量的第二容器中运行的第二服务应用程序，以完成对备用容器集群中包含的第二容器中运行的第二服务应用程序的恢复。

优选的，所述获取切换容器集群的操作信息，包括：

若获取到前端发送的切换容器集群的第三操作信息，则将提供服务的服务端口由第一端口切换为第二端口；

若获取到后台发送的切换容器集群的第四操作信息，则将备用容器集群切换至与前端连通的容器集群；

其中，第一端口为主容器集群为前端的应用程序提供的服务端口，第二服务端口为备用容器集群为前端的应用程序提供的服务端口。

优选的，所述若升级失败，包括：

若任意一个第一容器中运行的第一服务应用程序升级失败，则确定根据所述第二操作对所述第一容器中运行的第一服务应用程序升级失败。

第二方面，根据本发明实施例提供的一种容器集群服务应用程序升级的方法，其特征在于，包括：

接收模块，用于接收针对构建备用容器集群的第一操作信息，及接收针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息；

构建模块，用于根据所述第一操作信息构建相应的备用容器集群；其中，所述备用容器集群中包含预设数量的第二容器，所述第二容器中包含运行的第一服务应用程序；

控制模块，用于根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。

第三方面，根据本发明实施例提供的容器集群服务应用程序升级的设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述任一项所述的方法的步骤。

第四方面，根据本发明实施例提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法的步骤。

在本发明实施例中，在对主容器集群中的第一容器中运行的第一服务应用程序进行升级之前，首先接收第一操作信息，并根据第一操作信息构建备包括多个第二容器的备用容器集群，同时，所述第二容器中运行有第一服务应用程序；当接收到针对升级的第二操作信息时，根据所述第二操作信息对第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的第三操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。本技术方案，在针对第一容器中运行的第一服务应用程序升级失败时，只需要获取切换容器集群的第三操作信息，在获取到第三操作信息后，将备用容器集群切换至为前端的应用程序提供服务的容器集群。而备用容器集群中的第二容器中运行有第一服务应用程序，因此，备用容器集群可以提供与升级前的主容器集群相同的服务，而通过修改服务端口将备用容器集群切换至为前端的应用程序提供服务的容器集群的时间比回滚至原来的版本的时间短得多，因此，本方案有效保障了后台服务的质量。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明的一个实施例提供的一种容器集群服务应用程序升级的方法的流程图；

图2是本发明一个实施例提供的另外一种容器集群服务应用程序升级的流程图；

图3为本发明一个实施例中主容器集群、备用容器集群中的容器中的应用程序升级前后的版本的对比图；

图4是本发明一个实施例提供的一种容器集群服务应用程序升级的设备的结构示意图；

图5是实现本发明各个实施例的一种容器集群服务应用程序升级的设备的硬件结构示意图。

具体实施方式

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

图1为本发明一个实施例中提供的一种容器集群服务应用程序升级的方法的流程图，可包括如下步骤：

步骤S102、接收构建包含多个第二容器的备用容器集群的第一操作信息，并根据所述第一操作信息构建相应的备用容器集群；其中，所述备用容器集群中包含预设数量的第二容器，所述第二容器中包含运行的第一服务应用程序；

在本发明实施例中，在接收到构建包含多个第二容器的备用容器集群的第一操作之后，根据所述第一操作生成包含多个第二容器的备用容器集群。由于备用容器集群是作为在对主容器集群中的第一容器中运行的第一应用程序升级失败时的第二容器，因此，构建的备用容器集群中的第二容器的数量与主容器集群中的第一容器的数量优选相同；除此之外，构建的备用容器集群中的每个第二容器中均包含有正在运行的第一服务应用程序；并且，优选，构建的备用集群中的第二容器与前端的用户端之间的对应关系与主容器集群中的第一容器与前端的用户端之间的对应关系相同。

步骤S104、接收针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息；

在本发明实施例中，优选在接收所述针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息之前，构建备用容器集群。在本发明实施例中，其中所述第二操作信息可以由后台的操作人员触发并发送，而且后续的升级过程也可也由后台的操作人员参与。

步骤S106、根据所述第二操作对所述第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。

在本发明实施例中，若第一容器中运行的第一后台服务应用升级失败，则接收切换容器集群的操作信息，然后根据切换容器集群的操作信息，将备用容器集群切换至为前端提供服务的容器集群，基于备用容器集群与主容器集群可以为前端提供相同的服务，因此，当将备用集群切换至为前端应用提供服务的容器集群之后，很快便可同主容器集群一样，为前端的应用程序提供服务。

采用本发明实施例的方法对容器集群中的服务应用程序进行升级时，即使升级失败，只需要将为前端的应用程序提供服务的集群切换为备用容器集群，便可与主容器集群为前端的应用程序提供相同的服务，本方案，省去了现有技术方案中升级失败后需要回滚至原来的版本所耗费的时间。

在本发实施例中，在步骤S104之前，还包括：

步骤S1031、将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序，并进行测试；其中，所述第二服务应用程序为所述第一服务应用程序升级后的版本；

在本发明实施例中，在对第一容器中运行的第一服务应用程序进行升级之前(生产前测试阶段)，首先将第二容器中运行的第一服务应用程序升级为第二服务应用程序，并对升级后的备用容器集群进行测试。如果测试通过，则表明第一服务应用程序可以备升级为第二服务应用程序，在一定范围内保证了主容器集群升级成功并可为前端的应用程序提供服务的概率。

步骤S1032、当针对所述第二容器中的第二服务应用程序的测试结果满足要求，则将所述第二容器中运行的第二后台应用服务程序恢复至所述第一后台应用服务程序；

在本发明实施例中，当将第二容器中运行的第一服务应用程序升级为第二服务应用程序之后，对升级后的备用集群中的第二容器进行测试，在测试通过之后，将第二容器中运行的第二后台应用服务程序恢复至所述第一后台应用服务程序，以在第一容器中的第一服务应用程序升级失败时通过备用集群中的第二容器为前端的应用程序提供服务，以有效保障后台的容器集群为前端的应用程序提供的服务的质量。

在本发明实施例中，所述步骤S106，包括：

如图3所示，本发明实施例中，主容器集群中的服务应用程序在升级过程执行后升级为第二服务应用程序，而备用容器集群中的服务应用程序在升级至第二服务应用程序并测试同后，恢复至第一服务应用程序，当需要为前端的客户端提供服务时，仅需将为前端的客户端提供服务的容器集群切换至备用容器集群。

在本发明实施例中，若针对第二容器中的第一服务应用程序升级为第二服务应用程序的测试结果满足要求，则表明第二容器当前的环境满足升级的条件，且已经通过测试，表征在一定程度上能保证前端的应用程序的使用，此时，在执行将第一容器中运行的第一服务应用程序升级为所述第二服务应用程序的过程，在很大程度上提高了第一容器中运行的第一服务应用程序升级成功的概率。

具体的，具体的测试过程，包括：

在本发明实施例中，所述测试采用的预设应用程序在很大程度上模拟前端的应用程序，并可以模拟前端应用程序与后台提供服务的备用容器集群建立通信连接。在预设应用程序与备用服务集群建立通信连接之后，便可以模仿客户端调用第二容器中运行的第二服务应用程序，可以向备用服务集群发送通信消息，如流量查询消息，则可根据反馈的响应消息的内容或者从预设应用程序发送通信消息到接收到所述响应消息的时间判断是否能通过测试。

在本发明实施例中，所述主容器集群中的第一容器之间相互隔离，根据所述第二操作对所述第一容器中运行的第一服务应用程序进行升级，包括：每次升级预设数量的第一容器中运行的第一服务应用程序，以完成对主容器集群中包含的第一容器中的运行的第一服务应用程序进行升级。

在本发明实施例中，主容器集群、备用容器集群可以是基于K8S(kubernetes，简称K8S，是用8代替8个字符“ubernete”而成的缩写。是一个开源的、用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署、规划、更新及维护的一种机制。)平台建立的，而docker容器与K8S平台结合，可提供容器集群的自动化的管理功能，而docker容器通过namespace(命名空间)实现应用之间的隔离，同时每个应用与操作系统宿主机之间相互隔离，且相互不影响。

本发明实施例的主容器集群、备用容器集群是基于Kubernetes容器平台在同一物理环境下构建的，而docker namespace的机制使应用程序之间相互隔离，K8S实现的是应用集群之间的隔离，因此，本方案可以同时集成可提供相同服务的主集群与备用集群，即实现多租户的功能，而且容器相比于虚拟机更轻量，容器可以在服务器之间迁移，因此，后台服务采用本发明实施例的容器集群的方法，可以实现更高的服务器效率。

基于docker容器与K8S(kubernetes)结合的平台采用namespace机制，使得本发明实施例中的多个第一容器之间相互隔离。因此，对主容器集群中的多个第一容器中运行的第一服务应用程序进行升级的方案，可以采用平滑式升级，即每次升级一部分第一容器中运行的第一服务应用程序，如此升级，即使升级过程中有少量用户调用后台的主容器集群中的第一服务应用程序，对调用第一服务应用程序的用户并无影响，使得前端的应用程序无感知，有效保障了良好的用户体验。平滑式升级的具体方法可为：每次升级主容器集群的第一数量的第一容器，如1个，2个或3个等。在对该预设数量的第一容器中的第一服务应用程序升级时，不影响该主容器集群中的其他第一容器中的第一服务应用程序被正常调用，而等该预设数量的主容器集群升级完成后，再执行下一个预设数量的主容器集群的升级过程，如此循环，直至主容器集群中的所有的第一容器中的第一服务应用程序被升级完毕。

在本发明实施例中，所述第二容器之间相互隔离，

具体地，采用平滑式升级的方法对第二容器中运行的第一服务应用程序进行升级，具体地，平滑式升级的方法已在上述进行了具体阐述，在此不予赘述。

具体地，恢复的过程也可类似上述的平滑式升级的方案，进行平滑式恢复，即，每次恢复第三数量的第二容器中的运行的第二服务应用程序，直至备用容器集群中所有第二容器中运行的第二服务应用程序均恢复至第一服务应用程序。

在本发明实施例中，步骤S106中，所述接收修改服务端口的操作信息，包括：

在本发明实施例中，主容器集群与备用容器集群为前端的客户端提供服务的IP地址可以是相同的，不同的是服务端口，具体表现为不同的服务端口号，因此，当升级失败后，切换容器集群的方法可为如下两种的任意一种：

1)前端的操作人员发送切换容器集群的第三操作信息，则可通过切换为前端的应用程序提供服务的端口号将为前端的应用程序提供服务的主容器集群切换为备用容器集群；或者是即使升级成功后，当前端的客户端的用户体验不满意时，如发送查询消息后获取到反馈的响应消息的时间过长等发送反馈消息给前端的操作人员，或者是前端的操作人员通过监控发现前端的用户体验不好时，也可以发送切换容器集群的第三操作信息，进而将备用容器集群切换至为前端的客户端提供后台服务的服务集群。基于在后端的操作人员在对主容器集群中的第一容器中运行的第一服务应用程序升级失败时，直接将备用集群切换至为前端的客户端提供服务的容器集群，并未对主容器集群做任何修改，因此，本申请方案完好的保留了升级失败的第一容器中运行的第一服务应用程序，便于后续相关人员查找升级失败的原因。

2)作为另外一种实施方式，将为备用容器集群切换至为前端的客户端提供服务的容器集群也可以通过后端发送切换容器集群的第四操作信息来完成，具体为：后端操作人员发送切换容器集群的第四操作信息，通过脚本文件中的提供服务的容器集群和原有服务端口之间建立的映射关系，直接将备用容器集群切换至为前端的客户端提供服务的容器集群，而不改变容器集群对前端提供服务的端口号，可以有效保障前端用户无感知，保障了良好的用户体验。

在本发明实施例中，若通过前端发送第三操作信息切换提供服务的容器集群需要的时间为第一时间；而通过后端发送第四操作信息切换提供服务的容器集群需要的时间为第二时间，基于后端操作人员可通过调用相应的K8S脚本文件中的提供服务的容器集群和原有服务端口之间建立的映射关系，直接将备用容器集群切换为为前端提供服务的容器集群，而无需通过切换提供服务的端口号来切换提供服务的容器集群，因此，第二时间小于第一时间。基于后端的操作人员切换为前端提供服务的容器集群需要的时间较短，因此，在前端的操作人员与后端的操作人员均可切换为前端提供服务的容器集群时，可优先选择后端的操作人员切换为前端提供服务的容器集群的方式，从而有效保障了切换服务集群的高效率，保障了良好的用户体验。

在本发明实施例中，若根据所述第二操作信息对所述第一容器中运行的第一服务应用程序升级失败，包括：

在本发明实施例中，对所述升级失败的定义并非是局限于上述在任意一个容器中运行的第一服务应用程序未升级成功，还可以是表面上看是升级成功了，但前端的客户端的用户体验不满足要求等。

本发明实施例提供的容器集群服务应用程序升级的方法，在对主容器集群中的第一容器中运行的第一服务应用程序进行升级之前，首先接收第一操作信息，并根据第一操作信息构建备包括多个第二容器的备用容器集群，同时，所述第二容器中运行有第一服务应用程序；当接收到针对升级的第二操作信息时，根据所述第二操作信息对第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。本技术方案，在针对第一容器中运行的第一服务应用程序升级失败时，只需要获取切换容器集群的操作信息，在获取到第三操作信息后，将备用容器集群切换至为前端的应用程序提供服务的容器集群。而备用容器集群中的第二容器中运行有第一服务应用程序，因此，可以提供与升级前的主容器集群相同的服务，而通过修改服务端口将备用容器集群切换至为前端的应用程序提供服务的容器集群的时间比回滚至原来的版本的时间短得多，因此，本方案有效保障了后台的容器集群为前端的应用程序提供的服务的质量。

图4是本发明一个实施例提供的一种容器集群服务应用程序升级的设备的结构示意图。如图4所示的设备，可以包括：

接收模块41，用于接收针对构建备用容器集群的第一操作信息，及接收针对主容器集群中的第一容器中运行的第一服务应用程序进行升级的第二操作信息；

构建模块43，用于根据所述第一操作信息构建相应的备用容器集群；其中，所述备用容器集群中包含预设数量的第二容器，所述第二容器中包含运行的第一服务应用程序；

控制模块45，根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。

在一个实施例中，还包括：

备用容器集群升级模块，用于将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序；

测试模块，用于对所述备用容器集群中的第二服务应用程序进行测试；

备用容器集群还原模块，用于当针对所述第二容器中的第二服务应用程序的测试结果满足要求，则将所述第二容器中运行的第二后台应用服务程序恢复至所述第一后台应用服务程序；

所述控制模块，还用于：

针对第二服务应用程序的测试结果满足要求，则将所述第一容器中运行的第一服务应用程序升级为所述第二服务应用程序。

在一个实施例中，所述主容器集群中的第一容器之间相互隔离，控制模块，还用于：

在一个实施例中，所述测试模块，还用于：

在一个实施例中，所述第二容器之间相互隔离，

所述备用容器集群升级模块，还用于：

所述备用容器集群还原模块，还用于：

在一个实施例中，所述控制模块，还用于：

在一个实施例中，所述若升级失败，包括：

本发明实施例提供的容器集群服务应用程序升级的设备能够实现图1至图2的方法实施例中移动终端实现的各个过程，为避免重复，这里不再赘述。

本发明实施例提供的容器集群服务应用程序升级的设备，在对主容器集群中的第一容器中运行的第一服务应用程序进行升级之前，首先接收第一操作信息，并根据第一操作信息构建备包括多个第二容器的备用容器集群，同时，所述第二容器中运行有第一服务应用程序；当接收到针对升级的第二操作信息时，根据所述第二操作信息对第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群。本技术方案，在针对第一容器中运行的第一服务应用程序升级失败时，只需要获取切换容器集群的操作信息，便可将备用容器集群切换至为前端的应用程序提供服务的容器集群。而备用容器集群中的第二容器中运行有第一服务应用程序，备用容器集群与升级前的主容器集群可为前端的应用程序提供相同的服务，因此，可以提供与升级前的主容器集群相同的服务，而通过修改服务端口将备用容器集群切换至为前端的应用程序提供服务的容器集群的时间比回滚至原来的版本的时间短得多，因此，本方案有效保障了后台服务的质量。

相应于本发明实施例提供的容器集群服务应用程序升级的方法、设备，本发明实施例提供一种容器集群服务应用程序升级的设备的硬件结构，参见图5所示，容器集群服务应用程序升级的设备包括处理器510、收发机520、存储器530和总线接口。其中：

在本发明实施例中，容器集群服务应用程序升级的设备500还包括：存储在存储器530上并可在所述处理器510上运行的计算机程序，所述计算机程序被所述处理器510执行时实现上述图1所示的方法中的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

在图5中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器510代表的一个或多个处理器和存储器530代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机520可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。

处理器510负责管理总线架构和通常的处理，存储器530可以存储处理器510在执行操作时所使用的数据。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。。

Claims

1.一种容器集群服务应用程序升级的方法，其特征在于，包括：

接收构建包含多个第二容器的备用容器集群的第一操作信息，并根据所述第一操作信息构建相应的备用容器集群；其中，所述第二容器中包含运行的第一服务应用程序；

根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，若升级失败，则获取切换容器集群的操作信息，以将所述备用容器集群切换至为前端的应用程序提供服务的容器集群；

2.根据权利要求1所述的方法，其特征在于，在根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级之前，还包括：

3.根据权利要求2所述的方法，其特征在于，所述主容器集群中的第一容器之间相互隔离，所述根据所述第二操作信息对所述第一容器中运行的第一服务应用程序进行升级，包括：

4.根据权利要求2所述的方法，其特征在于，将所述第二容器中运行的第一服务应用程序升级为第二服务应用程序，并进行测试，包括：

5.根据权利要求2所述的方法，其特征在于，所述第二容器之间相互隔离，

6.根据权利要求1-5所述的方法，其特征在于，所述获取切换容器集群的操作信息，包括：

7.根据权利要求1-5任一项所述的方法，其特征在于，所述若升级失败，包括：

8.容器集群服务应用程序升级的设备，其特征在于，包括：

9.容器集群服务应用程序升级的设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法的步骤。