Method and apparatus for upgrading an application

Abstract

The disclosure discloses an application upgrading method and device. The method comprises: running a first deployment, the first deployment being used for managing a first group of pods, each pod in the first group of pods running a container of an old version of a first application; running a second deployment, the second deployment being used for managing a second group of pods, each pod in the second group of pods running a container of a new version of the first application; and adjusting the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to upgrade the first application to the new version or roll back the first application to the old version.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of upgrading applications, and in particular, to a method and device for upgrading applications. BACKGROUND

[0002] When the existing container operation and maintenance platform Kubernetes upgrades the application deployed in the container based on the original deployment mechanism, it needs to continuously upgrade the group of pods running the old version of the application managed by the deployment to the group of pods running the new version of the application. If the new version of the application has a problem, upgrading in this way will cause the application to be completely abnormal and the online business to be 100% damaged. SUMMARY

[0003] Therefore, the present disclosure provides a method and device for upgrading applications to effectively avoid the overall abnormality of the application upgrade and the 100% damage of the online business.

[0004] In a first aspect, a method for upgrading an application is provided, comprising: running a first deployment, the first deployment being used to manage a first group of pods, each pod in the first group of pods running a container of an old version of a first application; running a second deployment, the second deployment being used to manage a second group of pods, each pod in the second group of pods running a container of a new version of the first application; and adjusting the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to upgrade the first application to the new version or roll back the first application to the old version.

[0005] Optionally, before the adjusting the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, the method further comprises: receiving a first parameter, the first parameter being used to update a proportion of the number of pods in the second group of pods; and determining the number of pods in the first group of pods and the second group of pods according to the proportion of the number of pods in the second group of pods.

[0006] Optionally, after determining the number of pods in the first group and the number of pods in the second group according to the proportion of the number of pods in the second group, the method further comprises: updating the configuration file of the first deployment and the configuration file of the second deployment, so that the value of the replica field of the configuration file of the first deployment matches the number of pods in the first group, and the value of the replica field of the configuration file of the second deployment matches the number of pods in the second group; if the value of the replica field of the configuration file of the first deployment and / or the value of the replica field of the configuration file of the second deployment is not 0, sending a deployment update instruction to the deployment controller, so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment.

[0007] Optionally, after updating the configuration file of the first deployment and the configuration file of the second deployment, the method further comprises: if the value of the replica field of the configuration file of the first deployment or the value of the replica field of the configuration file of the second deployment is 0, sending a deployment deletion instruction to the deployment controller, so that the deployment controller deletes the first deployment or the second deployment.

[0008] Optionally, the first parameter is located in a first configuration file, and the first configuration file further includes configuration information of the deployment; after receiving the first configuration file, the method further includes: determining a number of deployments associated with the first application and a comparison result of the configuration information of the deployment and configuration information of a latest deployment in the deployments associated with the first application; if the number of deployments associated with the first application is greater than or equal to 2 and the comparison result is same, setting a second newest deployment and the latest deployment in the deployments associated with the first application as the first deployment and the second deployment respectively, and deleting the remaining deployments in the deployments associated with the first application; if the number of deployments associated with the first application is greater than or equal to 2 and the comparison result is different, setting the latest deployment as the first deployment, deleting the remaining deployments in the deployments associated with the first application, and setting the second deployment according to the configuration information of the deployment in the first configuration file.

[0009] Optionally, the first application is a secure multi-party computation model.

[0010] In a second aspect, a device for upgrading an application is provided, including: a first running module configured to run a first deployment, the first deployment being configured to manage a first group of pods, each pod in the first group of pods running a container of an old version of a first application; a second running module configured to run a second deployment, the second deployment being configured to manage a second group of pods, each pod in the second group of pods running a container of a new version of the first application; and an adjusting module configured to adjust a number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to upgrade the first application to the new version or roll back the first application to the old version.

[0011] Optionally, the device further includes: a receiving module configured to receive a first parameter, the first parameter being used to update a proportion of a number of pods in the second group of pods; and a first determining module configured to determine the number of pods in the first group of pods and the second group of pods according to the proportion of the number of pods in the second group of pods.

[0012] Optionally, the apparatus further comprises: an updating module, configured to update the configuration file of the first deployment and the configuration file of the second deployment, so that the value of the replica field of the configuration file of the first deployment matches the number of pods of the first group of pods, and the value of the replica field of the configuration file of the second deployment matches the number of pods of the second group of pods; and a sending module, configured to send a deployment update instruction to a deployment controller, so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment, if the value of the replica field of the configuration file of the first deployment and / or the value of the replica field of the configuration file of the second deployment is not 0.

[0013] Optionally, the sending module is further configured to send a deployment deletion instruction to the deployment controller, so that the deployment controller deletes the first deployment or the second deployment, if the value of the replica field of the configuration file of the first deployment or the value of the replica field of the configuration file of the second deployment is 0.

