Methods and systems for managing application image versions based on Kubernetes

Abstract

This specification provides a method and system for managing application image versions based on Kubernetes. The application image provider can store version description information of the application image in Kubernetes through target customized resources, and participating parties can store version identifiers of the application image in Kubernetes through target customized resources. Furthermore, the version management service maintains a first list and a second list by monitoring the target customized resources in Kubernetes. The first list records version description information for each version of the application image, and the second list records version identifiers for the versions of the application image owned by multiple participating parties.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and in particular to a method and system for managing application image versions based on Kubernetes. Background Technology

[0002] Currently, the emergence of Kubernetes (k8s) has driven the popularization and implementation of popular technologies such as microservice architecture, making development, operation, and delivery increasingly simple. Therefore, more and more enterprises are using Kubernetes as their internal container orchestration platform to improve productivity.

[0003] In privacy-preserving computing scenarios, multiple parties often need to collaborate on tasks such as joint training. Before initiating a joint task, appropriate application image versions need to be selected among the participating parties; otherwise, application image version incompatibility may lead to joint task failure. Therefore, a solution for managing application image versions is required. Summary of the Invention

[0004] This specification describes one or more embodiments of a method for managing application image versions based on Kubernetes, which can greatly improve management efficiency.

[0005] Based on the first aspect, a method for managing application image versions based on Kubernetes is provided, including:

[0006] The Kubernetes control plane receives the first request, which includes update information related to the version of the target application image shared by multiple parties;

[0007] In response to the first request, the control plane creates a target customized resource for storing the updated information;

[0008] The control plane sends an update event notification to the version management service, and the version management service requests the control plane in advance to monitor changes to the target customized resource;

[0009] The version management service adds the update information to one of its maintained first and second lists based on the update event notification. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participating parties.

[0010] According to the second aspect, a method for performing joint tasks using application images is provided, including:

[0011] The task initiation service sends a query request to the version management service. The query request includes the image identifier of the target application image that is jointly owned by multiple participants involved in the task to be executed.

[0012] The version management service queries its local cache and returns the query result to the task initiation service. The cache content includes a first list and a second list. The first list records version description information for each version of the target application image, and the second list records version identifiers for each of the multiple participants. The cache content is maintained by the version management service by monitoring target customized resources in Kubernetes. The target customized resources store version update information of the target application image registered with Kubernetes. The query result indicates the target version compatible with the target application image for each participant.

[0013] According to the third aspect, a management system for application image versions based on Kubernetes is provided, including:

[0014] The Kubernetes control plane is used to receive the first request, which includes update information related to the version of the target application image shared by multiple parties;

[0015] The control plane is also configured to, in response to the first request, create a target customized resource, which is used to store the updated information;

[0016] The control plane is also used to send update event notifications to the version management service, which in advance requests the control plane to monitor changes to the target customized resource;

[0017] The version management service is used to add the update information to one of a first list and a second list it maintains based on the update event notification. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participating parties.

[0018] According to the fourth aspect, a system for performing joint tasks using application images is provided, comprising:

[0019] The task initiation service is used to send a query request to the version management service. The query request includes the image identifier of the target application image that is jointly owned by multiple participants involved in the task to be executed.

[0020] The version management service queries its local cached content and returns the query results to the task initiation service. The cached content includes a first list and a second list. The first list records version description information for each version of the target application image, and the second list records version identifiers for each of the multiple participating parties. The cached content is maintained by the version management service by monitoring target customized resources in Kubernetes. The target customized resources store version update information of the target application image registered with Kubernetes. The query results indicate the target version compatible with the target application image for each participating party.

[0021] According to a fifth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first or second aspect.

[0022] According to a sixth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of the first aspect or the second aspect.

