Container upgrading method, system, equipment and medium

Abstract

The embodiment of the invention provides a container upgrading method, system and device and a medium. The method comprises the steps of obtaining a to-be-upgraded container mirror image and a container upgrading request; if the upgrade type identifier contained in the container upgrade request is in-situ upgrade, verifying the upgrade content of the to-be-upgraded container mirror image; and if the upgrading content passes the verification, sending the to-be-upgraded container mirror image to an elastic container instance agent, so that the elastic container instance agent executes an in-situ upgrading task. The upgrading content is managed by the elastic container instance agent, the upgrading requirements of various contents can be met, in addition, the in-situ upgrading task is executed by utilizing the elastic container instance agent, and the upgrading efficiency can be effectively improved. Meanwhile, in the upgrading process, whether upgrading is needed or not and whether upgrading is completed or not can be known by comparing the hash values, and therefore the upgrading progress can be mastered in real time.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a container upgrade method, system, device and medium. Background Art

[0002] Kubernetes (K8S for short) cluster is an open source container orchestration management platform for managing containerized applications on multiple hosts in a cloud platform. It provides a mechanism for application deployment, planning, updating, and maintenance.

[0003] The deployment group (Deployment) in the K8S cluster supports two upgrade modes for application instances (Pod): rolling upgrade (RollingUpdate) and replacement upgrade (RecreateUpdate). However, both upgrade modes require deleting the old Pod and creating a new Pod. Using these two methods will result in modifications to the Internet address (IP address), storage space, and device information, which will increase the workload and reduce the upgrade efficiency. In addition, the upgrade progress is uncontrollable. Summary of the invention

[0004] In order to solve or improve the problems existing in the prior art, the embodiments of the present application provide a container upgrade method, system, device and medium.

[0005] In a first aspect, in one embodiment of the present application, a container upgrade method is provided. Applied to an interactive service component, the method includes:

[0006] Get the container image to be upgraded and the container upgrade request;

[0007] If the upgrade type identifier included in the container upgrade request is in-place upgrade, verifying the upgrade content of the container image to be upgraded;

[0008] If the upgrade content verification passes, the container image to be upgraded is sent to the elastic container instance agent so that the elastic container instance agent performs the in-place upgrade task.

[0009] In a second aspect, in one embodiment of the present application, a container upgrade method is provided, which is applied to an elastic container instance agent, and the method includes:

[0010] In response to a container upgrade request including an upgrade type identifier of an in-place upgrade, comparing the received container image to be upgraded; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component;

[0011] If the comparison result is that the to-be-upgraded container image is different from the upgraded container, the upgraded container is upgraded to a target container corresponding to the to-be-upgraded container image.

[0012] In a third aspect, in one embodiment of the present application, a container upgrade method is provided, which is applied to a client, and the method includes:

[0013] Sending the container image to be upgraded and the container upgrade request including the upgrade type identifier of the in-place upgrade to the interactive service component; so that the interactive service component sends the container image to be upgraded to the elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded;

[0014] Receive first version information fed back by the elastic container instance agent;

[0015] If the first version information is the same as the second version information corresponding to the container image to be upgraded, the upgrade is completed.

[0016] In a fourth aspect, in one embodiment of the present application, a container upgrade system is provided, including:

[0017] An interactive service component, configured to execute the method described in the first aspect;

[0018] An elastic container instance agent, used to execute the method described in the second aspect;

[0019] The client is used to execute the method described in the third aspect.

[0020] In a fifth aspect, in one embodiment of the present application, an electronic device is provided, including a memory and a processor; wherein:

[0021] The memory is used to store programs;

[0022] The processor is coupled to the memory, and is used to execute the program stored in the memory to implement the method described in the first aspect, or to implement the method described in the second aspect, or to implement the method described in the third aspect.

[0023] In a sixth aspect, in one embodiment of the present application, a non-transitory machine-readable storage medium is provided, on which an executable code is stored. When the executable code is executed by a processor of an electronic device, the processor executes the container upgrade method described in the first aspect, the container upgrade method described in the second aspect, or the container upgrade method described in the third aspect.

[0024] The technical solution provided by the embodiment of the present application can adopt an in-place upgrade method when it is necessary to upgrade certain fields in the container without rebuilding the Pod node. Specifically, the client sends the generated container image to be upgraded and the container upgrade request to the interactive service component. When the interactive service component determines that the upgrade content in the container image to be upgraded meets the content allowed by the elastic container instance agent, the in-place upgrade task can be executed. Then, the container image to be upgraded is sent to the elastic instance container agent so that the elastic container instance agent performs the in-place upgrade task. Through the above scheme, the elastic container instance agent manages the upgrade content, which can meet the upgrade requirements of various contents. In addition, the use of the elastic container instance agent to perform the in-place upgrade task can effectively improve the upgrade efficiency. At the same time, during the upgrade process, by comparing the hash values, it can be known whether an upgrade is required and whether the upgrade is completed, so that the upgrade progress can be grasped in real time. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0026] Figure 1 A schematic diagram of a process for upgrading a container provided in an embodiment of the present application;

[0027] Figure 2 A schematic diagram of another method for upgrading a container provided in an embodiment of the present application;

