CN113741923A - 一种应用更新方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种应用更新方法、装置、设备及介质，该方法包括：当集群中包括至少一个第一Pod，且在每个第一Pod上部署有用于运行旧的目标应用的第一容器时，在接收到用于请求更新目标应用的应用更新请求之后，在各第一Pod上创建用于运行更新后的目标应用的第二容器，以使更新后的目标应用替代旧的目标应用，如此实现对集群上的目标应用进行更新的目的。可见，在对集群上的任一应用进行更新时，只需通过在该应用对应的原有Pod上创建用于运行更新后应用的新容器即可，如此能够有效地简化应用更新操作，从而提高了应用更新效率。

Description

一种应用更新方法、装置、设备及介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种应用更新方法、装置、设备及介质。

背景技术

目前，通常将部署于集群上的应用进行容器化处理，以使部署于集群上的应用能够与集群自身配置(如底层设施或文件系统等配置)解耦，从而使得该应用能够在不同集群或不同操作系统上进行迁移。

在包括多个节点的集群中，各节点上可以部署有容器部署单元Pod，而且各Pod上可以部署有各应用对应的容器。例如，集群包括第1个节点和第2个节点，第1个节点上部署有第1个Pod，第2个节点上部署有第2个Pod和第3个Pod，第1个Pod上部署有第1个容器和第2个容器，第2个Pod上部署有第3个容器和第4个容器，第3个Pod上部署有第5个容器，第1个容器至第4个容器均用于运行第1个应用，而且第5个容器用于运行第2个应用。

在一些情况下，需要对集群上的应用进行更新，以使集群上的应用能够更好的为用户提供业务服务。然而，因集群上的应用更新操作比较繁琐，导致应用更新效率较低。

发明内容

基于此，本申请实施例提供了一种应用更新方法、装置、设备及介质，能够简化应用更新操作，提高应用更新效率。

第一方面，本申请实施例提供了一种应用更新方法，该方法适用于对集群上的任一应用进行更新，而且该方法具体包括：当集群中包括至少一个第一Pod，且在每个第一Pod上部署有用于运行旧的目标应用的第一容器时，在接收到用于请求更新目标应用的应用更新请求之后，在各第一Pod上创建用于运行更新后的目标应用的第二容器，以使更新后的目标应用替代旧的目标应用，如此实现对集群上的目标应用进行更新的目的。可见，在对集群上的任一应用进行更新时，只需通过在该应用对应的原有Pod上创建用于运行更新后应用的新容器即可，如此能够有效地简化应用更新操作，从而提高了应用更新效率。

在一些可能的实现方式中，在接收到应用更新请求之后，先获取用于指定第二容器的Pod模板，再按照该Pod模板指定的第二容器，在各第一Pod上创建第二容器。其中，因Pod模板能够指定第二容器，使得在各第一Pod上创建第二容器时，直接根据Pod模板指定的第二容器进行创建即可，无需在各第一Pod上分别依据上述应用参数创建第二容器，如此能够减少在各第一Pod上创建第二容器的耗时，从而能够提高集群中应用的更新效率。

在一些可能的实现方式中，在接收到应用更新请求之后，先从集群中所有Pod中选择与该Pod模板匹配的Pod，并将选出的Pod确定为第一Pod；再在各第一Pod上创建第二容器。其中，因各第一Pod是预先基于Pod模板从集群中所有Pod中筛选得到的，使得后续可以只在这些筛选出的第一Pod执行应用更新过程的其他步骤，无需考虑集群中除了第一Pod以外的其他Pod，如此有利于提高目标应用的创建效率。

在一些可能的实现方式中，为了节约Pod空间，在第一Pod上创建完成第二容器之后，删除第一Pod上用于运行旧的目标应用的第一容器，以使第一Pod上只部署有目标应用的最新容器，不再部署有目标应用的历史容器，如此能够有效地节约Pod空间。

在一些可能的实现方式中，应用更新请求携带有更新后的目标应用的应用参数，所述应用参数包括应用版本信息和/或应用配置信息。

在一些可能的实现方式中，当存在多种类型的应用更新过程对集群中应用进行更新时，先通过图形用户界面(GUI)接收用户指定的目标应用的应用更新类型，并确定对应于该应用更新类型的应用更新过程，再按照该确定的应用更新过程对集群中目标应用进行更新。如此能够实现按照用户需求更新目标应用，从而有利于提高用户体验。

第二方面，本申请提供了一种应用更新装置，该装置包括：运行模块、通信模块和更新模块。其中，运行模块用于在第一容器部署单元(Pod)上运行旧的目标应用的第一容器；通信模块用于接收应用更新请求；更新模块用于在第一Pod上创建用于运行更新后的目标应用的第二容器，以替代旧的目标应用。

在一些可能的实现方式中，更新模块还用于：获取Pod模板，Pod模板指定第二容器。

在一些可能的实现方式中，该装置还包括：

选择模块，用于从多个Pod中选择与Pod模板匹配的Pod，选出的Pod为第一Pod。

在一些可能的实现方式中，更新模块还用于：在第一Pod上删除第一容器。

在一些可能的实现方式中，应用更新请求携带有更新后的目标应用的应用参数，应用参数包括应用版本信息和/或应用配置信息。

在一些可能的实现方式中，通信模块还用于：通过图形用户界面(GUI)接收用户指定的应用更新类型，具有应用更新类型的应用为待更新的目标应用。