[0014] Optionally, the first parameter is located in a first configuration file, and the first configuration file further includes configuration information of the deployment, and the apparatus further includes a second determining module configured to determine a number of deployments associated with the first application and a comparison result of the configuration information of the deployment and configuration information of a latest deployment in the deployments associated with the first application; and a setting module configured to, if the number of the deployments associated with the first application is greater than or equal to 2 and the comparison result is same, set a second newest deployment and the latest deployment in the deployments associated with the first application as the first deployment and the second deployment respectively, and delete the remaining deployments in the deployments associated with the first application, and further configured to, if the number of the deployments associated with the first application is greater than or equal to 2 and the comparison result is different, set the latest deployment as the first deployment, delete the remaining deployments in the deployments associated with the first application, and set the second deployment according to the configuration information of the deployment in the first configuration file.

[0015] Optionally, the first application is a secure multi-party computation model.

[0016] In a third aspect, an apparatus for upgrading an application is provided, including a memory and a processor, the memory storing executable code, and the processor configured to execute the executable code to implement the method in the first aspect.

[0017] In a fourth aspect, a computer-readable storage medium is provided, storing executable code, and when the executable code is executed, the method in the first aspect can be implemented.

[0018] In a fifth aspect, a computer program product is provided, including executable code, and when the executable code is executed, the method in the first aspect can be implemented.

[0019] The embodiment of the present disclosure provides a method for upgrading an application, which respectively manages a first group of pods running an old version of a first application container and a second group of pods running a new version of the first application container through a first deployment and a second deployment, and can adjust the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to realize that while using the second deployment to upgrade part of the pods corresponding to the first application to the new version, the remaining pods can be kept as the old version using the first deployment, thereby avoiding the problem of application overall exception and 100% damage of online business caused by rolling upgrade of all pods running the first application to the new version. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 A process diagram for upgrading an application using a deployment in the related art.

[0021] Figure 2 A method flowchart for upgrading an application provided by the embodiment of the present disclosure.

[0022] Figure 3 An architecture example diagram provided by the embodiment of the present disclosure.

[0023] Figure 4 A structure diagram of an apparatus for upgrading an application provided by an embodiment of the present disclosure.

[0024] Figure 5 A structure diagram of an apparatus for upgrading an application provided by another embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] The technical solutions in the embodiments of the present disclosure will be described clearly and completely in combination with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all the embodiments.

[0026] In order to facilitate understanding, the related concepts of the embodiments of the present disclosure will be briefly introduced first.

[0027] Kubernetes (container orchestration system): K8s for short, is an automatic container operation and management platform, and is also an open source automatic container orchestration tool. K8s supports combining multiple hosts into a cluster to run containerized applications, and can automatically deploy, expand, delete and manage containerized applications, eliminating many manual operations involved in deployment, expansion, and offline of applications (or application programs).

[0028] Pod: is the smallest deployable computing unit that can be created and managed in Kubernetes. Kubernetes can manage multiple pods, each of which can run one or more containers, each of which corresponds to the running of an application. The embodiments of the present disclosure do not make specific limitations on how many containers are specifically run in each pod. For example, in the original K8s design, a group of functionally similar containers form a pod, that is, multiple containers are run in each pod. Alternatively, each pod can be customized to correspond to one container, that is, only one container is run in each pod. For example, when the application run by the container is a multi-party secure computing model, each pod of the container can be defined to run only one container, and the one container can run a copy of the secure model to achieve separate management of the copy of the secure model.

[0029] Deployment: represents a long-running stateless application, is a high-level abstract resource provided by K8s, and is one of the workload types supported by K8s. An application is usually deployed in multiple containers running in multiple pods, and the deployment can uniformly manage the multiple pods. It can also be understood that: the underlying of a deployment is composed of multiple pods, and the containers in each pod run the same application, so the functions of each pod are the same and provide the same service externally. The management mode of the deployment to the multiple pods can be creation, update or maintenance. As an implementation manner, the deployment can be used to ensure that the number of pods in the running state is unchanged, and if one of the pods or the machine running the pod is down, the deployment can be responsible for recreating the pod or restarting the pod on other machines. As another implementation manner, the deployment can upgrade (or update) the containers running the application in the multiple pods it manages, so that the containers running in the multiple pods run the new version of the application, thereby realizing the upgrade of the application.

[0030] Gray update: also known as canary update, is a way of upgrading an application based on deployment. When an application needs to be upgraded to a new version, in order to ensure that the application is not affected during the upgrade process, there needs to be a pod providing services at any time point, and the gray update can achieve this goal.

[0031] The following will be described in detail Figure 1 The gray update in the related art is described in detail.