[0028] Figure 3 A schematic diagram of a process flow of another container upgrade method provided in an embodiment of the present application;

[0029] Figure 4 The proxy execution upgrade process illustrated in the embodiment of the present application;

[0030] Figure 5 A schematic diagram of the status reporting process provided in the embodiment of the present application;

[0031] Figure 6 A schematic diagram of a container upgrade system provided in an embodiment of the present application;

[0032] Figure 7 A schematic diagram of multi-terminal interaction for illustrating an embodiment of the present application;

[0033] Figure 8a A schematic diagram of the structure of a container upgrading device provided in an embodiment of the present application;

[0034] Figure 8b A schematic diagram of the structure of another container upgrading device provided in an embodiment of the present application;

[0035] Figure 8c A schematic diagram of the structure of another container upgrading device provided in an embodiment of the present application;

[0036] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0038] In some processes described in the specification, claims and the above-mentioned figures of the present application, multiple operations appearing in a specific order are included, and these operations may not be executed or executed in parallel in the order in which they appear in this article. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., do not represent the order of precedence, and do not limit "first" and "second" to different types. In addition, the embodiments described below are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0039] In a standard Kubernetes cluster, application release updates the Pod template and triggers Pod reconstruction, that is, creating a new Pod and deleting the old Pod. However, triggering Pod reconstruction in a Serverless Kubernetes cluster will involve resource production and assembly at the IaaS level, which is far less efficient than a standard Kubernetes cluster. In actual applications, when upgrading, it may only be necessary to upgrade a certain field in a container in the Pod, rather than upgrading the Pod as a whole. Therefore, an in-place upgrade can be used to improve the upgrade efficiency. However, when the in-place upgrade solution is used in a Serverless Kubernetes cluster, the upgrade progress is uncontrollable. Generally speaking, the image names of the two images reported, spec.containers[x].image and status.containerStatuses[x].image, should be consistent, so that the upgrade progress and whether the container is successfully upgraded can be distinguished based on the image name. However, in some cases, there may be inconsistencies between spec.containers[x].image and status.containerStatuses[x].image, because the status.containerStatuses[x].image reported by the kubelet process is actually the image name corresponding to the container obtained from the CRI interface. If there are multiple images corresponding to an imageID on the Node node, then any one of the image names may be reported, resulting in different image names for spec.containers[x].image and status.containerStatuses[x].image, misleading the judgment of the upgrade progress. In addition, in some container upgrade scenarios, the fields allowed to be upgraded are very limited. Therefore, a solution that can support in-place upgrades in ServerlessKubernetes clusters is needed.

[0040] Terminology explanation:

[0041] Kubernetes is an open source container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management. When deploying an application in a production environment, you usually need to deploy multiple instances of the application to load balance application requests.

[0042] Pod is a scheduling unit in Kubernetes. A Pod contains one or more containers. When there are multiple containers, these containers share the storage, network, etc. in the same Pod.

[0043] Serverless Kubernetes, a Kubernetes cluster without node operation and maintenance.

[0044] API-Server is an important management API layer of K8s, and plays the role of interaction entry. It is responsible for providing the Restful API access endpoint and persisting the data to the etcd server. It also provides a unified API call entry point to the outside world. All interactions are centered on the API Server.

[0045] The technical solution implemented in this application will be explained below in conjunction with specific embodiments.

[0046] like Figure 1 A flowchart of a container upgrade method provided in an embodiment of the present application. The execution subject of the method may be an interactive service component. Figure 1 You can see that the specific steps include the following:

[0047] 101: Get the container image to be upgraded and the container upgrade request.

[0048] 102: If the upgrade type identifier included in the container upgrade request is in-place upgrade, verify the upgrade content of the container image to be upgraded.

[0049] 103: If the upgrade content verification passes, the container image to be upgraded is sent to the elastic container instance agent, so that the elastic container instance agent performs the in-place upgrade task.

[0050] The container image to be upgraded mentioned here is formulated by the client according to the upgrade requirements. The container image to be upgraded may contain various upgraded fields, such as container image, container command, container env, container volume, etc. When the client provides the container image to be upgraded, it will notify the interactive service component (API server) in the form of a container upgrade request to perform corresponding verification, etc. The interactive service component (API server) serves as the brain component in the Kubernetes cluster. For example, after the interactive service component receives the container upgrade request, it verifies the content in the container image package to be upgraded, such as verifying whether the upgrade field contained in the image package is a field that is allowed to be upgraded. The specific verification process will be described in detail in the following embodiments, and will not be repeated here.

[0051] When upgrading the container in the Pod, you need to determine the upgrade type identifier. The upgrade type identifiers mentioned here include: in-place upgrade, rolling upgrade, replacement upgrade, etc. In actual applications, you can clearly mark whether to use the in-place upgrade solution in the container upgrade request, and you can also indicate the in-place upgrade method in the annotation of the container image to be upgraded.