第三方面，本申请提供了一种计算机，所述计算机包括处理器和存储器。所述处理器和所述存储器链接。所述处理器用于执行所述存储器中存储的指令，以使得计算机执行如第一方面或第一方面的任一种实现方式中的应用更新方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质包括指令，所述指令指示计算机执行上述第一方面或第一方面的任一种实现方式所述的应用更新方法。

第五方面，本申请提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的任一种实现方式所述的应用更新方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的k8s集群的结构示意图；

图2为本申请实施例提供的k8s的结构示意图；

图3为本申请实施例提供的应用更新方法的系统架构图；

图4为本申请实施例提供的一种应用更新方法的流程图；

图5为本申请实施例提供的应用于k8s的应用更新方法流程图；

图6为本申请实施例提供了一种计算机的结构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请提供的实施例中的方案进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。

为了便于理解本申请的技术方案，下面对本申请涉及的一些技术术语进行介绍。

kubernetes(简称k8s)是谷歌开源的容器编排调度引擎，用于管理集群中各节点上的容器化的应用。k8s包括管理(master)组件和节点(node)组件。其中，master组件可以在集群中任一节点上运行，而且master组件用于对集群进行控制管理。node组件可以在集群中任一节点上运行，而且node组件用于为节点提供k8s运行环境并用于维护该节点上的容器部署单元(也就是，Pod)。例如，如图1所示，当集群包括管理节点和N个应用节点时，则master组件可以在管理节点上运行，以使部署有master组件的管理节点能够管理控制该集群；而且每个应用节点上均可以运行node组件，以使每个应用节点上运行的node组件用于维护该节点上的Pod。

master组件包括接口服务器(也就是，kube-apiserver)、管理控制器(也就是，kube-controller-manager)和存储系统(如etcd)。其中，etcd用于保存所有集群数据。kube-apiserver为资源操作的唯一入口，以使用户和k8s中任一组件均是借助kube-apiserver通信实现对相关资源进行操作(如图2所示)。kube-controller-manager用于维护集群中各应用的应用状态，而且该kube-controller-manager是master组件中众多控制器的集合，该集合包括无状态应用控制器(也就是，Deployment Controller)和副本集合控制器(也就是，Replicaset Controller)。Deployment Controller用于维护Deployment资源状态；Replicaset Controller用于维护Replicaset资源状态，而且ReplicasetController能够根据Pod模板在至少一个节点上创建该Pod模板对应的Pod副本。

需要说明的是，在k8s中，Deployment用于为Pod和ReplicaSet提供声明式更新，也就是，用户只需要在Deployment中描述Pod和/或Replicaset的目标状态，则DeploymentController会控制Pod和Replicaset的实际状态改变成上述目标状态。Replcaset是指Pod副本集合。

node组件包括代理组件(也就是，kubelet)和运行组件(也就是，docker)。其中，kubelet用于维护节点中的Pod以及Pod上的容器。docker用于在Pod上运行容器。

Pod是k8s中用于创建、调度和管理的最小单位。另外，每个Pod上均可以部署有至少一个容器；而且，部署在同一Pod上的容器通常对应于同一个应用，也就是，一个Pod上部署的所有容器均用于运行相同应用。例如，若容器1和容器2均部署在Pod1上，则容器1和容器2通常用于运行相同应用。

另外，为了便于理解本申请的技术方案，下面对用于更新集群中应用的相关技术进行介绍。

在相关技术中，可以采用删除重建Pod的方式(例如，k8s中的Recreate Update方式或Rolling Update方式)来更新集群中应用，其具体为：当需要更新目标应用时，可以先在集群节点中创建新Pod，且该新Pod上部署有用于运行更新后的目标应用的容器，再将集群节点中已部署的旧Pod删除，且该旧Pod上部署有用于运行旧的目标应用的容器。例如，假设用于运行旧的目标应用的容器部署在Pod1、Pod2和Pod3上，而且用于运行更新后的目标应用的容器部署在Pod4、Pod5和Pod6上。基于该假设可知，当需要更新目标应用时，可以在集群中创建Pod4、Pod5和Pod6，并在集群中删除Pod1、Pod2和Pod3，以使集群中能够运行更新后的目标应用。

需要说明的是，本申请实施例不限定多个Pod创建和多个Pod删除的执行顺序，可以先创建所有新Pod再删除所有旧Pod，如k8s中的Recreate Update方式；也可以先创建第1批新Pod并删除第1批旧Pod，再创建第2批新Pod并删除第2批旧Pod，……(直至完成所有新Pod的创建以及所有旧Pod的删除工作)，如k8s中的Rolling Update方式。

基于上述相关技术提供的应用更新过程可知，因上述应用更新过程是借助Pod的删除再重建过程实现的，使得更新前应用对应的Pod和更新后应用对应的Pod不同，从而使得更新前应用对应Pod基本信息(如Pod名称、Pod名称标识、Pod的IP地址、Pod所处节点的节点信息等)不同于更新后应用对应Pod基本信息，导致集群中应用(尤其是那些对Pod基本信息具有强依赖性的应用)易因Pod基本信息的变动而出现异常(如应用无法正常运行等异常)。