[0032] As Figure 1As shown, when the deployment uses the method of gray update to perform rolling update on the application, after the deployment is run, two replica sets (ReplicaSet) can be created: ReplicaSet 1 and ReplicaSet 2, to maintain and update the multiple pods deployed by the application, so that the number of pods is always maintained within the user-defined range. The replica set ReplicaSet can also be referred to as a container manager. At each rolling update, replica set ReplicaSet 1 can be used to delete a part of the pods running the old version (V1) application container, and replica set ReplicaSet 2 can be used to supplement the creation of a part of the pods running the new version (V2) application container. After multiple rolling updates, replica set ReplicaSet 1 deletes all pods running the old version application container, and replica set ReplicaSet 2 creates a user-defined number of pods running the new version application container, so that the final deployment has pods running the same version of the application container. For example, Figure 1 For example, when the user-defined number of pods is 3, replica set ReplicaSet 1 deletes one pod running the V1 version container at each rolling, while replica set ReplicaSet 2 supplements the creation of one pod running the V2 version container. With the increase of the number of rolling, the number of pods running the V1 version application container in replica set ReplicaSet 1 is constantly decreasing, while the number of pods running the V2 version application container in replica set ReplicaSet 2 is constantly increasing. After 3 rolling, replica set ReplicaSet 1 no longer has pods, and the number of pods in replica set ReplicaSet 2 just meets the user-defined number 3.

[0033] Therefore, when updating the pods running the application container using a deployment, although the rolling update mechanism can be used, as long as the update is started, the multiple pods corresponding to the application will be automatically updated to the new version. However, updating in this way is relatively dangerous, and if the new version application has a problem, it will cause the application to be completely abnormal and the online business to be 100% damaged.

[0034] The above problem is particularly prominent in the scenario where the application is a multi-party secure computation model. The multi-party secure computation (Secure Multi-Party Computation, MPC for short) model is a model generated by using multi-party secure computation technology for training. In order to facilitate understanding, the related concepts of multi-party secure computation and multi-party secure computation model are briefly introduced.

[0035] In the big data era, multiple data holders can hold data of the same object. In this case, when data computation is performed on the data of the object, multiple data holders are involved, and the data computation can be completed only by cooperation of the multiple data holders. However, due to competition or privacy protection between different data holders, the data held by each data holder cannot or is unwilling to be disclosed.

[0036] For example, the same natural person can borrow money on different lending platforms. Therefore, each lending platform can store the amount of money borrowed by the natural person on the platform. When it is necessary to count the total amount of money borrowed by the natural person on multiple lending platforms, the data of the multiple lending platforms often need to be combined to complete the statistical computation. In this example, the lending platform is a data holder, the amount of money borrowed by the natural person is data held by the data holder, and the computation of the total amount of money borrowed by the natural person is a data computation expected to be completed.

[0037] For another example, each shared bicycle platform can provide bicycle use services for users. Each shared bicycle platform stores the use amount of shared bicycles of the platform per day. When it is desired to count the total use amount of shared bicycles on a certain day, the data of multiple shared bicycle platforms often need to be combined to complete the statistical computation. In this example, the shared bicycle platform is a data holder, the use amount of shared bicycles on the day is data held by the data holder, and the total use amount of shared bicycles on the day is a data computation expected to be completed.

[0038] For another example, each e-commerce platform can store consumption data of the same or different consumer groups. In order to better understand the habits of consumers and select target groups for marketing activities, consumption data of multiple e-commerce platforms often need to be combined for model training. In this example, the e-commerce platform is a data holder, the recorded consumption data is data held by the data holder, and the use of the data for model training is a data computation expected to be completed.

[0039] In order to combine the data of multiple data holders for data computation while protecting the data of the multiple data holders, multi-party secure computation is gradually widely used.

[0040] Multi-party secure computation can perform general computation while protecting data privacy. For example, multi-party secure computation enables multiple non-trusted data holders to perform efficient data computation under the premise of mutual data privacy, so as to achieve specified data computation using multi-source data and ensure that data privacy is not leaked during use, and truly realize that data is usable but invisible.

[0041] The multi-party secure computation model, which can also be referred to as a secure model, is an application of multi-party secure computation. As described previously, multiple data holders can jointly compute target data of an object based on data related to the object by using the data related to the object, and the computation of the target data can be based on a machine learning model trained by the multiple data holders based on the data related to the object, and the machine learning model is the multi-party secure computation model.

[0042] In order to train the machine learning model, the data of all data holders needs to be centralized and then a centralized modeling task is performed. However, with the introduction of various privacy protection laws, data transactions and flow across data holders have been prohibited, and data assets are also very important assets for data holders. Data holders themselves also have the need to protect data security and prohibit data leakage. The traditional centralized training scheme cannot meet the needs of the new era, especially the needs of the risk control field. The multi-party secure computation model can ensure joint training and prediction of the model without the original data of the data holders leaving the domain, and therefore is increasingly adopted by data holders. After the training of the multi-party secure computation model is completed, each data holder (or participant) obtains a part of the model, and in the model prediction stage, each participant runs the respective part of the model, so that multiple participants can jointly complete the model prediction.