[0052] This solution is applied to the in-place upgrade scenario, that is, to upgrade the container in the Pod without rebuilding the entire Pod. In the in-place upgrade application scenario, some fields in the container are often upgraded, but the upgrade content is limited, that is, some upgrade content is allowed, and some upgrade content is not allowed. By verifying the upgrade content, the upgrade content can be distinguished to ensure that the in-place upgrade can be successful. If the in-place upgrade is not marked, it is considered to be the deletion and reconstruction of the Pod, and there is no need to verify the upgrade content.

[0053] When it is determined to use in-place upgrade and the upgrade content is verified, the container image to be upgraded is sent to the Elastic Container Instance (ECI) agent. After the Elastic Container Instance agent receives the container upgrade request, it will first stop the upgraded container and then create a new target container based on the container image to be upgraded. In the subsequent upgrade process, the Elastic Container Instance agent will perform the specific upgrade process.

[0054] For example, the elastic container instance agent compares the received container image to be upgraded with the currently used upgraded container by hash value. If the comparison result shows that the hash values ​​of the container image to be upgraded and the upgraded container are different, it means that the two are different containers, and the upgrade is allowed. The container image to be upgraded is further pulled, and the upgraded container is stopped. When stopping the upgraded container, the prtstop process is executed first, so that the Pod and other related components and nodes are prepared to stop interacting with the upgraded container in advance, and then the upgraded container is actually stopped to avoid the adverse impact of the sudden stop of the upgraded container on the normal operation of other components or nodes.

[0055] In the above container upgrade solution, by rationally managing the upgrade content and using the elastic container instance agent to perform the upgrade operation, it is possible to effectively meet the in-place upgrade requirements of various upgrade contents and improve the upgrade efficiency.

[0056] In one or more embodiments of the present application, the upgrade content of the container image to be upgraded is verified, including: obtaining an upgrade field contained in the container image to be upgraded; if the upgrade field is a field allowed by the elastic container instance agent, the verification passes; if the upgrade field is not a field allowed by the elastic container instance agent, terminating the in-place upgrade.

[0057] In the prior art, in traditional K8s, when upgrading a created Pod, only the image field in the containers / init containers and the active deadline seconds field are allowed to be modified in the Pod spec. Other fields are not allowed. In the present application scheme, the elastic container instance agent in serverless kubernetes is used to perform in-place upgrade tasks, and more fields are allowed as upgrade content, such as container image, container command, container env, container volume, etc. These upgrade contents can aggregate multiple different fields together. After receiving the container image package to be upgraded and determining the upgrade fields contained in the image package, it is compared with the aggregated upgrade content. If the upgrade field is included in the aggregated upgrade content, it can be known that the image package to be upgraded is an allowed field. Conversely, if the upgrade field is not included in the aggregated upgrade content, it can be known that the image package to be upgraded does not contain an allowed field.

[0058] In actual applications, although the elastic container instance agent can support the upgrade content of more fields, it does not support unlimited support. The elastic container instance agent also needs to check and judge the upgrade field. When the upgrade field is a field allowed by the elastic container instance agent, the verification passes. Otherwise, the verification fails. As an optional method, a field whitelist can be set for the elastic container instance agent, and the fields within the whitelist range are considered to have passed the verification. On the contrary, if the upgrade content is not included in the whitelist range, the verification fails. For example, if the upgrade content contains not only the container command, but also the IP address modification corresponding to the Pod, the verification fails because the IP address modification is not within the whitelist range. Then terminate the in-place upgrade task.

[0059] Through the above method, the elastic container instance agent is used to effectively manage the upgrade content, which can better meet the upgrade needs of diversified fields.

[0060] In one or more embodiments of the present application, the upgrade content of the container image to be upgraded is verified, including: obtaining the upgrade field contained in the container image to be upgraded; if the upgrade field is not a field allowed by the elastic container instance agent, performing a rolling upgrade or a replacement upgrade.

[0061] In actual applications, if some upgrade contents are not allowed by the elastic container instance agent, the upgrade task can be performed by rolling upgrade or replacement upgrade.

[0062] It should be noted that because rolling upgrades or replacement upgrades take a long time and require deleting old Pods and creating new ones, which involves a lot of content, it is necessary to obtain the user's consent before abandoning the in-place upgrade plan and adopting rolling upgrades or replacement upgrades.

[0063] Through the above method, when the in-place upgrade cannot meet the upgrade requirements, a rolling upgrade or replacement upgrade method can be selected according to the actual situation to meet the upgrade requirements of diversified upgrade content.

[0064] In one or more embodiments of the present application, after the elastic container instance agent completes the in-place upgrade task, receiving first version information corresponding to the container image to be upgraded;

[0065] If the second version information included in the container upgrade request is the same as the first version information, the upgrade is successful; or,

[0066] Sending the first version information to the client, so that the client determines whether the first version information is the same as the second version information;

[0067] If they are the same, the upgrade is successful.

[0068] In actual applications, after the elastic container instance agent completes the upgrade task for the upgraded container, the version of the target container currently upgraded based on the image of the container to be upgraded is updated, for example, it can be updated to the first version information. Since the interactive service component and the client cannot yet determine whether the elastic instance container agent has successfully completed the in-place upgrade task, the upgraded first version information can be sent to the interactive service component after the elastic instance container agent completes the upgrade task. So that the interactive service component can determine whether the upgrade is successful based on the received first version information and the second version information included in the container upgrade request. And send the upgrade success result to the client.