为了解决上述相关技术存在的缺点，本申请实施例提供了一种应用更新方法，该方法具体包括：当集群中包括至少一个第一Pod，且在每个第一Pod上均部署有用于运行旧的目标应用的第一容器时，在接收到用于请求更新目标应用的应用更新请求之后，在各第一Pod上创建用于运行更新后的目标应用的第二容器，以使更新后的目标应用替代旧的目标应用，如此实现对集群上的目标应用进行更新的目的。其中，因该应用更新过程是通过在原有Pod上重建更新后应用对应的容器的方式实现的，使得旧的目标应用对应的容器和更新后的目标应用对应的容器均位于同一个Pod上，从而使得目标应用对应的Pod基本信息在应用更新过程中始终保持不变，如此能够避免因集群上的应用(尤其是那些对Pod基本信息具有强依赖性的应用)易因Pod基本信息的变化而发生异常。

为了便于理解本申请的技术方案，下面结合图3对本申请实施例提供的应用更新方法的应用场景进行示例性介绍。其中，图3为本申请实施例提供的应用更新方法的系统架构图。

图3所示的应用场景包括应用更新装置301、图形用户界面(Graphical UserInterface，GUI)302和用户303。其中，应用更新装置301部署于集群中，且应用更新装置301通过执行本申请实施例提供的应用更新方法对集群中应用进行更新。GUI302用于接收用户303输入的数据信息以及触发的指令请求。

在图3所示的应用场景中，当用户303想要更新目标应用时，用户303可以在GUI302上触发用于请求更新目标应用的应用更新请求，以使GUI302将该应用更新请求发送至应用更新装置301，使得应用更新装置301在第一Pod上创建用于运行更新后的目标应用的第二容器，如此能够实现在集群中利用更新后的目标应用替代旧的目标应用的目的。其中，第一Pod是指部署有用于运行旧的目标应用的第一容器的Pod。

另外，应用更新装置301包括运行模块3011、更新模块3012和通信模块3013。其中，运行模块3011用于在集群节点上运行容器，例如，运行模块3011用于在第一Pod上运行旧的目标应用的第一容器。通信模块3013用于接收用户303通过GUI302发送的信息(如数据信息、指令请求等信息)，例如，通信模块3013用于接收应用更新请求。更新模块3012用于对集群中应用进行更新，例如，更新模块3012可以用于在第一Pod上创建用于运行更新后的目标应用的第二容器，以替代旧的目标应用。

另外，本申请实施例不限定GUI302。在一种可能的实施方式中，GUI302是终端设备，例如，GUI302可以是智能手机、计算机、个人数字助理(Personal Digital Assitant，PDA)或平板电脑等终端设备。

为了使得本申请实施例的技术方案更加清楚、易于理解，下面结合图3所示的应用场景中的交互过程对本申请实施例提供的应用更新方法进行具体介绍。其中，图4为本申请实施例提供的一种应用更新方法的流程图，如图4所示，本申请实施例提供的应用更新方法，包括S401-S403：

S401：应用更新装置301在第一Pod上运行旧的目标应用的第一容器。

第一容器是指集群中用于运行旧的目标应用(也就是，更新前的目标应用)的容器。

第一Pod是指集群中部署有第一容器的Pod，而且本申请实施例不限定第一Pod的个数，也不限定每个第一Pod上部署的第一容器的个数。

基于上述内容可知，本申请实施例中，当用户303通过GUI302触发应用运行请求，且该应用运行请求用于请求运行旧的目标应用时，GUI302将该应用运行请求发送给应用更新装置301，以使应用更新装置301在集群中的第一Pod上运行旧的目标应用的第一容器。作为示例，假设集群包括节点1、节点2和节点3，节点1上部署有Pod1、Pod2和Pod3，节点2上部署有Pod3和Pod4，节点3上部署有Pod5，Pod1、Pod2和Pod5上均部署有第一容器。基于该假设可知，因Pod1、Pod2和Pod5上均部署有第一容器，使得Pod1、Pod2和Pod5均是第一Pod，故在应用更新装置301接收到上述应用运行请求之后，该应用更新装置301可以在Pod1、Pod2或Pod5上运行第一容器，以实现在集群中运行旧的目标应用。

S402：应用更新装置301接收应用更新请求。

应用更新请求用于请求更新目标应用，而且应用更新请求是由用户303通过GUI302触发的。

另外，本申请实施例不限定应用更新请求携带的信息。下面结合两种示例进行说明。

示例一，应用更新请求携带有更新后的目标应用的应用参数，且该应用参数包括应用版本信息和/或应用配置信息。

具体地，当应用更新请求用于请求将目标应用的当前版本更新为目标版本时，则该应用更新请求携带有该目标版本的应用版本信息(也就是，更新后的目标应用的版本信息)；当应用更新请求用于请求将目标应用的当前应用配置信息更新为目标应用配置信息时，则该应用更新请求携带有该目标应用配置信息(也就是，更新后的目标应用的应用配置信息)；当应用更新请求用于请求将目标应用的当前版本更新为目标版本，并将目标应用的当前应用配置信息更新为目标应用配置信息时，则该应用更新请求携带有目标应用配置信息和该目标版本的应用版本信息。

示例二，当应用更新装置301可以采用多种类型的应用更新过程对集群中应用进行更新时，应用更新请求可以携带有应用更新类型和更新后的目标应用的应用参数。其中，应用更新类型是由用户303通过GUI302指定的，而且应用更新装置301能够根据该应用更新类型确定更新目标应用时所使用的应用更新过程。如此，应用更新装置301不仅能够从该应用更新请求中提取出更新后的目标应用的应用参数，还能够从该应用更新请求中提取出更新目标应用所使用的应用更新过程的选择信息。