[0023] This specification provides one or more embodiments of a Kubernetes-based application image version management method. Each participant registers the version identifier of its application image with Kubernetes. Specifically, Kubernetes stores these version identifiers by creating a target-customized resource. This avoids the need for each participant to maintain its own application image version information, thus eliminating the need for external storage. Furthermore, the version management service caches the target-customized resource locally, facilitating quick lookup of compatible application image versions for each participant before initiating any collaborative task, thereby improving the execution efficiency of collaborative tasks. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0026] Figure 2A schematic diagram illustrating a Kubernetes-based application image version management method according to one embodiment is shown.

[0027] Figure 3 A schematic diagram illustrating a Kubernetes-based application image version management method according to one embodiment is shown.

[0028] Figure 4 This diagram illustrates a method for performing a joint task using an application image according to one embodiment.

[0029] Figure 5 A schematic diagram of a Kubernetes-based application image version management system is shown according to one embodiment;

[0030] Figure 6 A schematic diagram of a system for performing joint tasks using an application image is shown according to one embodiment. Detailed Implementation

[0031] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0032] In traditional technologies, a version management service is typically deployed locally on each participant's machine. This service periodically scans the image storage repository and saves the version information of the application images pulled from it. Specifically, this version information is stored in a database. Then, before the task initiation service launches the joint task, it sends version information query requests to the version management services of each participant. After receiving responses from each participant, the task initiation service calculates the compatible target versions for each participant and issues the joint task based on those target versions.

[0033] In the above scheme, since each participant needs to rely on a database to store the application image version information, an additional external storage medium is required. Furthermore, each time the task initiation service initiates a task, it needs to send a query request to the version management services of each participant, increasing the complexity of the joint task execution. Also, in this scheme, if even one participant fails to return a normal response, the entire query process will fail.

[0034] To address this, this solution proposes that each participant register the version information (e.g., version identifier) ​​of their application images with Kubernetes. Specifically, within Kubernetes, this is done by creating a target-customized resource to store each participant's version identifier. The version management service requests to monitor changes to this target-customized resource in Kubernetes to cache the version identifiers of each participant. Then, when initiating a joint task, it calculates the compatible target versions for each participant based on the cached information. This avoids the need for each participant to maintain its own application image version identifier, thus eliminating the need for external storage. Furthermore, it facilitates the version management service in quickly retrieving compatible target versions from each participant when the task initiation service initiates a joint task, thereby improving the execution efficiency of the joint task.

[0035] Figure 1 This is a schematic diagram illustrating an implementation scenario of one of the embodiments disclosed in this specification. Figure 1 In Kubernetes, the application image provider can store the version description information of the corresponding application image through target custom resources, and participant A or participant B can store the version identifier of the corresponding application image through target custom resources. Taking participant A as an example, the version identifier of the corresponding application image could be: appimagex:v1.0.0, appimagex:v2.0.0, and appimagey:v1.0.0, etc. Furthermore, the aforementioned target custom resources can be, for example, CR1, CR2, ..., CRn, which are instances of Custom Resource Definitions (CRDs).

[0036] Figure 1 In this context, the version management service can request the Kubernetes control plane to monitor changes to the aforementioned target customized resources. When these resources change, the control plane can send an update event notification to the version management service to update its cached content for those resources. This cached content includes a first list and a second list. The first list records version descriptions for each version of the application image, while the second list records the version identifiers for the application image held by each of the multiple participating parties.

[0037] The aforementioned cached content is specifically used to query the target versions that each participant is compatible with for a certain application image when the version management service receives a query request sent by the task initiation service.

[0038] It should be understood that Figure 1This is just an example. In actual applications, providers can also register application image version description information through the service platform. Then, the service platform can call the Kubernetes API interface to store the corresponding application image version description information in Kubernetes through the target customized resource.

[0039] Figure 2 This diagram illustrates a method for managing application image versions based on Kubernetes according to one embodiment. Figure 2 In this method, the following steps may be included:

[0040] In step S202, the provider of the target application image sends a first request to the Kubernetes control plane.

[0041] In one embodiment, the target application image can be an application image jointly owned by multiple parties.

[0042] The first request may include version description information for the current version of the target application image. Additionally, it may include the current version of the target application image. This current version can be an initial version or a newer version.