[0069] In another optional solution, after receiving the first version information, the interactive service component can send the first version information to the client, and then the client performs the comparison task. Specifically, after receiving the first version information, the client compares the second version information when generating the upgrade request with the first version information. If the two are the same, it indicates that the upgrade is successful, and if the two are different, it indicates that the upgrade fails.

[0070] In the above manner, the client and the interactive service component determine whether the upgrade is successful based on the version information, so that the client and the interactive service component can understand the upgrade status in time.

[0071] Based on the same idea, the embodiment of the present application also provides another container upgrade method, which is applied to elastic container instance proxy. Figure 2 A flow chart of another container upgrade method provided in an embodiment of the present application. Figure 2 You can see that the specific steps include the following:

[0072] 201: In response to a container upgrade request including an upgrade type identifier of an in-place upgrade, compare the received container image to be upgraded; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component.

[0073] 202: If the comparison result is that the to-be-upgraded container image is different from the upgraded container, the upgraded container is upgraded to a target container corresponding to the to-be-upgraded container image.

[0074] As mentioned above, after determining that the container upgrade request is an in-place upgrade, the hash values ​​of the container image to be upgraded and the container to be upgraded will be compared. If the hash values ​​of the two are the same, it means that they are the same container and no upgrade is required; conversely, if the hash values ​​of the two are different, it means that they are different containers and an upgrade is required.

[0075] After determining that an upgrade is required, the elastic container instance control component will verify the upgrade content of the container image to be upgraded. The elastic container instance control component can know which containers it controls, and through verification, it can know whether the upgrade content belongs to the containers it controls, and whether the upgrade content is allowed by the elastic container instance agent. After the verification passes, the upgrade interface (updatePod interface) is called to the corresponding elastic container instance (ECI), and then the corresponding elastic container instance is called through the upgrade interface to perform the upgrade task of the upgraded container contained therein.

[0076] In the above container upgrade solution, by rationally managing the upgrade content and using the elastic container instance agent to perform the upgrade operation, it is possible to effectively meet the in-place upgrade requirements of various upgrade contents and improve the upgrade efficiency.

[0077] In one or more embodiments of the present application, the comparing the received container image to be upgraded includes: calculating a first hash value of the container image to be upgraded; comparing the first hash value with a second hash value of the upgraded container; if the first hash value is different from the second hash value, it indicates that the comparison result is that the container image to be upgraded is different from the upgraded container; if the first hash value is the same as the second hash value, terminating the in-place upgrade.

[0078] As mentioned above, each container has a unique hash value. Here, the hash value of the container image to be upgraded is used as the first hash value, and the hash value of the container to be upgraded is used as the second hash value. If the first hash value is the same as the second hash value, it means that the currently running container does not need to be upgraded. On the contrary, if the first hash value is different from the second hash value, it means that the currently running container needs to be upgraded. Before executing the upgrade task, by calculating and comparing the hash values, you can know whether an upgrade is required to avoid upgrade errors.

[0079] In one or more embodiments of the present application, upgrading the upgraded container to a target container corresponding to the container image to be upgraded includes: stopping the operation of the upgraded container; updating the upgraded container to the target container; and updating a first hash value and first version information corresponding to the target container.

[0080] like Figure 4 The proxy execution upgrade process illustrated in the embodiment of this application. Figure 4 As shown in the figure, the specific actions performed by the elastic container instance agent during the upgrade process are as follows:

[0081] Start the in-place upgrade by first calculating the first hash value of the container image to be upgraded, and then comparing it with the second hash value of the container to be upgraded. If the comparison result shows that the first hash value and the second hash value are different, the upgrade begins.

[0082] After starting the upgrade, first pull the image of the container to be upgraded. Stop the old container (that is, the upgraded container), enter the container stop process, execute the prestop process of the old container, and after notifying all parties that the old container is ready to be stopped, actually stop the old container. This can effectively avoid or reduce the impact of stopping the old container on other nodes or components.

[0083] Next, a new container is created based on the container image to be upgraded. As long as this step is successful, the first hash value of the new container image is written, indicating that the container has been successfully updated. If any of the previous steps fails, a retry will be performed.

[0084] After the upgrade is complete, you can start a new target container and enter the container startup process. Execute the prestart of the new container to end the upgrade process.

[0085] Through the above solution, after the upgraded container is determined, the stop task is executed first, so as to reduce the impact of the container upgrade process on normal work.

[0086] In one or more embodiments of the present application, after the upgraded container is upgraded to the target container corresponding to the container image to be upgraded, it also includes: feeding back the first version information to the interactive access component or the client, so that the interactive component or the client determines whether the upgrade is successful based on the first version information.

[0087] In actual applications, after the elastic container instance agent completes the upgrade task for the upgraded container, the version of the target container currently upgraded based on the image of the container to be upgraded is updated, for example, it can be updated to the first version information. Since the interactive service component and the client cannot yet determine whether the elastic instance container agent has successfully completed the in-place upgrade task, the upgraded first version information can be sent to the interactive service component after the elastic instance container agent completes the upgrade task. So that the interactive service component can determine whether the upgrade is successful based on the received first version information and the second version information included in the container upgrade request. And send the upgrade success result to the client.