[0043] Prediction using the multi-party secure computation model is an online resident service. Once the model is deployed online, it needs to be permanently available, otherwise it will affect the stability of the business and cause losses to the participants (data holders). On the other hand, the multi-party secure computation model is not static after the training is completed, and needs to be continuously improved according to the business and needs, so the online model needs to have the ability of gray-scale updating. That is, since the multi-party secure computation model needs to be continuously updated and involves many participants, if the new version of the model has a problem, the resulting comprehensive application exception and 100% damage to the online business will be particularly prominent.

[0044] Therefore, the method for upgrading an application provided in the embodiments of the present disclosure uses a first deployment and a second deployment to manage pods running containers of a first application at the same time, the first deployment is used to manage a first group of pods running containers of an old version of the first application, and the second deployment is used to manage a second group of pods running containers of a new version of the first application, so that only a part of pods corresponding to the first application can be upgraded. This is equivalent to setting a breakpoint in the process of application upgrade, and even if the new version of the application has a problem, only part of the traffic of the application will be affected. Compared with the related art, the method can stop loss in time, and avoids the problems that the application is abnormal in the related art and that 100% of online business is damaged.

[0045] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings Figure 2 The method provided in the embodiments of the present disclosure is described in detail.

[0046] In step S210, the first deployment is run.

[0047] The first deployment is used to manage the first group of pods, and each pod in the first group of pods runs a container of an old version of the first application.

[0048] In step S220, the second deployment is run.

[0049] The second deployment is used to manage the second group of pods, and each pod in the second group of pods runs a container of a new version of the first application.

[0050] In step S230, according to the first deployment and the second deployment, the number of pods in the first group of pods and the second group of pods is adjusted to upgrade the first application to the new version or roll back the first application to the old version.

[0051] The first application in the embodiments of the present disclosure can be the above-mentioned secure multi-party computation model (MPC model), and the projects that can be involved in the secure multi-party computation model include: micro-loan joint operation projects, international risk control phase II pipeline projects, joint risk control projects, and the like.

[0052] The embodiments of the present disclosure respectively manage a first group of pods running the first application container of an old version and a second group of pods running the first application container of a new version through a first deployment and a second deployment, and can adjust the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to achieve the purpose that while using the second deployment to upgrade part of the pods corresponding to the first application to the new version, the remaining pods can be kept as the old version using the first deployment, thereby avoiding the problem that the overall application is abnormal and the online business is 100% damaged caused by rolling upgrade of all the pods running the first application to the new version.

[0053] The first deployment or the second deployment in the embodiments of the present application is a stateless application running according to a corresponding deployment description file (or a configuration file of the deployment). The pods managed by the first deployment or the second deployment can be automatically deployed by the deployment controller according to the specific content in the above-mentioned deployment description file. The deployment description file can be a file directly submitted or updated by an operation and maintenance personnel (or a model administrator) according to requirements. Alternatively, as shown in the figure, the deployment description file can also be a file automatically deployed by the MPC deployment controller according to the MPC deployment description file (or the first configuration file). The MPC deployment can be understood as a deployment similar to the deployment, but located above the deployment to manage the deployment. The deployment is specially used to manage the deployment of the multi-party secure computing application, and therefore can be called the MPC deployment. Figure 3

[0054] The MPC deployment description file is also a configuration file, which can define the version, name, attribute and detailed definition of the deployment description file of the first application. The detailed definition of the deployment description file includes the template of the deployment, the number of replicas, the image and startup parameters of the first application, the image address of the container and the data participant to be deployed by the first application and the like. As an example, the content of the MPC deployment description file can be as follows:

[0055] 1. apiVersion: nueva.oasis / v1alpha1

[0056] ​2. kind: MPCdeployment

[0057] 3. metadata:

[0058] 4. name: model-1 # model name

[0059] 5. labels:

[0060] 6. dsaas / update-percent: "10"

[0061] 7. spec:

[0062] 8. template:

[0063] 9. spec:

[0064] 10. replicas: 2

[0065] 11. command: # command, args, image specifies the image and startup parameters of the model

[0066] 12. -. / bin / mpc_serving

[0067] 13. args:

[0068] 14. -model_path=data / model1

[0069] 15. image: mpc_serving:v1

[0070] 16. domains: # deployed to institutions a and b

[0071] 17. -domainId: Institution-a

[0072] 18. -domainId: Institution-b

[0073] In the above description file, the MPCdeployment description file is mainly composed of 3 parts of content:

[0074] 1. Spec.domains field: used to describe which parties this model has (such as parties a and b in the above example).

[0075] 2. Spec.template field: used to describe the detailed information of the model (i.e. the configuration information of deployment), which is used to synthesize the deployment for each participant, wherein the replicas field indicates how many replicas the model needs to be deployed in total (for example, the replicas field is 2 in the above example, i.e. the model needs to be deployed with 2 replicas in total), and the number of replicas of each institution is the same. The deployment is a native mechanism of K8s, and K8s will automatically create a pod according to the deployment.

[0076] 3. metadata.labels "dsaas / update-percent" label: used to set the proportion of the number of the second group of pods that need to be updated in a gray manner.