基于上述内容可知，本申请实施例中，当用户303通过GUI302触发应用更新请求，且该应用更新请求用于请求更新目标应用时，GUI302将该应用更新请求发送给应用更新装置301，以使该应用更新装置301能够基于该应用更新请求携带的信息对集群中的目标应用进行更新。

S403：应用更新装置301在第一Pod上创建用于运行更新后的目标应用的第二容器，以替代旧的目标应用。

第二容器是指集群中用于运行更新后的目标应用的容器。

本申请实施例中，在应用更新装置301获取到应用更新请求之后，应用更新装置301利用该应用更新请求携带的应用参数，在各第一Pod上创建第二容器，以使在各第一Pod上利用更新后的目标应用替代旧的目标应用。作为示例，当集群中包括Pod1、Pod2和Pod5，且Pod1、Pod2和Pod5上均部署有第一容器时，Pod1、Pod2和Pod5上均为第一Pod，而且S403具体为：应用更新装置301在Pod1上创建第二容器、在Pod2上创建第二容器、以及在Pod5上创建第二容器，以使后续应用更新装置301通过运行Pod1上的第二容器、Pod2上的第二容器或者Pod5上的第二容器的方式，实现在集群中运行更新后的目标应用的目的。

基于上述S401至S403的相关内容可知，在本申请实施例提供的应用更新方法中，当集群中包括至少一个第一Pod，且在每个第一Pod上部署有用于运行旧的目标应用的第一容器时，在接收到用于请求更新目标应用的应用更新请求之后，在各第一Pod上创建用于运行更新后的目标应用的第二容器，以使更新后的目标应用替代旧的目标应用，如此实现对集群上的目标应用进行更新的目的。可见，在对集群上的任一应用进行更新时，只需通过在该应用对应的原有Pod上创建用于运行更新后应用的新容器即可，如此能够有效地简化应用更新操作，从而提高了应用更新效率。另外，因该应用更新过程是通过在原有Pod上重建更新后应用对应的容器的方式实现的，使得旧的目标应用和更新后的目标应用均位于同一个Pod上，从而使得目标应用对应的Pod基本信息在应用更新过程中始终保持不变，如此能够避免因集群上的应用(尤其是那些对Pod基本信息具有强依赖性的应用)易因Pod基本信息的变化而发生异常。

在一些情况(如应用更新装置301为k8s)下，第一Pod上的第二容器可以参照Pod模板上的第二容器进行创建。基于此，本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括S401-S403以外，还包括S404：

S404：应用更新装置301获取Pod模板，该Pod模板指定上述第二容器。

Pod模板是指在节点上创建Pod以及在Pod上创建容器时需要参照的对象。例如，在k8s中，可以将Pod模板的副本部署到节点上，作为节点上Pod；也可以依据Pod模板上部署的容器，在Pod上创建相应容器，以使该Pod上部署的容器与该Pod模板上部署的容器保持一致。

另外，Pod模板可以依据更新后的目标应用的应用参数进行创建，以使该Pod模板上部署有上述第二容器，从而使得该Pod模板能够指定上述第二容器。

基于上述内容可知，本申请实施例中，在应用更新装置301接收到应用更新请求之后，应用更新装置301先根据该应用更新请求携带的更新后的目标应用的应用参数创建Pod模板，以使Pod模板上部署有第二容器；再按照Pod模板上部署的第二容器，在各第一Pod上创建第二容器，以使各第一Pod上的第二容器与Pod模板上的第二容器相同，如此实现了第二容器的创建。其中，因Pod模板能够指定第二容器，使得在各第一Pod上创建第二容器时，直接根据Pod模板指定的第二容器进行创建即可，无需在各第一Pod上分别依据上述应用参数创建第二容器，如此能够减少在各第一Pod上创建第二容器的耗时，从而能够提高集群中应用的更新效率。

另外，为了提高目标应用的更新效率，可以基于集群中各Pod与上述Pod模板匹配结果，从集群中所有Pod中筛选出各第一Pod。基于此，本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括S401-S404以外，还包括S405：

S405：应用更新装置301从多个Pod中选择与上述Pod模板匹配的Pod，选出的Pod为第一Pod。

与上述Pod模板匹配的Pod满足的条件为：该Pod上部署的容器对应的应用与Pod模板上部署的容器对应的应用之间的区别仅在于应用参数不同。例如，当应用更新装置301为k8s时，与上述Pod模板匹配的Pod满足的条件可以为：该Pod上部署有目标应用对应容器，且该Pod上部署的目标应用对应容器不同于Pod模板上部署的目标应用对应容器。

需要说明的是，步骤S405可以在执行S404之后且执行S403之前完成执行。

基于上述内容可知，本申请实施例中，应用更新装置301在获取到用于指定第二容器的Pod模板之后，先将集群中各Pod与Pod模板进行匹配，并将与Pod模板匹配成功的各Pod均确定为第一Pod，再在这些确定出的各第一Pod上创建第二容器。其中，因各第一Pod是预先基于Pod模板从集群中所有Pod中筛选得到的，使得后续可以只在这些筛选出的第一Pod执行应用更新过程的其他步骤，无需考虑集群中除了第一Pod以外的其他Pod，如此有利于提高目标应用的创建效率。