[0088] In another optional solution, after receiving the first version information, the interactive service component can send the first version information to the client, and then the client performs the comparison task. Specifically, after receiving the first version information, the client compares the second version information when generating the upgrade request with the first version information. If the two are the same, it indicates that the upgrade is successful, and if the two are different, it indicates that the upgrade fails.

[0089] For example, if Figure 5 A schematic diagram of the status reporting process provided by the embodiment of the present application. Figure 5 As you can see, the specific steps include the following:

[0090] First, check whether the first hash value after the upgrade is consistent with the stored hash value. If they are inconsistent, it means that the upgrade has not been completed, and the status report of the in-place upgrade will not be performed.

[0091] If the first hash value after the upgrade is consistent with the stored hash value, it indicates that the upgrade has been completed and the status report of the in-place upgrade can be performed normally. At this time, the elastic container instance agent sends the first version information to the interactive service component, and then the interactive service agent sends the first version information to the client. At this time, the client will see that the condition version information in the container status is consistent with the version information filled in when the update was initiated, indicating that the update is complete.

[0092] In the above manner, the client and the interactive service component determine whether the upgrade is successful based on the version information, so that the client and the interactive service component can understand the upgrade status in time.

[0093] In one or more embodiments of the present application, before comparing the received container image to be upgraded, the following steps are further included:

[0094] If the elastic container instance includes multiple containers, the corresponding upgraded container is determined from the multiple containers according to the container identifier of the container to be upgraded; wherein the container identifier includes: at least one of a container name, a container ID and a container size;

[0095] The version information of other containers among the multiple containers except the upgraded container is updated.

[0096] In actual applications, some elastic container instances contain multiple containers. Although this upgrade is not for all containers in the elastic container instance, in order to keep the version synchronized, it is necessary to update the version information of all containers contained therein in units of elastic container instances or Pod nodes. The container identifier mentioned here can be understood as an identifier that represents a unique identification function in the elastic container instance. Therefore, the container identifier can be a container name or a container ID. Of course, in order to ensure a more accurate check (for example, to avoid duplicate container names that make it impossible to find the upgraded container), you can also use a variety of container identifiers (for example, container name, container ID and container size) to accurately find the upgraded container from multiple containers. It should be noted that the container identifier mentioned here can also include container application scenarios, container timestamps, etc.

[0097] In the above manner, the upgraded container is accurately found from multiple containers according to the container name. While the in-place upgrade task of the upgraded container is executed, the version information of other containers that are not upgraded this time in the multiple containers is also updated together, so that the version information of the multiple containers is kept synchronized.

[0098] Based on the same idea, the embodiment of the present application also provides another container upgrade method, which is applied to the client. Figure 3 A flowchart of another container upgrade method provided in an embodiment of the present application. Figure 3You can see that the specific steps include the following:

[0099] 301: Send a container image to be upgraded and a container upgrade request including an upgrade type identifier of an in-place upgrade to an interactive service component, so that the interactive service component sends the container image to be upgraded to an elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded.

[0100] 302: Receive first version information fed back by the elastic container instance agent.

[0101] 303: If the first version information is the same as the second version information corresponding to the container image to be upgraded, the upgrade is completed.

[0102] Based on the same idea, the present application embodiment also provides a container upgrade system. Figure 6 A schematic diagram of a container upgrade system provided in an embodiment of the present application. Figure 6 As can be seen, the system is a distributed system, which includes

[0103] The elastic container instance agent 61 is used to respond to the container upgrade request including the upgrade type identifier of the in-place upgrade, and compare the received container image to be upgraded; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component;

[0104] If the comparison result is that the to-be-upgraded container image is different from the upgraded container, the upgraded container is upgraded to a target container corresponding to the to-be-upgraded container image.

[0105] Also used to calculate the first hash value of the container image to be upgraded;

[0106] Compare the first hash value with the second hash value of the upgraded container;

[0107] If the first hash value is different from the second hash value, it indicates that the comparison result is that the container image to be upgraded is different from the upgraded container;

[0108] If the first hash value is the same as the second hash value, the in-place upgrade is terminated.

[0109] Also used to stop the operation of the upgraded container;

[0110] Updating the upgraded container to the target container;

[0111] Update the first hash value and first version information corresponding to the target container.

[0112] It is also used to feed back the first version information to the interactive access component or the client, so that the interactive component or the client can determine whether the upgrade is successful based on the first version information.

[0113] further configured to determine the corresponding upgraded container from the multiple containers according to the container name of the container to be upgraded if the elastic container instance includes multiple containers;

[0114] The version information of other containers among the multiple containers except the upgraded container is updated.

[0115] The interactive service component 62 is used to obtain the container image to be upgraded and the container upgrade request;

[0116] If the upgrade type identifier included in the container upgrade request is in-place upgrade, verifying the upgrade content of the container image to be upgraded;

[0117] If the upgrade content verification passes, the container image to be upgraded is sent to the elastic container instance agent so that the elastic container instance agent performs the in-place upgrade task.

[0118] Also used to obtain the upgrade field contained in the container image to be upgraded;