[0077] It can be understood that the MPCdeployment description file in the embodiments of the present application is mainly used for the generation of the subsequent deployment description file. In normal cases, the MPCdeployment description file and the deployment description file are in a 1:1 relationship, but in the model updating process, the MPCdeployment description file and the deployment description file are in a 1:2 relationship, i.e. the MPCdeployment description file corresponds to two different deployment description files of the old and new.

[0078] The embodiments of the present application automatically generate the description file of the deployment by setting an MPCdeployment controller on the deployment controller and directly submitting and updating the MPCdeployment description file by the operation and maintenance personnel. In this way, the operation and maintenance personnel can avoid the trouble of manually modifying or deleting the description file of the deployment for managing different versions of the first application when updating the first application, and it is easier to realize automatic deployment, which effectively improves the efficiency.

[0079] As discussed above, the number of pods managed by the first and second deployments can be adjusted as needed. Understandably, when the first application uses the aforementioned MPC model, the total number of containers for both the old and new versions of the first application deployed online at a given data holder can be a constant value; that is, the total number of containers for the first application corresponding to the MPC model held by a participating party remains unchanged. If this total number is M, and the number of pods managed by the first deployment is N, then the number of pods managed by the second deployment is MN. In other words, when updating the MPC model, if the first deployment adjusts the number of pods in the first group, the second deployment will correspondingly adjust the number of pods in the second group.

[0080] This application does not specifically limit the method for adjusting the number of pods in the first group and the number of pods in the second group. In some implementations, the number of pods managed by the first or second deployment can be adjusted by manually changing the value of the copy field in the configuration file of the first or second deployment.

[0081] In other implementations, such as Figure 3 As shown, the deployment controller can automatically adjust the value of the replica field in the configuration file of the first or second deployment based on the first parameter in the MPCdeployment description file (i.e., dsaas / update-percent mentioned above) to adjust the number of pods managed by the first or second deployment.

[0082] Generally speaking, before adjusting the number of pods managed by the first and second deployments based on the first and second deployments, it is necessary to first determine the number of the first group of pods that need to be maintained as the old version and the number of the second group of pods that need to be upgraded to the new version.

[0083] The first parameter, which is the proportion of the total number of pods of the first application corresponding to the MPC model in the second group of pods, can be defined in the MPCdeployment description file. The first parameter is used to update the proportion of the number of pods in the second group of pods, i.e., modifying the first parameter can update the proportion of the number of pods in the second group of pods. Referring to the foregoing, the total number of pods corresponding to the MPC model at a certain data holder is a constant value, therefore, the MPCdeployment controller can receive the first parameter and determine the number of pods in the first group of pods managed by the first deployment and the second group of pods managed by the second deployment according to the first parameter.

[0084] The specific determination method can be as follows: Spec.template.replicas in the MPCdeployment description file represents the total number of replicas, and dsaas / update-percent (i.e., the first parameter) represents the percentage of the number of replicas of the upgraded model. The value obtained by multiplying Spec.template.replicas by dsaas / update-percent is rounded, i.e., the number of pods in the second group of pods. The result of subtracting the number of pods in the new second group of pods from Spec.template.replicas is the number of pods in the first group of pods. For example, the number of replicas in the MPCdeployment description file is 2, and the first parameter is set to 10, then the number of pods in the second group of pods should be 0.2 rounded to 1, and the number of pods in the corresponding first group of pods is 1.

[0085] For another example, the number of replicas is 10, and the first parameter is set to 20 (i.e., the proportion is 20%), then the number of pods in the second group of pods should be 2 (i.e., 10*20%), and the number of pods in the first group of pods should be 8 (i.e., 10-2). That is, 2 replicas of the MPC model need to be newly configured, and the remaining 8 models are maintained as the old configuration. In this way, the operator can verify whether the new version of the model is correct in the 2 new models, if normal, the value of the first parameter can be continuously increased until 100% to update the first application to the new version. If not, the value of the first parameter can be modified to 0, so that all pods are returned to the old version.

[0086] In order to manage the corresponding number of pods, after determining the number of the first group of pods that need to be maintained as the old version and the number of the second group of pods that need to be upgraded to the new version, the configuration files of the first deployment and the second deployment also need to be set or updated accordingly.

[0087] When upgrading the application, the configuration file of the first deployment and the configuration file of the second deployment are updated, so that the value of the replicas field of the configuration file of the first deployment matches the number of the first group of pods, and the value of the replicas field of the configuration file of the second deployment matches the number of the second group of pods. That is, the number of the second group of pods is set to the replicas field of the second deployment, and the number of the first group of pods is set to the replicas field of the first deployment by the deployment controller.

[0088] Further, if the value of the replicas field of the configuration file of the first deployment and / or the value of the replicas field of the configuration file of the second deployment is not 0, a deployment update instruction is sent to the deployment controller, so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment.

[0089] If the value of the replicas field of the configuration file of the first deployment or the value of the replicas field of the configuration file of the second deployment is 0, a deployment deletion instruction is sent to the deployment controller, so that the deployment controller deletes the first deployment or the second deployment.