[0043] In one embodiment, the provider can send the first request via a service platform. Specifically, the provider can first register the version description information of the current version of the target application image with the service platform. Then, the service platform sends the first request by calling the Kubernetes API.

[0044] In one embodiment, the version description information includes at least one of the following: basic information about the application image, configuration information for application startup dependencies, and deployment information of the application. Here, the application can refer to a container application launched based on an application image.

[0045] The basic information of the application image may include, but is not limited to, image name, version identifier, image identifier, and signature. Deployment information may include, but is not limited to, deployment name, role, number of replicas, upgrade policy, access policy, and basic information of the application container. Basic information of the application container may include, but is not limited to, startup command, mounted volumes, ports, and resources.

[0046] It should be understood that in practical applications, the above version description information may include more information, such as resource names, etc., and this manual does not limit this.

[0047] In step S204, in response to the first request, the Kubernetes control plane creates a target custom resource, which is used to store version description information of the current version of the target application image. In one embodiment, the target custom resource is a Custom Resource Definition (CRD), which can be used to extend Kubernetes resources.

[0048] Specifically, the Kubernetes API Server can be invoked in advance to add CRD resources to Kubernetes. Subsequently, upon receiving the first request mentioned above, the API Server creates an instance CR corresponding to the CRD, and the version description information is stored in the instance CR.

[0049] In one example, the created instance CR can be seen in the following code snippet:

[0050]

[0051]

[0052]

[0053] In the code snippet above, lines 3-4 (metadata.name) represent the resource name, lines 6-10 (spec.image) represent the basic information of the application image, such as image name / version identifier / image identifier (ID) / signature, etc., lines 11-19 (spec.configTemplates) represent the configuration template file information for application startup dependencies, and lines 20-64 (spec.deployTemplates) represent the application deployment template information, which is an array and mainly includes the following categories:

[0054] spec.deployTemplates[].name: represents the deployment name of the application;

[0055] spec.deployTemplates[].role: indicates the role of the application, 'client' indicates the deployment template information when the application acts as a client;

[0056] spec.deployTemplates[].replicas: Represents the default number of replicas for the application. This value can be dynamically overridden when the task is initiated.

[0057] spec.deployTemplates[].strategy.runningState: Represents the running strategy of the application pod;

[0058] `spec.deployTemplates[].strategy.rollingUpdate`: Represents the upgrade strategy for the application pod;

[0059] spec.deployTemplates[].strategy.networkPolicy: This indicates the access policy for this application. You can configure the application's access policy based on this setting later.

[0060] spec.deployTemplates[].spec: Represents the basic information of the application container, which defines the application's startup command, mounted volumes, ports, and resources.

[0061] It should be understood that when the first request also includes the current version of the target application image, the Kubernetes control plane can store the current version of the target application image locally.

[0062] In step S206, the Kubernetes control plane sends an update event notification to the version management service, which has requested the control plane in advance to monitor changes to the target customized resources.

[0063] The update events here include any of the following: creation, modification, and deletion.

[0064] Changes to target customized resources here include any of the following: creation, modification, and deletion.

[0065] In one embodiment, monitoring changes to the target customized resource can be implemented based on Kubernetes' list-watch mechanism.

[0066] The list-watch mechanism is an asynchronous message processing mechanism that enables the Kubernetes control plane and version management service to communicate and synchronize information. Specifically, when the version management service requests to monitor changes to a target customized resource, a long-lived TCP connection can be established between the Kubernetes control plane and the version management service. When a change is detected, an update event notification is sent to the version management service via this long-lived TCP connection. In a concrete example, this update event notification can carry version description information of the current version of the target application image.

[0067] In step S208, the version management service adds the current version description information of the target application image to the first list in its maintained cache based on the update event notification.

[0068] This first list is used to record version description information for each version of the target application image.

[0069] The above describes the management process of the version description information of the application image registered by the provider. The following describes the management process of the version identifier of the application image of the participating parties.

[0070] Figure 3 This diagram illustrates a method for managing application image versions based on Kubernetes according to one embodiment. Figure 3 In this method, the following steps may be included:

[0071] In step S302, any first participant among the multiple participants sends a first request to the Kubernetes control plane.

[0072] The first request may include a version identifier of the current version of the target application image obtained by the first participant. This version identifier can specifically be a version number.

[0073] The target application image mentioned above is downloaded from the image storage repository or loaded offline as an image package by the first participant before receiving the joint task request. After the first participant downloads the current version of the target application image to its local machine, it can store the version identifier of the current version and then send the aforementioned first request to the Kubernetes control plane.

[0074] In one embodiment, the aforementioned multiple participants are multiple organizations involved in privacy computation.

[0075] In another embodiment, the aforementioned participants each correspond to different namespaces in Kubernetes. Under each namespace, a participant-related service Pod runs. In a more specific embodiment, a version scanning service Pod is deployed under the participant's namespace. This version scanning service scans the version identifiers of the application images on the participant's compute nodes and can then send the aforementioned first request to the Kubernetes control plane.

[0076] In step S304, in response to the first request, the Kubernetes control plane creates a target custom resource, which is used to store the version identifier of the current version of the target application image.

[0077] The definition of target-customized resources here can be found above.

[0078] Similarly, the version identifier of the above application image is stored by creating an instance CR corresponding to the CRD in Kubernetes.

[0079] In one example, the created instance CR can be seen in the following code snippet:

[0080]

[0081]

[0082] In the code snippet above, `metadata.name` on line 4 represents the resource name, and `metadata.name.namespace` on line 5 represents the namespace to which the resource belongs, i.e., the namespace to which the participating parties belong. `spec.image` on lines 6-13 represents the version information for each version of the application image named "secretflow", including the version identifier.

[0083] In step S306, the Kubernetes control plane sends an update event notification to the version management service, which has previously requested the Kubernetes control plane to monitor changes to the target customized resource.

[0084] As mentioned earlier, the version management service can monitor changes to target customized resources based on the list-watch mechanism.

[0085] In step S308, the version management service adds the current version identifier to the field corresponding to the first participant in the second list in the cache based on the update event notification.

[0086] The second list above is used to record the version identifier of the target application image that each participating party has.

[0087] Of course, in practical applications, the second list mentioned above can also be used to record the version identifiers of other application images owned by each participant. Taking any first participant as an example, "other application images" here includes application images owned only by the first participant.

[0088] This specification provides one or more embodiments of an application image version management method. Each participant registers the version information (e.g., version identifier) ​​of its application images with Kubernetes. Specifically, in Kubernetes, this is done by creating a target-customized resource to store the version identifiers of each participant. The version management service requests to monitor changes to the target-customized resource in Kubernetes to cache the version identifiers of each participant. Then, when initiating a joint task, it calculates the compatible target version for each participant based on the cached content. This avoids the need for each participant to maintain its own application image version information separately, thus eliminating the need for external storage media. Furthermore, the target-customized resource in Kubernetes can store not only application image version identifiers but also version description information such as application startup dependency configuration information, greatly enriching the stored application image version information.

[0089] It should be noted that, with the version management service caching the version identifiers of the application images of each participant, the task initiation service can call the version management service to query the target versions compatible with a given application image from each participant, and then initiate a joint task. This will be explained in detail below.

[0090] Figure 4 A schematic diagram illustrating a method for performing a federated task using an application image according to one embodiment is shown. Figure 4 As shown, the method may include the following steps:

[0091] In step S402, the task initiation service sends a query request to the version management service. The query request includes the image identifiers of the target application images owned by the multiple participants involved in the task to be executed.

[0092] It should be understood that the task to be executed here can be jointly executed by applications launched separately by multiple participants based on the target application image. This joint execution specifically includes communication between the applications launched separately by the multiple participants, etc.

[0093] In a more specific embodiment, where the aforementioned multiple participants are multiple institutions involved in privacy computation, the aforementioned task to be performed may specifically be a joint model training task.

[0094] In step S404, the version management service queries its local cached content and returns the query result to the task initiation service.