[0119] If the upgrade field is a field allowed by the elastic container instance agent, the verification passes;

[0120] If the upgrade field is not a field allowed by the elastic container instance agent, the in-place upgrade is terminated.

[0121] It is also used to obtain the upgrade field contained in the container image to be upgraded

[0122] If the upgrade field is not a field allowed by the elastic container instance agent, a rolling upgrade or a replacement upgrade is performed.

[0123] It is also used to receive the first version information corresponding to the container image to be upgraded after the elastic container instance agent completes the in-place upgrade task;

[0124] If the second version information included in the container upgrade request is the same as the first version information, the upgrade is successful; or,

[0125] Sending the first version information to the client, so that the client determines whether the first version information is the same as the second version information;

[0126] If they are the same, the upgrade is successful.

[0127] The client 63 is used to send the container image to be upgraded and the container upgrade request including the upgrade type identifier of the in-place upgrade to the interactive service component; so that the interactive service component sends the container image to be upgraded to the elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded;

[0128] Receive first version information fed back by the elastic container instance agent;

[0129] If the first version information is the same as the second version information corresponding to the container image to be upgraded, the upgrade is completed.

[0130] like Figure 7 The following is a schematic diagram of multi-terminal interaction for illustrating an embodiment of the present application. Figure 7 As you can see, the specific upgrade process is as follows:

[0131] The client sends a container upgrade request and the container image to be upgraded to the interactive service component (APIserver). After receiving the container upgrade request and the container image to be upgraded, the interactive service component determines whether the upgrade type identifier is an in-place upgrade. If it is an in-place upgrade, the upgrade content in the container image to be upgraded is further verified. If the verification passes, the container image to be upgraded is sent to the elastic container instance agent.

[0132] After receiving the container image to be upgraded, the elastic container instance agent calculates the first hash value of the container image to be upgraded and compares the first hash value with the second hash value of the upgraded container image. If the comparison result is different, it means that an upgrade is required.

[0133] The elastic container instance agent pulls the container image to be upgraded and stops the old container image to be upgraded. Create a new target container. After the creation is completed, start the new target container. If the startup is successful, it means that the upgrade is successful. Then, send the upgraded first version information to the interactive service component, and the interactive service component sends the first version information to the client.

[0134] The client compares the second version information of the container image to be upgraded with the first version information to see if they are the same. If they are the same, it means the upgrade is successful.

[0135] Based on the same idea, the present embodiment also provides a container upgrade device. Figure 8a A schematic diagram of a container upgrade device provided in an embodiment of the present application. The device is applied to an interactive service component. Figure 8a As can be seen in the figure, the device comprises:

[0136] The acquisition module 801 is used to acquire the container image to be upgraded and the container upgrade request.

[0137] The verification module 802 is configured to verify the upgrade content of the container image to be upgraded if the upgrade type identifier included in the container upgrade request is in-place upgrade.

[0138] The sending module 803 is configured to send the container image to be upgraded to the elastic container instance agent if the upgrade content verification passes, so that the elastic container instance agent performs the in-place upgrade task.

[0139] A verification module 802 is used to obtain an upgrade field contained in the container image to be upgraded;

[0140] If the upgrade field is a field allowed by the elastic container instance agent, the verification passes;

[0141] If the upgrade field is not a field allowed by the elastic container instance agent, the in-place upgrade is terminated.

[0142] Verification module 802, used to obtain the upgrade field contained in the container image to be upgraded

[0143] If the upgrade field is not a field allowed by the elastic container instance agent, a rolling upgrade or a replacement upgrade is performed.

[0144] A verification module 802 is configured to receive first version information corresponding to the container image to be upgraded after the elastic container instance agent completes the in-place upgrade task;

[0145] If the second version information included in the container upgrade request is the same as the first version information, the upgrade is successful; or,

[0146] Sending the first version information to the client, so that the client determines whether the first version information is the same as the second version information;

[0147] If they are the same, the upgrade is successful.

[0148] Based on the same idea, another embodiment of the present invention also provides another container upgrading device. Figure 8b A schematic diagram of another container upgrade device provided in an embodiment of the present application. The device is applied to elastic container instance proxy. Figure 8b As can be seen in the figure, the device comprises:

[0149] A comparison module 811 is used to compare the received container image to be upgraded in response to the container upgrade request including the upgrade type identifier of the in-place upgrade; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component;

[0150] The upgrading module 812 is configured to upgrade the upgraded container to a target container corresponding to the container image to be upgraded if the comparison result shows that the container image to be upgraded is different from the upgraded container.

[0151] A comparison module 811 is used to calculate a first hash value of the container image to be upgraded;

[0152] Compare the first hash value with the second hash value of the upgraded container;

[0153] If the first hash value is different from the second hash value, it indicates that the comparison result is that the container image to be upgraded is different from the upgraded container;

[0154] If the first hash value is the same as the second hash value, the in-place upgrade is terminated.

[0155] An upgrade module 812 is used to stop the upgraded container from running;

[0156] Updating the upgraded container to the target container;

[0157] Update the first hash value and first version information corresponding to the target container.