[0090] It can be understood that after the deletion and update of any deployment, K8s will automatically delete and create the pods corresponding to the deployment. If the number of pods does not meet the description of the replicas of the deployment, the number of pods will also be automatically adjusted.

[0091] By setting the first parameter to update the proportion of the number of pods in the second group of pods and determining the number of pods in the first group of pods and the second group of pods, the embodiments of the present application can update the same proportion of pods at different data holders, thereby completing all updates under the same number of updates. In this way, the problem of different data holders being out of sync in pod updating caused by directly modifying the number of pods in the first group of pods and the second group of pods can be avoided.

[0092] It should be noted that the configuration information (for example, the configuration content of the multi-party secure calculation model or the corresponding number of replicas) in the configuration file of the first deployment or the second deployment can be updated at any time during the online and subsequent upgrade processes. For example, when the multi-party secure calculation model is initially online, the corresponding deployment is only one, that is, the first deployment. When the multi-party secure calculation model is initially updated, the corresponding deployment can have two, that is, the first deployment and the second deployment. The model configuration information in the configuration file of the second deployment is different from the model configuration information in the configuration file of the first deployment. If the newly updated model is good after the initial update, the value of the replica field of the configuration file of the second deployment can be increased, and the value of the replica field of the configuration file of the first deployment can be correspondingly reduced.

[0093] In combination with the foregoing content, in the process of updating the multi-party secure calculation model, the number of replicas of the first deployment and the second deployment can be updated in the same proportion. Figure 3In the illustrated example, the model administrator needs to resubmit the MPCdeployment description file (or the first configuration file) whether the administrator modifies the dsaas / update-percent (i.e., the first parameter) tag or modifies the spec.template model configuration information (or the configuration information of the deployment). After the MPCdeployment description file is submitted, the MPCdeployment controller can process the configuration file of the first deployment or the second deployment accordingly. Specifically, after receiving the MPCdeployment description file submitted by the administrator, the MPCdeployment controller (referred to as an md-controller) first determines the number of deployments associated with the first application that already exist and the configuration information of the deployments. When the application is upgraded, the md-controller also determines the comparison result of the configuration information of the deployment in the MPCdeployment description file and the configuration information of the latest deployment in the deployments associated with the first application that already exist. After determining the above, the md-controller further performs subsequent work.

[0094] The specific processing flow can be as follows:

[0095] The md-controller scans the spec.domains field, and for each data holder (i.e., participant), the following operations are performed respectively and sequentially:

[0096] a) The md-controller scans the existing deployments corresponding to the first application (e.g., model-1) of the data holder. The number of deployments can be 0, 1, 2, or more. If the number of deployments is more than two, it is an abnormal case. At this time, only the latest two deployments are retained, and the remaining deployments are deleted. Subsequently, the case of two deployments is still executed.

[0097] b) If the number of existing deployments is 0, it means that the MPCdeployment description file is submitted for the first time, which is a new first application. No gray update logic is needed, and the md-controller creates a new deployment (i.e., the first deployment) according to the spec.template content and submits it to the deployment controller. The process ends.

[0098] c) If the number of existing deployments is 1, it is further divided into two cases:

[0099] First, the content of the existing deployment is the same as spec.template, which means that the administrator did not update the MPC deployment description file, but submitted the same MPC deployment description file twice, so this submission can be ignored, and the process ends.

[0100] Second, the content of the existing deployment is different from spec.template, which means that the administrator updated the MPC deployment description file, and a new round of gray-scale update begins. At this time, the md-controller creates a new deployment (i.e., the second deployment) according to the content of spec.template, and the existing deployment is the first deployment. Then, the replica number of the first and second deployments is adjusted according to the method described above, and the two deployments after adjustment are submitted to the deployment controller, and the process ends.

[0101] d) If the number of existing deployments is 2, sort the existing deployments according to the creation time, and the latest deployment associated with the first existing application is called d2, and the second new deployment is called d1. Compare the content of spec.template with d2, and handle according to whether the comparison result is the same or not:

[0102] First, spec.template is the same as d2, which means that the administrator did not update the content of spec.template, but only updated the "dsaas / update-percent" tag. In this case, it means that the administrator wants to continue to promote the progress of the gray-scale deployment. At this time, d2 is taken as the second deployment, and d1 is taken as the first deployment. The md-controller adjusts the replica number of the first and second deployments according to the method described above, and then submits the two deployments after adjustment to the deployment controller, and the process ends.

[0103] Second, Spec.template is different from d2, which means that the administrator started a new round of gray-scale update without ending the previous round of gray-scale update. At this time, the md-controller performs the following actions:

[0104] Delete d1; create a new deployment as the second deployment according to the content of spec.template, called d3, and take d2 as the first deployment; at the same time, adjust the replica numbers of the first and second deployments according to the foregoing method, and then submit the two deployments after adjustment to the deployment controller, and the process ends.