在一些情况下，可以预先将Pod上部署的容器化应用的应用标识与该Pod之间建立对应关系，以便后续能够基于该应用标识查找出部署有该容器化应用的Pod。基于此可知，本申请实施例还可以基于目标应用的应用标识，从集群中所有Pod中筛选出各第一Pod，故本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括上述部分步骤或全部步骤以外，还包括S406：

S406：应用更新装置301将多个Pod中对应于目标应用标识的Pod，确定为第一Pod。

目标应用标识用于唯一标识目标应用。另外，本申请实施例不限定目标应用标识的获取方式，例如，当应用更新请求中携带有目标应用标识的相关信息时，则应用更新装置301可以根据该应用更新请求，获得目标应用标识。

基于上述内容可知，本申请实施例中，在应用更新装置301获取到应用更新请求之后，应用更新装置301先根据应用更新请求确定目标应用标识，再从集群中所有Pod中筛选出对应于目标应用标识的各Pod，均作为第一Pod，以便后续应用更新装置301能够直接在这些确定出的各第一Pod上创建第二容器，如此有利于提高第二容器的创建效率。

另外，为了节约Pod空间，可以删除第一Pod上用于运行旧的目标应用的第一容器，以使第一Pod上不再部署有旧的目标应用对应的容器。基于此，本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括上述部分步骤或全部步骤以外，还包括S407：

S407：应用更新装置301在第一Pod上删除第一容器。

本申请实施例中，在应用更新装置301接收到应用更新请求之后，应用更新装置301可以在各第一Pod上创建第二容器并删除第一容器，以使各第一Pod上只部署有目标应用的最新容器，不再部署有目标应用的历史容器，如此能够有效地节约Pod空间。

需要说明的是，本申请实施不限定在第一Pod上删除第一容器和创建第二容器的执行顺序，例如，在任一第一Pod上，可以先删除第一容器再创建第二容器，也可以先创建第二容器再删除第一容器。

另外，本申请实施例不限定应用更新装置301在各第一Pod上删除第一容器的执行时间，下面结合两个示例进行说明。

示例一，应用更新装置301可以在所有第一Pod上均删除第一容器之后，再分别在各第一Pod上创建第二容器。例如，当Pod1、Pod2、Pod5和Pod6上均部署有第一容器时，应用更新装置301可以在Pod1上删除第一容器、在Pod2上删除第一容器、在Pod5上删除第一容器、以及在Pod6上删除第一容器之后，在Pod1上创建第二容器、在Pod2上创建第二容器、在Pod5上创建第二容器、以及在Pod6上创建第二容器。

示例二，应用更新装置301可以按照处于容器更新状态的Pod个数保持不变的模式进行第一Pod上第二容器的创建及第一容器的删除。例如，当Pod1、Pod2、Pod5和Pod6上均部署有第一容器，且应用更新装置301中处于容器更新状态的Pod个数为2时，应用更新装置301分别在Pod1和Pod2上进行容器更新(也就是，删除第一容器并创建第二容器)；当Pod1和Pod2同时完成容器更新时，应用更新装置301分别开始在Pod5和Pod6上进行容器更新；当Pod1和Pod2没有同时完成容器更新(例如，Pod1完成容器更新但Pod2未完成容器更新，或者Pod2完成容器更新但Pod1未完成容器更新)时，应用更新装置301开始在Pod5上进行容器更新，以使应用更新装置301中始终保持2个第一Pod处于容器更新状态。如此能够保证应用更新装置301中始终保持2个第一Pod处于容器更新状态。

另外，在示例二中，处于容器更新状态的Pod个数可以由用户303通过GUI302指定，可以在应用更新装置301中预先设定。

在一些情况下，应用更新装置301可以采用多种类型的应用更新过程对集群中应用进行更新，故应用更新装置301可以根据用户303通过GUI302指定的应用更新类型确定应用更新过程。基于此，本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括上述部分步骤或全部步骤以外，还包括S408：

S408：应用更新装置301通过GUI302接收用户303指定的应用更新类型，具有该应用更新类型的应用为待更新的目标应用。

本申请实施例中，当应用更新装置301通过GUI302接收到用户303指定的目标应用的应用更新类型时，应用更新装置301先根据该应用更新类型，确定对应于该应用更新类型的应用更新过程，以使后续应用更新装置301按照该确定的应用更新过程对集群中目标应用进行更新。例如，当应用更新装置301根据该应用更新类型确定的应用更新过程包括本申请实施例提供的应用更新方法任一实施方式中的步骤时，则应用更新装置301按照本申请实施例提供的应用更新方法任一实施方式更新目标应用。

在一些情况下，用户303没有通过GUI302直接指定应用更新类型，而是通过GUI302输入应用更新过程的描述信息(如应用更新过程不能变更Pod基本信息等信息)，此时，应用更新装置301可以基于这些描述信息确定出应用更新类型。基于此，本申请实施例还提供了应用更新方法的一种可能的实施方式，在该实施方式中，应用更新方法除了包括上述部分步骤或全部步骤以外，还包括S409-S412：

S409：应用更新装置301通过GUI302接收用户303输入的目标过程信息。