[0158] The upgrading module 812 is used to feed back the first version information to the interactive access component or the client, so that the interactive component or the client can determine whether the upgrading is successful based on the first version information.

[0159] The upgrade module 812 is configured to determine the corresponding upgraded container from the multiple containers according to the container name of the container to be upgraded if the elastic container instance includes multiple containers; wherein the container identifier includes at least one of a container name, a container ID, and a container size;

[0160] The version information of other containers among the multiple containers except the upgraded container is updated.

[0161] Based on the same idea, another embodiment of the present invention also provides another container upgrading device. Figure 8c A schematic diagram of another container upgrade device provided in an embodiment of the present application. The device is applied to a client. Figure 8c As can be seen in the figure, the device comprises:

[0162] The sending module 821 is used to send the container image to be upgraded and the container upgrade request including the upgrade type identifier of the in-place upgrade to the interactive service component; so that the interactive service component sends the container image to be upgraded to the elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded;

[0163] A receiving module 822 is configured to receive the first version information fed back by the elastic container instance agent;

[0164] The comparison module 823 is configured to complete the upgrade if the first version information is the same as the second version information corresponding to the container image to be upgraded.

[0165] An embodiment of the present application also provides an electronic device. The electronic device is a master node electronic device in a computing unit. Fig. 9 The electronic device includes a memory 901, a processor 902 and a communication component 903;

[0166] The memory 901 is used to store programs;

[0167] The processor 902 is coupled to the memory and is configured to execute the program stored in the memory to:

[0168] Get the container image to be upgraded and the container upgrade request;

[0169] If the upgrade type identifier included in the container upgrade request is in-place upgrade, verifying the upgrade content of the container image to be upgraded;

[0170] If the upgrade content verification passes, the container image to be upgraded is sent to the elastic container instance agent so that the elastic container instance agent performs the in-place upgrade task.

[0171] Processor 902 is used to obtain an upgrade field included in the container image to be upgraded;

[0172] If the upgrade field is a field allowed by the elastic container instance agent, the verification passes;

[0173] If the upgrade field is not a field allowed by the elastic container instance agent, the in-place upgrade is terminated.

[0174] Processor 902, configured to obtain an upgrade field contained in the container image to be upgraded

[0175] If the upgrade field is not a field allowed by the elastic container instance agent, a rolling upgrade or a replacement upgrade is performed.

[0176] Processor 902 is configured to receive first version information corresponding to the container image to be upgraded after the elastic container instance agent completes the in-place upgrade task;

[0177] If the second version information included in the container upgrade request is the same as the first version information, the upgrade is successful; or,

[0178] Sending the first version information to the client, so that the client determines whether the first version information is the same as the second version information;

[0179] If they are the same, the upgrade is successful.

[0180] The processor 902 is further configured to compare the received container image to be upgraded in response to the container upgrade request including the upgrade type identifier of the in-place upgrade; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component;

[0181] If the comparison result is that the to-be-upgraded container image is different from the upgraded container, the upgraded container is upgraded to a target container corresponding to the to-be-upgraded container image.

[0182] The processor 902 is further configured to calculate a first hash value of the container image to be upgraded;

[0183] Compare the first hash value with the second hash value of the upgraded container;

[0184] If the first hash value is different from the second hash value, it indicates that the comparison result is that the container image to be upgraded is different from the upgraded container;

[0185] If the first hash value is the same as the second hash value, the in-place upgrade is terminated.

[0186] The processor 902 is further configured to stop the operation of the upgraded container;

[0187] Updating the upgraded container to the target container;

[0188] Update the first hash value and first version information corresponding to the target container.

[0189] The processor 902 is further configured to feed back the first version information to the interactive access component or the client, so that the interactive component or the client determines whether the upgrade is successful based on the first version information.

[0190] The processor 902 is further configured to determine the corresponding upgraded container from the multiple containers according to the container name of the container to be upgraded if the elastic container instance includes multiple containers; wherein the container identifier includes at least one of a container name, a container ID, and a container size;

[0191] The version information of other containers among the multiple containers except the upgraded container is updated.

[0192] The processor 902 is further configured to send the container image to be upgraded and the container upgrade request including the upgrade type identifier of the in-place upgrade to the interactive service component; so that the interactive service component sends the container image to be upgraded to the elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded;

[0193] Receive first version information fed back by the elastic container instance agent;

[0194] If the first version information is the same as the second version information corresponding to the container image to be upgraded, the upgrade is completed.

[0195] The memory 901 can be configured to store various other data to support operations on the electronic device. Examples of these data include instructions for any application or method for operating on the electronic device. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0196] Furthermore, the processor 902 in this embodiment may specifically be: a programmable switching processing chip, in which a data replication engine is configured to replicate received data.

[0197] When the processor 902 executes the program in the memory, in addition to the above functions, it can also realize other functions, which can be specifically referred to the description of the above embodiments. Fig. 9 As shown, the electronic device also includes: a power supply component 904 and other components.

[0198] The present application also provides a non-transitory machine-readable storage medium, wherein the non-transitory machine-readable storage medium stores executable code, and when the executable code is executed by a processor of an electronic device, the processor executes Figure 1 The method described in the corresponding embodiment.