[0105] The embodiment of the present application proposes the concept of MPCdeployment on the basis of the original deployment of K8s. The MPCdeployment can manage different versions of the same model at the same time. When a new version of the model is to be put into operation, the MPCdeployment controller adjusts the proportion of the new and old models by maintaining two deployments at the bottom layer and constantly adjusting the replica number of the configuration file of the deployment. In this way, the model administrator can set a small proportion to observe whether the new version of the model is normal. If it is normal, the proportion can be increased. If it is not normal, the old MPCdeployment description file can be submitted to roll back the new version of the model, so as to avoid the problem that the online model is 100% damaged and affects the online business.

[0106] The method embodiment of the present application is described in detail above. Figures 1 to 3 The device embodiment of the present application is described in detail below. It should be understood that the description of the method embodiment and the description of the device embodiment correspond to each other, therefore, the parts not described in detail can be referred to the foregoing method embodiment. Figures 4 to 5 The device embodiment of the present application is described in detail below. It should be understood that the description of the method embodiment and the description of the device embodiment correspond to each other, therefore, the parts not described in detail can be referred to the foregoing method embodiment.

[0107] Figure 4 is a schematic structural diagram of an apparatus for upgrading an application provided by an embodiment of the present application. The apparatus 400 can include a first running module 410, a second running module 420, and an adjusting module 430. These modules are described in detail below.

[0108] The first running module 410 is configured to run a first deployment, and the first deployment is configured to manage a first group of pods, and each pod in the first group of pods runs a container of an old version of a first application.

[0109] The second running module 420 is configured to run a second deployment, and the second deployment is configured to manage a second group of pods, and each pod in the second group of pods runs a container of a new version of the first application.

[0110] The adjusting module 430 is configured to adjust the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to upgrade the first application to a new version or roll back the first application to an old version.

[0111] Optionally, as shown in the figure, the apparatus can further include a receiving module 440 configured to receive a first parameter, the first parameter being used to update the proportion of the number of pods in the second group of pods. Figure 4

[0112] The first determining module 450 is configured to determine the number of pods in the first group of pods and the second group of pods according to the proportion of the number of pods in the second group of pods.

[0113] Optionally, the apparatus can further include an updating module 460 configured to update the configuration file of the first deployment and the configuration file of the second deployment, so that the value of the replica field of the configuration file of the first deployment matches the number of pods in the first group of pods, and the value of the replica field of the configuration file of the second deployment matches the number of pods in the second group of pods.

[0114] The sending module 470 is configured to send a deployment update instruction to a deployment controller, so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment, if the value of the replica field of the configuration file of the first deployment and / or the value of the replica field of the configuration file of the second deployment is not 0.

[0115] Optionally, the sending module 470 is further configured to send a deployment deletion instruction to the deployment controller, so that the deployment controller deletes the first deployment or the second deployment, if the value of the replica field of the configuration file of the first deployment or the value of the replica field of the configuration file of the second deployment is 0.

[0116] Optionally, the first parameter is located in a first configuration file, the first configuration file further including configuration information of a deployment, and the apparatus 400 further includes a second determining module 480 configured to determine the number of deployments associated with the first application and a comparison result of the configuration information of the deployment and the configuration information of the latest deployment in the deployments associated with the first application.​

[0117] The setting module 490 is configured to set a second newest deployment and a newest deployment in the deployments associated with the first application as a first deployment and a second deployment respectively, and delete the remaining deployments in the deployments associated with the first application if the number of the deployments associated with the first application is greater than or equal to 2 and the comparison result is same, and the setting module is further configured to set the newest deployment as the first deployment, delete the remaining deployments in the deployments associated with the first application, and set a second deployment according to the configuration information of the deployment in the first configuration file if the number of the deployments associated with the first application is greater than or equal to 2 and the comparison result is different.

[0118] Optionally, the first application is a secure multi-party computation model.

[0119] Figure 5 FIG. 5 is a structural schematic diagram of an apparatus for upgrading an application according to another embodiment of the present disclosure. The apparatus 500 may, for example, be a computing device having a computing function. For example, the apparatus 500 may be a mobile terminal or a server. The apparatus 500 may include a memory 510 and a processor 520. The memory 510 may be configured to store executable code. The processor 520 may be configured to execute the executable code stored in the memory 510 to implement the steps in the various methods described above. In some embodiments, the apparatus 500 may further include a network interface 530, and data exchange between the processor 520 and an external device may be achieved through the network interface 530.

[0120] In the embodiments described above, all or some of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or some of the embodiments can be implemented in the form of a computer program product storing computer program instructions. When the computer program instructions are loaded into and executed by a computer, all or some of the procedures or functions according to the embodiments of the present disclosure are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer program instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer program instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital video disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0121] Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments of the present disclosure can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present disclosure.

[0122] In several embodiments provided by the present disclosure, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are merely schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0123] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may also be distributed to multiple network units. Part or all of the units can be selected to achieve the purpose of the embodiment of the present application according to actual needs.