[0095] The query results above at least indicate the compatible target versions that each participant has for the target application image.

[0096] As mentioned earlier, the local cached content of the version management service includes a first list and a second list. The first list is used to record the version description information of each version of the application image, and the second list is used to record the version identifiers of the application images owned by multiple participants.

[0097] It should be understood that the number of application images in the first and second lists mentioned above can be multiple. When there are multiple application images, the query of local cached content can specifically include the version management service first determining the target application image to be queried based on the image identifier. Then, it queries the second list to obtain the version identifiers possessed by each participant for the target application image. If the version identifier is a version number, a maximum common version number can be determined based on the version numbers possessed by each participant, and the version corresponding to this maximum version number can be used as the target version.

[0098] Of course, in practical applications, other strategies or rules can be combined to determine the target version mentioned above, and this specification does not limit this.

[0099] After determining the target version, the version management service can also query the first list to obtain version description information of the target application image, such as application startup dependency configuration information and application deployment information. Therefore, the query results can also indicate application startup dependency configuration information, etc.

[0100] After receiving the query results, the task initiation service sends task execution instructions to each participant, which may include the name and version number of the target application image and the configuration information of the application startup dependencies.

[0101] After receiving the task execution instruction, each participating party can launch the corresponding application based on the name and version number of the target application image, and jointly execute the task to be executed through the launched application.

[0102] The method for executing joint tasks using application images provided in the embodiments of this specification allows the task initiation service to query the target versions compatible with the target application image for each participant simply by calling the version management service when initiating a joint task, without having to send a request to each participant to query version information. This improves version query efficiency and, consequently, joint task execution efficiency.

[0103] Corresponding to the above-described Kubernetes-based application image version management method, one embodiment of this specification also provides a Kubernetes application image version management system, such as... Figure 5 As shown, the system may include:

[0104] The Kubernetes control plane 502 is used to receive the first request, which includes update information related to the version of the target application image that is shared by multiple parties 504.

[0105] Control plane 502 is also configured to, in response to the first request, create a target custom resource for storing update information.

[0106] Control plane 502 is also used to send update event notifications to version management service 506, which requests control plane 502 in advance to monitor changes to the target customized resource.

[0107] Version management service 506 is used to add update information to one of its maintained first and second lists based on update event notifications. The first list is used to record version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participants.

[0108] In one embodiment, the first request comes from any of the multiple participants, and the update information is the version identifier of the current version of the target application image obtained by the first participant.

[0109] Version control service 506 is specifically used for:

[0110] Add a first version identifier to the field corresponding to the first participant in the second list.

[0111] In another embodiment, the first request is issued by the provider of the target application image, and the update information includes version description information of the current version of the target application image.

[0112] The version description information includes at least one of the following: basic information about the application image, configuration information of the application startup dependencies, and deployment information of the application.

[0113] Version control service 506 is specifically used for:

[0114] Add the current version description information of the target application image to the first list.

[0115] In a more specific embodiment, the first request described above is forwarded to control plane 502 via the service platform.

[0116] In one embodiment, the aforementioned multiple participants 504 correspond to different namespaces in Kubernetes, and version scanning services are deployed under each of the different namespaces;

[0117] The aforementioned first request is issued by any first participant among multiple participants through the first version scanning service under its namespace.

[0118] The functions of each functional module of the system in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the system provided in one embodiment of this specification will not be repeated here.

[0119] This specification provides an example of a Kubernetes-based application image version management system that stores application image version information by creating a target-customized resource in Kubernetes, thereby avoiding the need to introduce additional external storage media.

[0120] Corresponding to the above-described method for performing federated tasks using application images, one embodiment of this specification also provides a system for performing federated tasks using application images, such as... Figure 6 As shown, the system may include:

[0121] The task initiation service 602 is used to send a query request to the version management service 604. The query request includes the image identifier of the target application image jointly owned by multiple participants involved in the task to be executed.

[0122] Version management service 604 queries its local cache content and returns the query results to task initiation service 602.

