升级应用的方法及装置与流程

1.本公开涉及升级应用领域，尤其涉及一种升级应用的方法及装置。


背景技术：

2.现有的容器运维管理平台kubernetes在基于原生的deployment机制对部署在容器内的应用进行升级时，需要不间断的将deployment所管理的一组运行有旧版本应用的 pod全部滚动地升级为运行有新版本应用的pod。如果新版本的应用有问题，通过这种方式升级会导致应用全面异常及线上业务100％受损。


技术实现要素：

3.有鉴于此，本公开提供一种升级应用的方法和装置，以有效避免应用升级时的全面异常和线上业务的100％受损。
4.第一方面，提供一种升级应用的方法，包括：运行第一deployment，所述第一 deployment用于管理第一组pod，所述第一组pod中的每个pod运行有旧版本的第一应用的容器；运行第二deployment，所述第二deployment用于管理第二组pod，所述第二组pod中的每个pod运行有新版本的所述第一应用的容器；根据所述第一deployment 和所述第二deployment，调整所述第一组pod和所述第二组pod中的pod数量，以将所述第一应用升级到所述新版本或将所述第一应用回滚至所述旧版本。
5.可选地，在所述根据所述第一deployment和所述第二deployment，调整所述第一组pod和所述第二组pod中的pod数量之前，所述方法还包括：接收第一参数，所述第一参数用于更新所述第二组pod中的pod数量的占比；根据所述第二组pod中的pod数量的占比，确定所述第一组pod和所述第二组pod中的pod数量。
6.可选地，在所述根据所述第二组pod中的pod数量的占比，确定所述第一组pod 和所述第二组pod中的pod数量之后，所述方法还包括：更新所述第一deployment的配置文件和所述第二deployment的配置文件，使得所述第一deployment的配置文件的副本字段的取值与所述第一组pod的pod数量相匹配，所述第二deployment的配置文件的副本字段的取值与所述第二组pod的pod数量相匹配；如果所述第一deployment的配置文件的副本字段的取值和/或所述第二deployment的配置文件的副本字段的取值不为0，则向deployment控制器发送deployment更新指令，以便所述deployment控制器根据所述第一deployment的配置文件对所述第一deployment进行更新和/或根据所述第二 deployment的配置文件对所述第二deployment进行更新。
7.可选地，在所述更新所述第一deployment的配置文件和所述第二deployment的配置文件之后，所述方法还包括：如果所述第一deployment的配置文件的副本字段的取值或所述第二deployment的配置文件的副本字段的取值为0，则向deployment控制器发送 deployment删除指令，以便所述deployment控制器删除所述第一deployment或所述第二deployment。
8.可选地，所述第一参数位于第一配置文件中，所述第一配置文件中还包括 deployment的配置信息，在接收到所述第一配置文件之后，所述方法还包括：确定所述第一应用关联的deployment的数量以及所述deployment的配置信息与所述第一应用关联的deployment中的最新deployment的配置信息的比较结果；如果所述第一应用关联的deployment的数量大于等于2且所述比较结果为相同，将所述第一应用关联的 deployment中的次新deployment和所述最新deployment分别设置为所述第一deployment 和第二deployment，并删除所述第一应用关联的deployment中的其余deployment；如果所述第一应用关联的deployment的数量大于等于2且所述比较结果为不同，将所述最新 deployment设置为所述第一deployment，删除所述第一应用关联的deployment中的其余 deployment，并根据所述第一配置文件中的deployment的配置信息设置所述第二 deployment。
9.可选地，所述第一应用为安全多方计算模型。
10.第二方面，提供一种升级应用的装置，包括：第一运行模块，用于运行第一 deployment，所述第一deployment用于管理第一组pod，所述第一组pod中的每个pod 运行有旧版本的第一应用的容器；第二运行模块，用于运行第二deployment，所述第二 deployment用于管理第二组pod，所述第二组pod中的每个pod运行有新版本的所述第一应用的容器；调整模块，用于根据所述第一deployment和所述第二deployment，调整所述第一组pod和所述第二组pod中的pod数量，以将所述第一应用升级到所述新版本或将所述第一应用回滚至所述旧版本。
11.可选地，所述装置还包括：接收模块，用于接收第一参数，所述第一参数用于更新所述第二组pod中的pod数量的占比；第一确定模块，用于根据所述第二组pod中的pod 数量的占比，确定所述第一组pod和所述第二组pod中的pod数量。
12.可选地，所述装置还包括：更新模块，用于更新所述第一deployment的配置文件和所述第二deployment的配置文件，使得所述第一deployment的配置文件的副本字段的取值与所述第一组pod的pod数量相匹配，所述第二deployment的配置文件的副本字段的取值与所述第二组pod的pod数量相匹配；发送模块，用于如果所述第一deployment 的配置文件的副本字段的取值和/或所述第二deployment的配置文件的副本字段的取值不为0，则向deployment控制器发送deployment更新指令，以便所述deployment控制器根据所述第一deployment的配置文件对所述第一deployment进行更新和/或根据所述第二deployment的配置文件对所述第二deployment进行更新。
13.可选地，所述发送模块还用于如果所述第一deployment的配置文件的副本字段的取值或所述第二deployment的配置文件的副本字段的取值为0，则向deployment控制器发送deployment删除指令，以便所述deployment控制器删除所述第一deployment或所述第二deployment。
14.可选地，所述第一参数位于第一配置文件中，所述第一配置文件中还包括 deployment的配置信息，所述装置还包括：第二确定模块，用于确定所述第一应用关联的deployment的数量以及所述deployment的配置信息与所述第一应用关联的deployment 中的最新deployment的配置信息的比较结果；设置模块，用于如果所述第一应用关联的 deployment的数量大于等于2且所述比较结果为相同，将所述第一应用关联的 deployment中的次新deployment和所述最新deployment分别设置为所述第一deployment 和第二
deployment，并删除所述第一应用关联的deployment中的其余deployment，所述设置模块还用于如果所述第一应用关联的deployment的数量大于等于2且所述比较结果为不同，将所述最新deployment设置为所述第一deployment，删除所述第一应用关联的 deployment中的其余deployment，并根据所述第一配置文件中的deployment的配置信息设置所述第二deployment。
15.可选地，所述第一应用为安全多方计算模型。
16.第三方面，提供一种升级应用的装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现如第一方面所述的方法。
17.第四方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面所述的方法。
18.第五方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面所述的方法。
19.本公开实施例提供了一种升级应用的方法，其分别通过第一deployment和第二 deployment管理运行有旧版本的第一应用容器的第一组pod和运行有新版本的第一应用容器的第二组pod，并可根据第一deployment和第二deployment调整第一组pod和第二组pod中的pod数量，以实现在使用第二deployment将第一应用所对应的部分pod升级到新版本的同时，可使用第一deployment将剩余的pod保持为旧版本，从而避免了将运行有第一应用的pod全部滚动式的升级为新版本而导致的应用全面异常及线上业务100％受损的问题。
附图说明
20.图1为相关技术中利用deployment进行应用升级的过程示意图。
21.图2是本技术实施例提供的升级应用的方法流程图。
22.图3是本公开实施例提供的架构示例图。
23.图4是本公开一实施例提供的升级应用的装置的结构示意图。
24.图5是本公开另一实施例提供的升级应用的装置的结构示意图。
具体实施方式
25.下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。
26.为了便于理解，先对本公开实施例的相关概念进行简单介绍。
27.kubernetes(容器编排系统)：简称k8s，是一个自动化的容器运维管理平台，也是一个开源的自动化容器编排工具。k8s支持将多台主机组合成集群来运行容器化应用，它可以自动部署、扩展、删除和管理容器化应用，消除了应用(或称应用程序)在部署、扩缩容、下线时涉及到的许多手动操作。
28.pod(容器组)：是可以在kubernetes中创建和管理的最小可部署的计算单元。 kubernetes可管理多个pod，每个pod中可运行有一个或者多个容器，每个容器对应的运行有一个应用。本公开实施例对每个pod中具体运行多少个容器不做具体的限定。例如，在原生的k8s设计中，一组功能类似的容器组成一个pod，即每个pod中运行有多个容器。或者，可以将每个pod自定义为与容器一一对应，即每个pod中只运行有一个容器。例如，在容器所运
行的应用为多方安全计算模型时，可将其每个pod定义为只运行一个容器，该一个容器可运行有一个安全模型的副本，以实现对该安全模型的副本的单独管理。
29.deployment(部署)：表示一个长期运行的无状态应用，是k8s提供的高层抽象资源，也是k8s支持的工作负载类型之一。一个应用通常是部署在多个容器中的，该多个容器运行于多个pod中，而deployment则可以对该多个pod进行统一的管理。也可以理解为：一个deployment的底层由多个pod组成，每个pod内的容器上运行有相同的应用，因此每个pod的功能一样，对外提供相同的服务。deployment对该多个pod的管理方式可以是创建、更新或者维护。作为一种实现方式，deployment可用于保证运行(即running) 状态下pod的数量不变，如果其中一个pod或运行pod的机器挂掉，deployment可负责重新创建pod或在其它机器上重新拉起pod。作为另一种实现方式，deployment可将其所管理的多个pod中运行有应用的容器进行升级(或称更新)，以使多个pod所运行的容器内运行有新版本的应用，从而实现了应用的升级。
30.灰度更新：也叫金丝雀更新，是基于deployment进行应用的升级的一种方式。当需要将一个应用升级到新版本时，为了保证应用在升级的过程中不影响其线上的使用，需要任何时间点都有pod在提供服务，而灰度更新则可以实现这一目标。
31.下面结合图1对相关技术中的灰度更新进行详细的说明。
32.如图1所示，在deployment使用灰度更新的方法对应用进行滚动更新时，当运行 deployment之后，可创建两个副本集(replicaset)：replicaset 1和replicaset 2，来对应用所部署的多个pod进行维护和更新，以使pod的数量始终维持在用户定义的范围内。副本集replicaset也可以称为容器管理器。在每次滚动更新时，副本集replicaset1可用来删除一部分运行旧版本(v1)应用容器的pod，副本集replicaset2可用来补充创建一部分运行新版本(v2)应用容器的pod，进行多次滚动后，副本集replicaset1会删除全部运行旧版本应用容器的pod，而副本集replicaset2会创建好用户定义数量的运行有新版本应用容器的pod，以使得最终deployment中运行同一应用版本容器的pod。以图1 中用户定义的pod数量为3为例，replicaset1在每次滚动时，删除一个运行v1版本容器的pod，同时replicaset2补充创建一个运行v2版本容器的pod。随着滚动次数的增加，replicaset 1中运行有v1版本应用容器的pod的数量不断减少，同时，replicaset 2 中运行有v2版本应用容器的pod的数量不断增加。经过3次滚动后，replicaset 1中不再拥有pod，而replicaset 2中的pod数刚好符合用户定义数量3。
33.由此可知，在使用一个deployment对运行有应用容器的pod进行更新时，虽然可以采用滚动更新的机制，但只要启动更新，则会自动的将应用所对应的多个pod全部滚动更新为新版本。然而，通过这样的方式进行更新是比较危险的，如果新版本应用出现问题，将会导致应用全面异常，线上业务100％受损。
34.上述问题在应用为多方安全计算模型的场景下显得尤为突出。多方安全计算 (secure multi-party computation，简称mpc)模型是一种利用多方安全计算技术训练产生的模型。为了便于理解，先对多方安全计算及多方安全计算模型的相关概念进行简单的介绍。
35.在大数据时代，多个数据持有方可以持有同一对象的数据。在这种情况下，在对该对象的数据进行数据计算时，会涉及多个数据持有方，可能需要该多个数据持有方合作才
能完成该数据计算。然而，由于不同数据持有方之间出于竞争或者隐私保护方面的考虑，不能或者不愿意泄露各自持有的数据。
36.例如，同一个自然人可以在不同的借款平台借款。因此，各借款平台均可能存储有该自然人在本平台的借款数额。当需要统计该自然人在多个借款平台的借款总额时，往往需要联合该多个借款平台的数据才能完成该统计计算。在这个例子中，借款平台是数据持有方，该自然人的借款数额是数据持有方持有的数据，计算自然人借款总额为期望完成的数据计算。
37.又如，每个共享单车平台都可以为用户提供单车使用服务。各共享单车平台均存储有该平台每天共享单车的使用量。在希望统计共享单车在某一天的使用总量时，往往需要联合多个共享单车平台的数据完成统计计算。在这个例子中，共享单车平台是数据持有方，这一天共享单车的使用量是数据持有方持有的数据，这一天共享单车的使用总量为期望完成的数据计算。
38.又如，每个电子商务平台均可能存储相同或不同消费群体的消费数据。为了更好地了解消费者的习惯和选择营销活动的目标群体，往往需要联合多个电子商务平台的消费数据进行模型训练。在这个例子中，电子商务平台为数据持有方，各自记录的消费数据为数据持有方持有的数据，利用这些数据进行模型训练为期望完成的数据计算。
39.为了联合多个数据持有方的数据进行数据计算，同时保护该多个数据持有方的数据，多方安全计算逐渐被广泛应用。
40.多方安全计算可以在保护数据隐私的前提下进行通用计算。例如，多方安全计算使非互信的多个数据持有方之间可以在数据相互保密的前提下进行高效数据计算，从而做到既使用多源数据进行指定的数据计算，又保证使用过程中数据隐私不被泄漏，真正实现数据的可用而不可见。
41.多方安全计算模型，也可以称为安全模型，为多方安全计算的一种应用。如前所述，多个数据持有方可利用其与对象有关的数据共同计算与该对象的目标数据，该目标数据的计算可以是基于多个数据持有方根据其与对象有关的数据所训练的机器学习模型而计算的，而该机器学习模型则为多方安全计算模型。
42.为了训练该机器学习模型，需要将所有数据持有方的数据集中到一起，再执行集中式的建模任务。但是，随着各类隐私保护法案的出台，数据跨数据持有方交易、流动已经被禁止，同时，数据资产也是数据持有方非常重要的一种资产，数据持有方自身也有保护数据安全，禁止数据外泄的需求，传统的集中式训练方案已经无法满足新时期的需求，特别是无法满足风控领域的需求。而多方安全计算模型则可以保证在数据持有方的原始数据不出域的情况下完成模型的联合训练和预测，因此被越来越多的数据持有方所采用。多方安全计算模型训练完成后，每个数据持有方(或称参与方)得到了模型的一部分，在模型预测阶段，每个参与方都把各自“部分的”模型运行起来，这样多个参与方就能联合完成模型预测。
43.利用多方安全计算模型进行预测是一个线上的常驻服务，一旦模型上线部署后，就需要永远保持服务可用，否则就会影响业务的稳定性，使得参与者(数据持有方)的业务受到损失。另一方面，多方安全计算模型训练完成后并不是一成不变的，需要根据业务和需求不断迭代改进，因此线上模型需要具备灰度更新能力。也就是说，由于多方安全计算模型需要不断的更新且其牵扯的参与方较多，如果新版本的模型有问题，其所导致的应用全面
异常，线上业务100％受损现象会特别的突出。
44.有鉴于此，本公开实施例提供一种升级应用的方法，该方法同时使用第一 deployment和第二deployment来对运行有第一应用的容器的pod进行管理，第一 deployment用来管理运行有旧版本第一应用的容器的第一组pod，第二deployment用来管理运行有新版本第一应用的第二组pod，从而可实现只将第一应用所对应的一部分pod 进行升级。这相当于在应用升级的过程中设置了断点，即使新版本的应用有问题，也只会影响应用的部分流量。与上述相关技术相比能够及时止损的，避免了相关技术中应用全面异常，线上业务100％受损的问题。
45.下面结合附图2，对本公开实施例提供的方法进行详细描述。
46.在步骤s210，运行第一deployment。
47.第一deployment用于管理第一组pod，第一组pod中的每个pod运行有旧版本的第一应用的容器。
48.在步骤s220，运行第二deployment。
49.第二deployment用于管理第二组pod，第二组pod中的每个pod运行有新版本的第一应用的容器。
50.在步骤s230，根据第一deployment和第二deployment，调整第一组pod和第二组pod中的pod数量，以将第一应用升级到新版本或将第一应用回滚至旧版本。
51.本技术实施例中的第一应用可以是上述安全多方计算模型(简称mpc模型)，该安全多方计算模型可以涉及的项目包括：微贷联营项目，国际风控二期管道项目，联合风控项目等等。
52.本公开实施例分别通过第一deployment和第二deployment管理运行有旧版本的第一应用容器的第一组pod和运行有新版本的第一应用容器的第二组pod，并可根据第一 deployment和第二deployment调整第一组pod和第二组pod中的pod数量，以实现在使用第二deployment将第一应用所对应的部分pod升级到新版本的同时，可使用第一 deployment将剩余的pod保持为旧版本，从而避免了将运行有第一应用的pod全部滚动式的升级为新版本而导致的应用全面异常及线上业务100％受损的问题。
53.本技术实施例中的第一deployment或第二deployment是一种根据相应的 deployment描述文件(或称deployment的配置文件)所运行的无状态应用，第一 deployment或第二deployment所管理的pod可以是deployment控制器根据上述 deployment描述文件中的具体内容所自动部署的。deployment描述文件可以是运维人员 (或称模型管理员)根据需求直接提交或更新的一种文件。或者，如图3所示，deployment 描述文件还可以是mpcdeployment控制器根据mpcdeployment描述文件(或称第一配置文件)自动部署的文件。mpcdeployment可以理解为是一种类似于deployment，但位于deployment之上可对deployment进行管理的部署。该部署专用于对部署多方安全计算应用的deployment进行管理，因此可称为mpcdeployment。
54.mpcdeployment描述文件也是一种配置文件，该文件中可以定义第一应用的版本、名称、属性以及deployment描述文件的详细定义。deployment描述文件的详细定义包括 deployment的模板、副本的数量、第一应用的镜像和启动参数、容器的镜像地址和第一应用所要部署的数据参与方等信息。作为一个示例，mpcdeployment描述文件的内容可以如下：
55.1.apiversion:nueva.oasis/v1alpha1
56.2.kind:mpcdeployment
57.3.metadata:
58.4.name:model-1#模型名称
59.5.labels:
60.6.dsaas/update-percent:"10"
61.7.spec:
62.8.template:
63.9.spec:
64.10.replicas:2
65.11.command:#command，args，image指定了模型的镜像和启动参数
66.12.-./bin/mpc_serving
67.13.args:
68.14.-model_path＝data/model1
69.15.image:mpc_serving:v1
70.16.domains:#部署到机构a和b
71.17.-domainid:institution-a
72.18.-domainid:institution-b
73.在上述描述文件中，mpcdeployment描述文件主要由3部分内容组成：
74.1、spec.domains字段：用于描述这个模型有哪几个参与方(如上述示例中的参与方a和b)。
75.2、spec.template字段：用于描述模型的详细信息(即deployment的配置信息)，该信息用来给每一个参与方合成deployment，其中replicas字段指明了模型总共要部署多少个副本(如上述示例中replicas字段为2，即该模型总共需要部署2个副本)，每个机构副本数一样。deployment是k8s的原生机制，k8s会自动根据deployment创建 pod。
76.3、metadata.labels“dsaas/update-percent”标签：用于设置需要进行灰度更新的第二组pod的数量比例。
77.可以理解的是，本技术实施例中的mpcdeployment描述文件主要是用于后续 deployment描述文件的生成。在正常情况下，mpcdeployment描述文件与deployment 描述文件是1:1的关系，但是，在模型更新过程中，mpcdeployment描述文件与deployment 描述文件是1:2的关系，即mpcdeployment描述文件会对应新旧两个不同的deployment 描述文件。
78.本技术实施例通过在deployment控制器之上设置一个mpcdeployment控制器，并通过运维人员直接提交和更新mpcdeployment描述文件而自动生成deployment的描述文件。这样可以避免运维人员在对第一应用进行更新时，需要针对管理不同版本第一应用的deployment的描述文件进行手动修改或删除的麻烦，更容易实现自动部署，有效提高效率。
79.通过前述内容可知，第一deployment和第二deployment所管理的pod的数量是可以根据需要而调整的。可以理解的是，在第一应用为上述mpc模型时，在某一个数据持有方处，其在线上部署的新旧版本的第一应用的容器的总数量可以是恒定值，即一个参与方处
所持有的mpc模型所对应的第一应用的容器的总数量是不变的。如果该总数量为m，第一deployment所管理的pod的数量为n，则第二deployment所管理的pod 的数量即为m-n。也就是说，在更新mpc模型时，如果第一deployment调整了第一组 pod的数量，则第二deployment会相应的调整第二组pod的数量。
80.本技术实施例对调整第一组pod的数量和调整第二组pod的数量的方式不做具体的限定。在一些实现方式中，可以通过手动调整第一deployment或第二deployment的配置文件的副本字段的取值而调整第一deployment或第二deployment所管理的pod的数量。
81.在另一些实现方式中，如图3所示，deployment控制器可以根据mpcdeployment 描述文件中的第一参数(即上述dsaas/update-percent)而自动的调整第一deployment或第二deployment的配置文件的副本字段的取值，以调整第一deployment或第二 deployment所管理的pod的数量。
82.通常而言，在根据第一deployment和第二deployment调整第一deployment和第二 deployment所管理的pod的数量之前，需要先确定需要维持为旧版本的第一组pod的数量和需要升级为新版本的第二组pod的数量。
83.通过前述mpcdeployment描述文件可知，可在mpcdeployment描述文件中定义第一参数，该第一参数为第二组pod中的pod数量与mpc模型所对应的第一应用的pod 的总数量的占比。第一参数用于更新第二组pod中的pod数量的占比，即修改该第一参数可以更新第二组pod中的pod数量的占比。参考前文，某一个数据持有方处的mpc 模型所对应的pod的总数量是恒定值，因此，mpcdeployment控制器可接收第一参数并根据第一参数确定第一deployment所管理的第一组pod和第二deployment所管理的第二组pod中的pod应有的数量。
84.具体的确定方法可以如下：mpcdeployment描述文件中的spec.template.replicas表示总的副本数，dsaas/update-percent(即第一参数)表示升级的模型的副本数百分比。 spec.template.replicas乘dsaas/update-percent后的值取整，即为第二组pod中的pod应有的数量。spec.template.replicas减去新第二组pod中的pod应有的数量的结果，即为第一组pod中的pod应有的数量。例如，上述mpcdeployment描述文件中的replicas数量是 2，第一参数设成10，则第二组pod数量应该是0.2取整即为1，对应的第一组pod数量为1。
85.再如，replicas数量是10，第一参数设成20(即占比为百分之20)，则第二组pod 数量应该为2(即10*20％)，第一组pod数量应该为8(即10-2)。也就是说mpc模型有2个副本是需要新配置的，而剩余的8个模型是维持为旧配置的。通过这种方式运维人员可以在这2个新模型中验证新版模型是否正确，如果正常，则可以继续提高第一参数的值，直到100％将第一应用全部更新为新版本。如果不正常，则可以修改第一参数的值为0，使得全部pod退为旧版本。
86.为了可以实现对上述对应数量pod的管理，在确定需要维持为旧版本的第一组pod 的数量和需要升级为新版本的第二组pod的数量之后，还需要相应的设置或者更新第一 deployment和第二deployment的配置文件。
87.在升级应用时，更新第一deployment的配置文件和第二deployment的配置文件，使得第一deployment的配置文件的副本字段的取值与上述第一组pod的pod数量相匹配，第
二deployment的配置文件的副本字段的取值与上述第二组pod的pod数量相匹配。即通过deployment控制器将第二组pod的pod数量设置到第二deployment的replicas字段中，将第一组pod的pod数量设置到第一deployment的replicas字段中。
88.进一步地，如果第一deployment的配置文件的副本字段的取值和/或第二 deployment的配置文件的副本字段的取值不为0，则向deployment控制器发送deployment 更新指令，以便deployment控制器根据第一deployment的配置文件对第一deployment 进行更新和/或根据第二deployment的配置文件对第二deployment进行更新。
89.如果第一deployment的配置文件的副本字段的取值或第二deployment的配置文件的副本字段的取值为0，则向deployment控制器发送deployment删除指令，以便 deployment控制器删除第一deployment或第二deployment。
90.可以理解的是，任意deployment在删除、更新后，k8s会自动删除、创建deployment 对应的pod，如果pod数量不满足deployment的replicas描述，pod数量也会被自动调整。
91.本技术实施例通过设置第一参数而更新第二组pod中的pod数量的占比以及确定第一组pod和第二组pod中的pod数量，可以在不同的数据持有方处同步更新同比例的pod，从而在相同的更新次数下，完成全部的更新。这样可以避免直接通过修改第一组pod和第二组pod中的pod数量而导致的不同的数据持有方处的pod更新不同步的问题。
92.需要说明的是，第一deployment或第二deployment的配置文件中的配置信息(例如，可以是多方安全计算模型的配置内容或者对应的副本数)在上线及之后的升级过程中都是可以随时更新变化的。例如，当多方安全计算模型为初次上线时，其对应的 deployment只有一个，即为第一deployment。在对该多方安全计算模型进行初次部分更新时，其对应的deployment可以有两个，即为第一deployment和第二deployment。该第二deployment的配置文件中的模型配置信息与第一deployment的配置文件中的模型配置信息是不同的。如果进行初次更新后，新模型效果比较好，可以提高第二deployment 的配置文件的副本字段的取值，相应的减少第一deployment的配置文件的副本字段的取值。
93.结合上文内容，在图3所示的示例中，模型管理员无论是修改了dsaas/update-percent (即第一参数)标签，还是修改了spec.template模型配置信息(或称deployment的配置信息)，都需要重新提交mpcdeployment描述文件(或称第一配置文件)。mpcdeployment 描述文件被提交后，mpcdeployment控制器可以相应的对第一deployment或第二 deployment的配置文件进行处理。具体来说，mpcdeployment控制器(简称md-控制器) 在接收到管理员提交的mpcdeployment描述文件后，md-控制器会首先确定已经存在的第一应用关联的deployment的数量以及deployment的配置信息。在应用升级时，md
‑ꢀ
控制器还会确定mpcdeployment描述文件中的deployment的配置信息与已经存在的第一应用关联的deployment中的最新deployment的配置信息的比较结果。在确定了上述内容后，md-控制器会进一步的进行后续工作。
94.具体的处理流程可以如下：
95.md-控制器扫描spec.domains字段，对于每一个数据持有方(即参与方)分别、依次做如下操作：
96.a)扫描该数据持有方中已存在的第一应用(如model-1)对应的deployment， deployment的数量可能有0个、1个、2个或多个，如果deployment数量有多个，属于非正常情
况。此时只保留最新的2个deployment，将其余的deployment删除，后续仍旧按2个deployment的情况执行。
97.b)如果已存在的deployment的数量为0个，说明mpcdeployment描述文件是第一次被提交，这是一个全新的第一应用，不需要走灰度更新逻辑，md-控制器根据 spec.template内容创建一个新的deployment(即第一deployment)，提交给deployment 控制器，流程结束。
98.c)如果已存在的deployment的数量为1个，又分为两种情况：
99.第一、该已存在的deployment中的内容与spec.template相同，说明管理员并没有更新mpcdeployment描述文件，而是把同样的mpcdeployment描述文件提交了2次，因此可以忽略此次提交，流程执行结束。
100.第二、该已存在的deployment的内容与spec.template不同，说明管理员更新了mpcdeployment描述文件，新一轮灰度更新开始。此时md-控制器做的事情是根据 spec.template内容创建一个新的deployment(即第二deployment)，已存在的deployment 作为第一deployment，同时根据前述方法调整第一、第二deployment的副本(replica) 数量，再将调整完毕后的两个deployment提交到deployment控制器，流程执行结束。
101.d)如果已存在的deployment的数量为2，将已存在的deployment按照创建时间排序，将已存在的第一应用关联的deployment中的最新deployment的称为d2，次新 deployment称为d1，将spec.template中的内容与d2比较，根据比较结果是否相同分成两种情况处理：
102.第一、spec.template与d2相同，说明管理员并没有更新spec.template内容，只是更新了“dsaas/update-percent”标签，这种情况表示管理员想继续推进灰度部署的进度。此时，将d2作为第二deployment，将d1作为第一deployment，md-控制器根据前述方法调整第一、第二deployment的副本(replica)数量，再将调整完毕后的两个deployment 提交到deployment控制器，流程执行结束。
103.第二、spec.template与d2不同，说明管理员在上一轮灰度更新没有结束的情况下开启了新一轮灰度更新，此时md-控制器执行的动作是：
104.删除d1；根据spec.template的内容创建一个新的deployment作为第二deployment，称为d3，将d2作为第一deployment；同时根据前述方法调整第一、第二deployment的副本(replica)数量，再将调整完毕后的两个deployment提交到deployment控制器，流程执行结束。
105.本技术实施例在k8s原生的deployment之上提出了mpcdeployment的概念。 mpcdeployment可以同时管理同一个模型的不同版本，当新版本模型要上线时， mpcdeployment控制器通过在底层维护两个deployment，并通过不断调整deployment 的配置文件的副本数量来调整新旧模型的比例。通过这种方式，模型管理员可以设置一个小的比例来观察新版本模型是否正常，如果正常可以继续加大比例，不正常的话可以通过提交旧的mpcdeployment描述文件来回滚掉新版本模型，从而避免线上模型100％受损而影响线上业务问题。
106.上文结合图1至图3，详细描述了本公开的方法实施例，下面结合图4至图5，详细描述本公开的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，
未详细描述的部分可以参见前面方法实施例。
107.图4是本公开一实施例提供的一种升级应用的装置的示意性结构图。该装置400 可以包括第一运行模块410、第二运行模块420以及调整模块430。下面对这些模块进行详细介绍。
108.第一运行模块410用于运行第一deployment，第一deployment用于管理第一组pod，第一组pod中的每个pod运行有旧版本的第一应用的容器。
109.第二运行模块420用于运行第二deployment，第二deployment用于管理第二组pod，第二组pod中的每个pod运行有新版本的第一应用的容器。
110.调整模块430用于根据第一deployment和第二deployment，调整第一组pod和第二组pod中的pod数量，以将第一应用升级到新版本或将第一应用回滚至旧版本。
111.可选地，如图4所示，该装置还可以包括接收模块440，用于接收第一参数，第一参数用于更新第二组pod中的pod数量的占比。
112.第一确定模块450，用于根据第二组pod中的pod数量的占比，确定第一组pod和第二组pod中的pod数量。
113.可选地，该装置还可以包括更新模块460，用于更新第一deployment的配置文件和第二deployment的配置文件，使得第一deployment的配置文件的副本字段的取值与第一组pod的pod数量相匹配，第二deployment的配置文件的副本字段的取值与第二组 pod的pod数量相匹配。
114.发送模块470用于如果第一deployment的配置文件的副本字段的取值和/或第二 deployment的配置文件的副本字段的取值不为0，则向deployment控制器发送deployment 更新指令，以便deployment控制器根据第一deployment的配置文件对第一deployment 进行更新和/或根据第二deployment的配置文件对第二deployment进行更新。
115.可选地，发送模块470还用于如果第一deployment的配置文件的副本字段的取值或第二deployment的配置文件的副本字段的取值为0，则向deployment控制器发送 deployment删除指令，以便deployment控制器删除第一deployment或第二deployment。
116.可选地，第一参数位于第一配置文件中，第一配置文件中还包括deployment的配置信息，该装置400还包括第二确定模块480，用于确定第一应用关联的deployment的数量以及deployment的配置信息与第一应用关联的deployment中的最新deployment的配置信息的比较结果。
117.设置模块490用于如果第一应用关联的deployment的数量大于等于2且比较结果为相同，将第一应用关联的deployment中的次新deployment和最新deployment分别设置为第一deployment和第二deployment，并删除第一应用关联的deployment中的其余 deployment，设置模块还用于如果第一应用关联的deployment的数量大于等于2且比较结果为不同，将最新deployment设置为第一deployment，删除第一应用关联的deployment 中的其余deployment，并根据第一配置文件中的deployment的配置信息设置第二 deployment。
118.可选地，第一应用为安全多方计算模型。
119.图5是本公开又一实施例提供的升级应用的装置的结构示意图。该装置500例如可以是具有计算功能的计算设备。比如，装置500可以是移动终端或者服务器。装置500 可以
包括存储器510和处理器520。存储器510可用于存储可执行代码。处理器520可用于执行所述存储器510中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置500还可以包括网络接口530，处理器520与外部设备的数据交换可以通过该网络接口530实现。
120.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，dvd))、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
121.本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
122.在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
123.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
124.另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
125.以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。