[0124] In addition, each functional unit in various embodiments of the present disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0125] The above is only a specific embodiment of the present disclosure, but the protection scope of the present disclosure is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present disclosure, which should be covered within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method for upgrading an application, comprising: Run the first deployment, which manages the first group of pods, each of which runs a container with an older version of the first application. Run a second deployment to manage a second group of pods, each of which runs a container of the new version of the first application; Based on the first deployment and the second deployment, adjust the number of pods in the first group of pods and the second group of pods to upgrade the first application to the new version or roll back the first application to the old version; Before adjusting the number of pods in the first group of pods and the second group of pods based on the first deployment and the second deployment, the method further includes: Receive a first parameter, which is used to update the percentage of pods in the second group of pods; The number of pods in the first group and the second group are determined based on the proportion of pods in the second group; The first parameter is located in a first configuration file, which also includes deployment configuration information. After receiving the first configuration file, the method further includes: Determine the number of deployments associated with the first application and the comparison result between the configuration information of the deployments and the configuration information of the latest deployment among the deployments associated with the first application; If the number of deployments associated with the first application is greater than or equal to 2 and the comparison results are the same, the second newest deployment and the latest deployment in the deployments associated with the first application are set as the first deployment and the second deployment, respectively, and the remaining deployments in the deployments associated with the first application are deleted. If the number of deployments associated with the first application is greater than or equal to 2 and the comparison result is different, the latest deployment is set as the first deployment, the remaining deployments in the deployments associated with the first application are deleted, and the second deployment is set according to the deployment configuration information in the first configuration file.

2. The method according to claim 1, after determining the number of pods in the first group and the second group based on the proportion of pods in the second group, the method further includes: Update the configuration files of the first deployment and the second deployment so that the value of the copy field in the configuration file of the first deployment matches the number of pods in the first group of pods, and the value of the copy field in the configuration file of the second deployment matches the number of pods in the second group of pods. If the value of the copy field of the configuration file of the first deployment and / or the value of the copy field of the configuration file of the second deployment are not 0, a deployment update instruction is sent to the deployment controller so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment.

3. The method according to claim 2, after updating the configuration files of the first deployment and the second deployment, the method further includes: If the value of the copy field in the configuration file of the first deployment or the value of the copy field in the configuration file of the second deployment is 0, a deployment deletion command is sent to the deployment controller so that the deployment controller deletes the first deployment or the second deployment.

4. The method according to claim 1, wherein the first application is a secure multi-party computation model.

5. An apparatus for upgrading an application, comprising: The first running module is used to run the first deployment, which is used to manage the first group of pods, each of which runs a container with an older version of the first application. The second runtime module is used to run the second deployment, which is used to manage the second group of pods, each of which runs a container of the new version of the first application. The adjustment module is used to adjust the number of pods in the first group of pods and the second group of pods according to the first deployment and the second deployment, so as to upgrade the first application to the new version or roll back the first application to the old version; A receiving module is used to receive a first parameter, which is used to update the percentage of pods in the second group of pods. The first parameter is located in a first configuration file, which also includes deployment configuration information. The first determining module is used to determine the number of pods in the first group and the second group based on the proportion of the number of pods in the second group; The second determining module is used to determine the number of deployments associated with the first application and the comparison result between the configuration information of the deployments and the configuration information of the latest deployment among the deployments associated with the first application. The setting module is configured to, if the number of deployments associated with the first application is greater than or equal to 2 and the comparison result is the same, set the second newest deployment and the latest deployment among the deployments associated with the first application as the first deployment and the second deployment respectively, and delete the remaining deployments among the deployments associated with the first application. The setting module is also configured to, if the number of deployments associated with the first application is greater than or equal to 2 and the comparison result is different, set the latest deployment as the first deployment, delete the remaining deployments among the deployments associated with the first application, and set the second deployment according to the deployment configuration information in the first configuration file.

6. The apparatus according to claim 5, further comprising: The update module is used to update the configuration files of the first deployment and the second deployment, so that the value of the copy field of the configuration file of the first deployment matches the number of pods in the first group of pods, and the value of the copy field of the configuration file of the second deployment matches the number of pods in the second group of pods. The sending module is configured to send a deployment update instruction to the deployment controller if the value of the copy field of the configuration file of the first deployment and / or the value of the copy field of the configuration file of the second deployment is not 0, so that the deployment controller updates the first deployment according to the configuration file of the first deployment and / or updates the second deployment according to the configuration file of the second deployment.

7. The apparatus according to claim 6, wherein the sending module is further configured to send a deployment deletion instruction to the deployment controller if the value of the copy field of the configuration file of the first deployment or the value of the copy field of the configuration file of the second deployment is 0, so that the deployment controller deletes the first deployment or the second deployment.

8. The apparatus according to claim 5, wherein the first application is a secure multi-party computation model.

9. An apparatus for upgrading an application, comprising a memory and a processor, the memory storing executable code, the processor being configured to execute the executable code to implement the method of any one of claims 1-4.

Images