[0123] The query results above indicate the target version that each participant is compatible with for the target application image.

[0124] The aforementioned cached content includes a first list and a second list. The first list records version description information for each version of the target application image, while the second list records version identifiers for each of the multiple participating parties. This cached content is maintained by the version management service 604 by monitoring target-customized resources in Kubernetes. These target-customized resources store version update information for the target application image registered with Kubernetes.

[0125] The functions of each functional module of the system in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the system provided in one embodiment of this specification will not be repeated here.

[0126] This specification provides an embodiment of a system for executing joint tasks using application images, which can greatly improve the execution efficiency of joint tasks.

[0127] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 , Figure 3 or Figure 4 The method described.

[0128] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, it implements a combination... Figure 2 , Figure 3 or Figure 4 The method described.

[0129] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0130] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0131] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this specification. It should be understood that the above description is only a specific embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this specification should be included within the scope of protection of this specification.

Claims

1. A method for managing application image versions based on Kubernetes, comprising: The Kubernetes control plane receives the first request, which includes update information related to the version of the target application image shared by multiple parties; In response to the first request, the control plane creates a target customized resource for storing the updated information; The control plane sends an update event notification to the version management service, and the version management service requests the control plane in advance to monitor changes to the target customized resource; The version management service adds the update information to one of its maintained first and second lists based on the update event notification. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participating parties.

2. The method according to claim 1, wherein, The first request comes from any first participant among the plurality of participants, and the update information is the version identifier of the current version of the target application image obtained by the first participant.

3. The method according to claim 2, wherein, The added / updated information includes: Add the version identifier to the field corresponding to the first participant in the second list.

4. The method according to claim 1, wherein, The first request is issued by the provider of the target application image, and the update information includes version description information of the current version of the target application image.

5. The method according to claim 4, wherein, The addition of the updated information includes: Add the version description information of the current version to the first list.

6. The method according to claim 4, wherein, The first request is forwarded to the control plane via the service platform.

7. The method according to claim 1, wherein, The multiple participants correspond to different namespaces in the Kubernetes, and version scanning services are deployed in different namespaces. The first request is issued by any first participant among the plurality of participants through the first version scanning service under its namespace.

8. The method according to claim 1, wherein, The version description information includes at least one of the following: basic information of the application image, configuration information of application startup dependencies, and application deployment information.

9. A method for performing a joint task using an application image, comprising: The task initiation service sends a query request to the version management service, the query request including, The image identifier of the target application image jointly owned by multiple parties involved in the task to be executed; The version management service queries its local cache content and returns the query results to the task initiation service. The cache content includes a first list and a second list. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participants. The cache content is maintained by the version management service by monitoring the target customized resources in Kubernetes. The target customized resource is used to store version update information of the target application image registered with Kubernetes; The query results indicate to each participant the target version compatible with the target application image.

10. A management system for application image versions based on Kubernetes, comprising: The Kubernetes control plane is used to receive the first request, which includes update information related to the version of the target application image shared by multiple parties; The control plane is also configured to, in response to the first request, create a target customized resource, which is used to store the updated information; The control plane is also used to send update event notifications to the version management service, which in advance requests the control plane to monitor changes to the target customized resource; The version management service is used to add the update information to one of a first list and a second list it maintains based on the update event notification. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participating parties.

11. A system for performing federated tasks using application images, comprising: The task initiation service is used to send query requests to the version management service, the query requests including... The image identifier of the target application image jointly owned by multiple parties involved in the task to be executed; The version management service is used to query its local cached content and return the query results to the task initiation service. The cached content includes a first list and a second list. The first list is used to record the version description information of each version of the target application image, and the second list is used to record the version identifier of each version owned by each of the multiple participants. The cached content is maintained by the version management service by monitoring the target customized resources in Kubernetes. The target customized resource is used to store version update information of the target application image registered with Kubernetes; The query results indicate to each participant the target version compatible with the target application image.

12. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed in the computer, it causes the computer to perform the method of any one of claims 1-9.

13. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-9.

Images