目标过程信息为目标应用的应用更新过程的描述信息。另外，本申请实施例不限定目标过程信息。作为示例，目标过程信息包括应用更新过程的约束条件，和/或应用更新过程中部分或全部步骤的描述信息。其中，应用更新过程的约束条件用于描述应用更新过程应该满足的限制条件，例如，应用更新过程的约束条件可以为应用更新过程不能变更Pod基本信息。

S410：应用更新装置301根据目标过程信息确定应用更新类型。

本申请实施例不限定应用更新装置301确定应用更新类型的具体实施方式，例如，S410具体可以为：应用更新装置301先获取各应用更新类型对应的预设描述信息，再将目标过程信息分别与各应用更新类型对应的预设描述信息进行匹配，确定对应于匹配度最高的预设描述信息的应用更新类型。

其中，预设描述信息是预先设定并存储在预设存储位置的，而且应用更新装置301能够从该预设存储位置获取该预设描述信息。

本申请实施例中，在应用更新装置301接收到目标过程信息之后，先从预设存储位置获取各应用更新类型对应的预设描述信息，并将各应用更新类型对应的预设描述信息与目标过程信息分别进行匹配，得到各应用更新类型对应的匹配度；再比较各应用更新类型对应的匹配度，并将对应于最高匹配度的应用更新类型，确定为最终的应用更新类型。

S411：应用更新装置301将应用更新类型通过GUI302进行显示，以使用户303确定是否选择该应用更新类型。

S412：应用更新装置301接收用户303通过GUI302输入的选择结果。

基于上述内容可知，本申请实施例中，当用户303在GUI302上输入目标过程信息时，GUI302将该目标过程信息发送给应用更新装置301，以使应用更新装置301先根据目标过程信息确定应用更新类型，再将该应用更新类型反馈给GUI302，以使GUI302将应用更新类型显示给用户303，并由用户303通过GUI302确认是否选择该显示的应用更新类型，以便GUI302将用户303的选择结果反馈给应用更新装置301，以使应用更新装置301基于该选择结果确定上述确定的应用更新类型是否为用户为目标应用指定的应用更新类型，若是，则直接利用对应于上述确定的应用更新类型的应用更新过程进行目标应用的更新；若否，则结束当前的应用更新过程或者重新向用户303推荐其他的应用更新类型。可见，因应用更新装置301能够根据用户303提供的目标过程信息自动确定应用更新类型，无需用户303直接指定应用更新类型，如此降低了用户使用应用更新装置301的技术门槛，有利于提高用户体验。

为了便于理解上述技术方案，下面结合图2和图5并以应用更新装置为k8s为例对本申请实施例提供的应用更新方法进行说明。其中，图5为本申请实施例提供的应用于k8s的应用更新方法流程图。如图5所示，本申请实施例提供的应用于k8s的应用更新方法，包括S501-S505：

S501：kube-apiserver接收用户通过GUI触发的应用更新请求，该应用更新请求用于请求更新目标应用，且该应用更新请求携带有更新后的目标应用的应用参数和用户指定的目标应用的应用更新类型。

应用更新类型与应用更新过程一一对应，且该对应关系具体为：k8s的应用更新类型包括Recreate Update类型、Rolling Update类型和InplaceRolling Update类型，而且Recreate Update类型对应于上文的Recreate Update方式，Rolling Update类型对应于上文的Rolling Update方式，InplaceRolling Update类型对应于本申请实施例提供的应用更新方法。

本申请实施例中，当k8s中的kube-apiserver通过GUI接收到应用更新请求之后，kube-apiserver可以直接将该应用更新请求携带的更新后的目标应用的应用参数和用户指定的目标应用的应用更新类型存储到etcd，以便后续k8s中的其他组件(如DeploymentController)能够使用etcd中存储的上述信息。

S502：Deployment Controller判断etcd中存储的目标应用的应用参数是否发生更新，若是，则执行S503；若否，则结束。

Deployment Controller用于通过kube-apiserver实时监控etcd中存储的数据信息(如，目标应用的应用参数)是否发生变化。

本申请实施例中，当k8s中的kube-apiserver将应用更新请求携带的更新后的目标应用的应用参数存储至etcd之后，Deployment Controller能够通过kube-apiserver监控到目标应用对应的应用参数发生更新，从而Deployment Controller需要执行S503及其后续步骤，以便完成目标应用的更新过程。

S503：在Deployment Controller确定etcd中存储的目标应用的应用更新类型为InplaceRolling Update类型时，Deployment Controller根据更新后的目标应用的应用参数，更新目标应用的Pod模板。

本申请实施例中，在Deployment Controller确定etcd中存储的目标应用的应用参数发生更新之后，Deployment Controller先根据etcd中存储的目标应用的应用更新类型，确定目标应用的应用更新过程，其具体为：当Deployment Controller确定目标应用的应用更新类型为Recreate Update类型时，则利用上文介绍的Recreate Update方式对目标应用进行更新；当Deployment Controller确定目标应用的应用更新类型为RollingUpdate类型，则利用上文介绍的Rolling Update方式对目标应用进行更新；在DeploymentController确定目标应用的应用更新类型为InplaceRolling Update类型时，则利用S503至S505对目标应用进行更新。

另外，本申请实施例不限定目标应用的Pod模板的更新过程，例如，目标应用的Pod模板的更新过程具体可以为：Deployment Controller根据更新后的目标应用的应用参数，创建目标应用的新Pod模板；Deployment Controller将目标应用的新Pod模板存储至etcd中，并将该新模板设置为目标应用的Pod模板，以使部署有第一Pod的节点上的kubelet能够基于该Pod模板更新第一Pod。