[0199] Based on the above embodiment, when it is necessary to upgrade certain fields in the container, there is no need to rebuild the Pod node, and an in-place upgrade method can be used. Specifically, the client sends the generated container image to be upgraded and the container upgrade request to the interactive service component. When the interactive service component determines that the upgrade content in the container image to be upgraded meets the content allowed by the elastic container instance agent, the in-place upgrade task can be executed. Then, the container image to be upgraded is sent to the elastic instance container agent so that the elastic container instance agent performs the in-place upgrade task. Through the above scheme, the elastic container instance agent manages the upgrade content, which can meet the upgrade requirements of various contents. In addition, the use of the elastic container instance agent to perform the in-place upgrade task can effectively improve the upgrade efficiency. At the same time, during the upgrade process, by comparing the hash value, it can be known whether an upgrade is required and whether the upgrade is completed, so that the upgrade progress can be grasped in real time.

[0200] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portals for users to choose to authorize or refuse. The device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without creative work.

[0201] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0202] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A container upgrade method, characterized in that: Applied to an interactive service component, the method comprises: Get the container image to be upgraded and the container upgrade request; If the upgrade type identifier included in the container upgrade request is in-place upgrade, verifying the upgrade content of the container image to be upgraded; If the upgrade content verification passes, the container image to be upgraded is sent to the elastic container instance agent so that the elastic container instance agent performs the in-place upgrade task.

2. The method according to claim 1, characterized in that Verifying the upgrade content of the container image to be upgraded includes: Obtaining the upgrade field contained in the container image to be upgraded; If the upgrade field is a field allowed by the elastic container instance agent, the verification passes; If the upgrade field is not a field allowed by the elastic container instance agent, the in-place upgrade is terminated.

3. The method according to claim 2, characterized in that Verifying the upgrade content of the container image to be upgraded includes: Get the upgrade fields contained in the container image to be upgraded If the upgrade field is not a field allowed by the elastic container instance agent, a rolling upgrade or a replacement upgrade is performed.

4. The method according to claim 1, characterized in that: Also includes: When the elastic container instance agent completes the in-place upgrade task, receiving first version information corresponding to the container image to be upgraded; If the second version information included in the container upgrade request is the same as the first version information, the upgrade is successful; or, Sending the first version information to the client, so that the client determines whether the first version information is the same as the second version information; If they are the same, the upgrade is successful.

5. An in-situ upgrade method, characterized in that: Applied to an elastic container instance agent, the method includes: In response to a container upgrade request including an upgrade type identifier of an in-place upgrade, comparing the received container image to be upgraded; wherein the upgrade content of the container image to be upgraded is verified by the interactive service component; If the comparison result is that the to-be-upgraded container image is different from the upgraded container, the upgraded container is upgraded to a target container corresponding to the to-be-upgraded container image.

6. The method according to claim 5, characterized in that The comparing the received container image to be upgraded includes: Calculate a first hash value of the container image to be upgraded; Compare the first hash value with the second hash value of the upgraded container; If the first hash value is different from the second hash value, it indicates that the comparison result is that the container image to be upgraded is different from the upgraded container; If the first hash value is the same as the second hash value, the in-place upgrade is terminated.

7. The method according to claim 5, characterized in that The step of upgrading the upgraded container to a target container corresponding to the container image to be upgraded includes: Stop the upgraded container from running; Updating the upgraded container to the target container; Update the first hash value and first version information corresponding to the target container.

8. The method according to claim 7, characterized in that After the upgraded container is upgraded to a target container corresponding to the container image to be upgraded, the method further includes: The first version information is fed back to the interactive access component or the client, so that the interactive component or the client determines whether the upgrade is successful based on the first version information.

9. The method according to claim 8, characterized in that Before comparing the received container images to be upgraded, it also includes: If the elastic container instance includes multiple containers, the corresponding upgraded container is determined from the multiple containers according to the container identifier of the container to be upgraded; wherein the container identifier includes: at least one of a container name, a container ID and a container size; The version information of other containers among the multiple containers except the upgraded container is updated.

10. A container upgrade method, characterized in that: Applied to a client, the method comprises: Sending the container image to be upgraded and the container upgrade request including the upgrade type identifier of the in-place upgrade to the interactive service component; so that the interactive service component sends the container image to be upgraded to the elastic container instance agent after completing the verification of the upgrade content in the container image to be upgraded; Receive first version information fed back by the elastic container instance agent; If the first version information is the same as the second version information corresponding to the container image to be upgraded, the upgrade is completed.

11. A container upgrade system, characterized in that: The system comprises: A client, configured to execute the method according to claim 10; An interactive service component, configured to execute the method according to any one of claims 1 to 4; An elastic container instance agent, configured to execute the method according to any one of claims 5 to 9.

12. An electronic device comprising a memory and a processor; wherein: The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the method of any one of claims 1 to 4, or the method of any one of claims 5 to 9, or the method of claim 10.

13. A non-transitory machine-readable storage medium having executable code stored thereon, wherein when the executable code is executed by a processor of an electronic device, the processor is caused to execute the method as described in any one of claims 1 to 4, or the method as described in any one of claims 5 to 9, or the method as described in claim 10.

Images