S504：Deployment Controller根据目标应用的应用标识确定各第一Pod。

在k8s中，目标应用的应用标识可以是第一标签；而且，具有第一标签的Pod上均部署有第一容器。另外，本申请实施例不限定目标应用的应用标识的确定方式，例如，可以基于上述应用更新请求中携带的目标应用的相关信息确定。

另外，在k8s中，本申请实施例不限定各第一Pod的确定方式，例如，可以将selector字段为目标应用的应用标识的Replicaset中的各Pod副本确定为第一Pod。

需要说明的是，为了保证在容器更新过程中，目标应用对应的Replicaset能够始终包括目标应用对应的所有Pod，可以将目标应用对应的Replicaset的selector字段修改为旧的目标应用的应用标识和更新后的目标应用的应用标识，直至在确定目标应用对应的所有Pod均部署有第二容器之后，再次将目标应用对应的Replicaset的selector字段修改为更新后的目标应用的应用标识，以使Deployment Controller能够始终利用目标应用对应的Replicaset的selector字段，查询得到目标应用对应的所有Pod。

S505：各第一Pod对应的kubelet在确定该第一Pod需要更新时，在该第一Pod上创建第二容器并删除第一容器。

本申请实施例不限定kubelet确定第一Pod需要更新的具体实施方式，例如，对于每个第一Pod对应的kubelet来说，该kubelet将该第一Pod与etcd中存储的目标应用的Pod模板进行比对，在确定该第一Pod上部署的目标应用对应的容器与上述Pod模板上部署的目标应用对应的容器存在区别时，确定该第一Pod需要更新，并在该第一Pod上创建第二容器并删除第一容器，以使该第一Pod能够在第二容器中运行更新后的目标应用。为了便于理解S505，下面结合示例进行说明。

作为示例，假设集群包括节点1、节点2和节点3；节点1上部署有Pod1、Pod2和Pod3，节点2上部署有Pod3和Pod4，节点3上部署有Pod5；Pod1、Pod2和Pod5上均部署有第一容器；节点1上部署有kubelet1，节点2上部署有kubelet2，节点3上部署有kubelet3。

基于上述假设可知，当etcd中存储的目标应用的Pod模板更新完成时，kubelet1将节点1上部署的Pod1与etcd中存储的目标应用的Pod模板进行比对，并在确定Pod1上的第一容器不同于Pod模板上的第二容器时，确定Pod1需要更新，此时该kubelet1按照该Pod模板在Pod1上创建第二容器并删除第一容器，以使Pod1上部署的目标应用对应的容器与Pod模板上部署的目标应用对应的容器相同。同样，kubelet1将节点1上部署的Pod2与etcd中存储的目标应用的Pod模板进行比对，并在确定Pod2上的第一容器不同于Pod模板上的第二容器时，确定Pod2需要更新，此时该kubelet1按照该Pod模板在Pod2上创建第二容器并删除第一容器，以使Pod2上部署的目标应用对应的容器与Pod模板上部署的目标应用对应的容器相同。同样，kubelet3将节点3上部署的Pod5与etcd中存储的目标应用的Pod模板进行比对，并在确定Pod5上的第一容器不同于Pod模板上的第二容器时，确定Pod5需要更新，此时该kubelet3按照该Pod模板在Pod5上创建第二容器并删除第一容器，以使Pod5上部署的目标应用对应的容器与Pod模板上部署的目标应用对应的容器相同。如此实现了集群中目标应用的更新。

另外，在k8s中为了避免Pod空间资源不足，可以在第一Pod上先删除第一容器再创建第二容器，以使第二容器的创建过程中能够使用通过删除第一容器所释放的Pod空间资源，如此有效地避免了Pod空间资源不足的发生。

另外，在k8s中可以按照处于容器更新状态的Pod个数保持不变的模式对所有第一Pod上的容器进行更新，而且处于容器更新状态的Pod个数可以根据MaxUnavailable字段确定，例如，将MaxUnavailable字段的值确定为处于容器更新状态的Pod个数。其中，MaxUnavailable字段的值可以预先设定，也可以由用户通过GUI指定。

另外，每个节点上的docker用于运行Pod上部署的容器。例如，当节点1上部署有Pod1和docker1，且Pod1上部署有第一容器时，docker1在Pod1上运行第一容器，以使旧的目标应用能够在集群中运行。

基于上述S501至S505的相关内容可知，在k8s中，可以在原有Pod上直接删除旧的目标应用对应的容器并创建更新后的目标应用对应的容器，以使目标应用对应的Pod在目标应用的更新过程中始终保持不变，从而使得目标应用对应的Pod基本信息始终保持不变，如此能够有效地避免因集群上的应用易因Pod基本信息的变化而发生异常。

上文结合图1至图5，详细描述了本申请实施例提供的应用更新方法，下面结合附图对本申请实施例提供的应用更新装置以及相应的设备进行介绍。

如图3所示，本申请实施例提供的应用更新装置301包括：

运行模块3011，用于在第一容器部署单元(Pod)上运行旧的目标应用的第一容器；

通信模块3013，用于接收应用更新请求；

更新模块3012，用于在第一Pod上创建用于运行更新后的目标应用的第二容器，以替代旧的目标应用。

其中，运行模块3011的具体实现可以参见图4所示实施例中S401相关内容描述。通信模块3013的具体实现可以参见图4所示实施例中S402相关内容描述。更新模块3012的具体实现可以参见图4所示实施例中S403相关内容描述。

在一些可能的实现方式中，更新模块3012还用于：

获取Pod模板，Pod模板指定第二容器。

在一些可能的实现方式中，应用更新装置301还包括：

选择模块，用于从多个Pod中选择与Pod模板匹配的Pod，选出的Pod为第一Pod。

在一些可能的实现方式中，更新模块3012还用于：

在第一Pod上删除第一容器。

在一些可能的实现方式中，应用更新请求携带有更新后的目标应用的应用参数，应用参数包括应用版本信息和/或应用配置信息。

在一些可能的实现方式中，通信模块3013还用于：

通过图形用户界面(GUI)接收用户指定的应用更新类型，具有应用更新类型的应用为待更新的目标应用。

本申请实施例的应用更新装置301可对应于执行本申请实施例中描述的应用更新方法，并且应用更新装置301的各个模块/单元的上述和其它操作和/或功能分别为了实现图4、图5所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机。该计算机可以是服务器或者云服务器，具体用于实现如图3所示实施例中应用更新装置301的功能。

图6提供了一种计算机的结构示意图，如图6所示，计算机600包括总线601、处理器602、通信接口603和存储器604。处理器602、存储器604和通信接口603之间通过总线601通信。总线601可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口603用于与外部通信。例如，接收基于图遍历语言的第一查询请求，接收基于图遍历语言的第二查询请求等等。

其中，处理器602可以为中央处理器(central processing unit，CPU)。存储器604可以包括易失性存储器(volatile memory)，例如随机存取存储器(random accessmemory，RAM)。存储器604还可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)，快闪存储器，HDD或SSD。

存储器604中存储有可执行代码，处理器602执行该可执行代码以执行前述应用更新方法。

具体地，在实现图3所示实施例的情况下，且图3实施例中所描述的应用更新装置301的各模块为通过软件实现的情况下，执行图3中的运行模块3011和更新模块3012功能所需的软件或程序代码存储在存储器604中。通信模块3013功能通过通信接口603实现。通信接口603接收应用更新请求，将其通过总线601传输至处理器602，处理器602执行存储器604中存储的各模块对应的程序代码，如运行模块3011和更新模块3012对应的程序代码，从而实现在第一容器部署单元(Pod)上运行旧的目标应用的第一容器，以及在第一Pod上创建用于运行更新后的目标应用的第二容器，以替代旧的目标应用。当然，处理器602还可以执行选择模块对应的程序代码，从多个Pod中选择与与Pod模板匹配的Pod，选出的Pod为第一Pod，如此，应用更新装置301可以对第一Pod上目标应用对应的容器进行更新。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括指令，所述指令指示计算机执行上述应用于应用更新装置301的应用更新方法。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括指令，所述指令指示计算机执行上述应用于应用更新装置301的应用更新方法。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品被计算机执行时，所述计算机执行前述应用更新方法的任一方法。该计算机程序产品可以为一个软件安装包，在需要使用前述应用更新方法的任一方法的情况下，可以下载该计算机程序产品并在计算机上执行该计算机程序产品。

Claims (14)

1.一种应用更新方法，其特征在于，所述方法包括：

在第一容器部署单元(Pod)上运行旧的目标应用的第一容器；

接收应用更新请求；

在所述第一Pod上创建用于运行更新后的目标应用的第二容器，以替代所述旧的目标应用。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取Pod模板，所述Pod模板指定所述第二容器。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

从多个Pod中选择与所述Pod模板匹配的Pod，选出的Pod为所述第一Pod。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

在所述第一Pod上删除所述第一容器。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述应用更新请求携带有更新后的目标应用的应用参数，所述应用参数包括应用版本信息和/或应用配置信息。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

通过图形用户界面(GUI)接收用户指定的应用更新类型，具有所述应用更新类型的应用为待更新的所述目标应用。

7.一种应用更新装置，其特征在于，所述装置包括：

运行模块，用于在第一容器部署单元(Pod)上运行旧的目标应用的第一容器；

通信模块，用于接收应用更新请求；

更新模块，用于在所述第一Pod上创建用于运行更新后的目标应用的第二容器，以替代所述旧的目标应用。

8.根据权利要求7所述的装置，其特征在于，所述更新模块还用于：

获取Pod模板，所述Pod模板指定所述第二容器。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

选择模块，用于从多个Pod中选择与所述Pod模板匹配的Pod，选出的Pod为所述第一Pod。

10.根据权利要求7-9任一项所述的装置，其特征在于，所述更新模块还用于：

在所述第一Pod上删除所述第一容器。

11.根据权利要求7-10任一项所述的装置，其特征在于，所述应用更新请求携带有更新后的目标应用的应用参数，所述应用参数包括应用版本信息和/或应用配置信息。

12.根据权利要求7-11任一项所述的装置，其特征在于，所述通信模块还用于：

通过图形用户界面(GUI)接收用户指定的应用更新类型，具有所述应用更新类型的应用为待更新的所述目标应用。

13.一种计算机，其特征在于，所述计算机包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算机执行如权利要求1至6中任一项所述的应用更新方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，所述指令指示计算机执行如权利要求1至6中任一项所述的应用更新方法。

Images