CN113590146A

CN113590146A - Server and container upgrading method

Info

Publication number: CN113590146A
Application number: CN202110623442.1A
Authority: CN
Inventors: 赵贝; 马忠飞
Original assignee: Juhaokan Technology Co Ltd
Current assignee: Juhaokan Technology Co Ltd
Priority date: 2021-06-04
Filing date: 2021-06-04
Publication date: 2021-11-02
Anticipated expiration: 2041-06-04
Also published as: CN113590146B

Abstract

The invention relates to a server and container upgrading method, relating to the technical field of computers, and comprising the following steps: after receiving an upgrade instruction for a target container, if the target container is processing a service and a port carried in a service request is a port of the target container, sending the service request to the target container according to the port of the target container recorded in a server and a container identifier corresponding to the port of the target container; and after determining that the upgrading content of the target container is the container template, creating a new container in the management node containing the target container according to the container template contained in the upgrading content of the target container. The invention can create a new container in the management node containing the container to be upgraded, so that the operations of redistributing the network, mounting the remote disk and the like are not needed, and the upgrading process is simplified.

Description

Server and container upgrading method

Technical Field

The invention relates to the technical field of computers, in particular to a server and a container upgrading method.

Background

In a cloud platform cluster environment, such as a Kubernetes-based container cloud cluster, there are a large number of micro-services, each of which may have multiple instances, running in a container fashion distributed across multiple computing server hosts of the cloud platform.

When the container is upgraded, if the service is deployed by using the Deployment agent, the Deployment agent triggers the new version replicase to create a new Pod and deletes the old version Pod, wherein the old version Pod is the Pod containing the container to be upgraded. In the deployment operation process, an original Pod object is deleted, a new Pod is dispatched to another Node and is allocated to a new IP, then a container for upgrading is created on the Node, meanwhile, a container which is not upgraded in the original Pod is created, and a directory of the new Pod is remotely mounted.

If the service is deployed by using the stateful set, the stateful set deletes the old Pod object first in the upgrading process, and creates a new Pod object by using the same name after the deletion is completed. Stateful set waits until the original pod is completely deleted from the Kubernets cluster, and then the new pod is submitted to be created. This new Pod will also be rescheduled, IP assigned, and the directory for the new Pod will be remotely mounted.

However, when the container template is upgraded, since the container can be directly established according to the container template, the pod is not modified, if the upgrade is still performed by using the above scheme, the network is reallocated, the remote disk is mounted, and the upgrade operation is complicated.

Disclosure of Invention

The invention provides a server and a container upgrading method, aiming at the situation that when the upgrading content is the container template upgrading, a new container can be created in a management node containing the container to be upgraded, so that the operations of redistributing a network, mounting a remote disk and the like are not needed, and the upgrading process is simplified.

In a first aspect, an embodiment of the present invention provides a server, including: a processor and a receiving unit;

the receiving unit is used for receiving an upgrading instruction aiming at a target container and receiving the service request;

the processor is used for judging whether the target container is processing the service or not after receiving an upgrading instruction aiming at the target container;

if the target container is processing a service and a port carried in the service request is the port of the target container, sending the service request to the target container according to the port of the target container recorded in the server and a container identifier corresponding to the port of the target container, so that the target container continues to process the service;

after the upgrade content of the target container is determined to be the upgrade of the container template, a new container is created in a management node containing the target container according to the container template contained in the upgrade content of the target container; the new container in the container template is the same as the service data disk storage directory of the target container, the port of the new container recorded in the container template is the same as the port of the target container, and the container identifications of the new container and the target container are different.

The server can determine that the container is upgraded, if the upgrade content is the upgrade of the container template, and the container template does not relate to the modification of the management node but is the modification of the container, so the invention creates the upgraded container in the management node where the container to be upgraded is located according to the container template contained in the upgrade content of the container to be upgraded, because the port of the new container indicated in the container template is the same as the port of the container to be upgraded, and simultaneously, the service data disk storage directory of the new container in the container template is the same as that of the target container, thereby enabling a user request to normally find the service port, upgrading in situ, the management node is not changed, the resource is not required to be pulled again to create the container which is not upgraded in the management node, the IP address is not required to be redistributed, and the hanging process is not required, the upgrading process is simplified, and meanwhile, the influence of upgrading of the container is avoided in service processing according to the port of the container and the container identifier recorded in the server.

In one possible implementation, the processor is further configured to:

detecting whether the annotation information of the upgrade content of the target container is the identifier of the container template;

if yes, determining the upgrading content of the target container as upgrading the container template.

The server can determine whether the upgrade content is the upgrade of the container template by detecting whether the annotation information is the identifier of the container template, so that the process of determining the upgrade content is facilitated.

In one possible implementation, the processor is specifically configured to:

generating a selection interface to display according to the identification corresponding to each upgrading content of the target container;

and placing the identifier of the container template selected by the user in the selection interface into the annotation information.

The server provides the opportunity for the user to select the upgrading content, and the user experience is improved in consideration of the self needs of the user.

In one possible implementation, the processor is further configured to:

suspending a deployment process, wherein the deployment process is used for deleting the management node containing the target container and executing the creation of a new management node.

According to the server, the server does not need to delete the management node containing the target container and create a new management node, and only can create a new container in the management node containing the target container, so that the upgrading process is simplified.

In one possible implementation, the processor is specifically configured to:

after the creation of the new container is completed, updating the container identifier corresponding to the port of the target container recorded in the server to the container identifier of the new container, so as to send the service request carrying the port of the target container to the new container according to the container identifier of the new container, and controlling the target container to stop running after a preset time.

In the server, since the service request is distributed to the container, the port of the container and the container identifier corresponding to the port recorded in the server are required, after the new container is created, the server is updated, that is, the container identifier corresponding to the port is updated, so that the new container can receive the service request, and meanwhile, the target container may be processing the service request received in the process of creating the new container.

In a second aspect, an embodiment of the present invention provides a container upgrading method, including:

after receiving an upgrade instruction for a target container, judging whether the target container is processing a service;

if the target container is processing the service and a port carried in the received service request is the port of the target container, sending the service request to the target container according to the port of the target container recorded in the server and a container identifier corresponding to the port of the target container, so that the target container continues to process the service;

In one possible implementation, the upgrade content of the target container is determined as an upgrade to the container template by:

In one possible implementation, the annotation information is obtained by:

In a possible implementation manner, after determining that the upgrade content of the target container is to upgrade the container template, the method further includes:

In one possible implementation, the method further includes:

In a third aspect, the present application also provides a computer storage medium having stored thereon a computer program which, when executed by a processing unit, performs the steps of the container upgrade method of the second aspect.

In addition, for technical effects brought by any one implementation manner of the second aspect to the fourth aspect, reference may be made to technical effects brought by different implementation manners of the first aspect, and details are not described here.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention and are not to be construed as limiting the invention.

FIG. 1 is a schematic diagram of a node in Kubernetes according to an embodiment of the present invention;

FIG. 2 is a flow chart of a method for upgrading a container according to an embodiment of the present invention;

FIG. 3 is a diagram illustrating a change in pod1 during a container upgrade process, according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a user interaction interface provided by an embodiment of the invention;

FIG. 5 is a flow chart of a complete method for upgrading a container according to an embodiment of the present invention;

fig. 6 is a block diagram of a server according to an embodiment of the present invention.

Detailed Description

In order to make those skilled in the art better understand the technical solution of the present invention, the technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first", "second", and the like in the description of the present invention and the drawings described above are used for distinguishing similar objects and not necessarily for describing a particular order or sequence. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.

The application scenario described in the embodiment of the present invention is for more clearly illustrating the technical solution of the embodiment of the present invention, and does not form a limitation on the technical solution provided in the embodiment of the present invention, and it can be known by a person skilled in the art that with the occurrence of a new application scenario, the technical solution provided in the embodiment of the present invention is also applicable to similar technical problems.

Kubernets is a portable, scalable, open source platform for managing containerized workloads and services. In Kubernetes, a plurality of containers run on a plurality of servers of a cloud platform in a distributed manner, and may also be called hosts, and each server may be called a node, although the node may also be a virtual machine. Each node may be provided with a plurality of pods, each pod being a management node of the container, and each pod being capable of managing a plurality of containers, the plurality of containers using the same IP address, storage resource, and the like, so that the management node of a pod manages the cooperative work of the plurality of containers therebelow.

Each pod contained in the node is provided with an IP address, and if the local needs to access the service data of the pod in the pod, the directory of the pod in the pod needs to be mounted in the local directory, so that the service data generated by the pod in the pod can be accessed locally. If the remote needs to access the business data of the container in the pod, the directory of the container in the pod needs to be mounted in the remote disk, so that the business data generated by the container in the pod can be accessed in the remote disk.

The container template comprises container mirror images, environment variables, starting commands, required CPU memory amount and other information, and the container mirror images are used for providing a file system of an isolated execution environment for the container. Therefore, the containers in the pod are created directly from the container template.

To give an example, as shown in fig. 1, pod1 and pod2 are provided in node1, pod1 manages container 1 and container 2, that is, container 1 and container 2 use the same IP address and storage resource, etc., pod2 manages container 3, container 4 and container 5, and container 3, container 4 and container 5 use the same IP address and storage resource, etc.

When a container 1 or a container 2 in the Pod1, and a container 3, a container 4, or a container 5 in the Pod2 are upgraded, the upgrade content of the upgrade is stored in the apiserver, then a deployment process is started, and after the deployment process is started, a new version replicase is triggered to create a Pod, and an old version Pod is deleted.

The apiserver provides HTTP Rest interfaces such as the addition, deletion, modification and the like of various resource objects (pod and the like) of Kubernetes, and is a data bus and a data center of the whole system.

The replicase maintains the operation of a group of Pod copies, and has the main function of ensuring that a certain number of pods can normally operate in the cluster, continuously monitoring the operating states of the pods, and re-operating new Pod copies when the pods have faults and the restart number is reduced.

The deployment process creates the Pod, and the deployment process is responsible for creating, updating, and maintaining all the Pods it manages. The RS is responsible for controlling the number of copies, and the deployment process creates a specific Pod.

For the above upgrade process, the pod needs to be rebuilt and established, and in summary, it can be seen that the newly created pod needs to allocate a new IP and mount again, and if the hosts of the two pods are not the same, the newly created pod needs to schedule the container mirror in the apiserver again, and so on.

Because the new upgraded content is the container template, the container template can recreate the new container without relying on the file of the previous container. In order to simplify the steps of upgrading the container template, an embodiment of the present invention provides a container upgrading method, which is shown in fig. 2 and includes:

s200: after receiving an upgrading instruction aiming at a target container, judging whether the target container is processing a service; if yes, executing S201, otherwise executing S202;

s201: if the port carried in the received service request is the port of the target container, sending the service request to the target container according to the port of the target container recorded in the server and the container identifier corresponding to the port of the target container, so that the target container continues to process the service;

the container identifier corresponding to the port is a unique identifier of the container, for example, the port is generally four numbers, 8080, then the container identifier corresponding to the port is 8080-IOP, where IOP is a unique identifier generated before the container can process the service request.

Generally, if a container needs to process services, the function of endpoints of Kubernetes is needed, a kube-proxy process on a node joins endpoints of the container, the endpoints are accessible service endpoints, and an IP address of each pod, a port of the container in the pod and a container identifier corresponding to the port are recorded.

Therefore, when a service request is received, the container identifier corresponding to the port carried in the service request can be found through endpoints, and then the container to be forwarded by the service request can be found through the port and the container identifier corresponding to the port. When the carried port is the port of the target container, the service request may find the target container to process the service request according to the port of the target container and the container identifier corresponding to the port recorded in the server.

S202: after the upgrading content of the target container is determined to be the container template, a new container is created in a management node containing the target container according to the container template contained in the upgrading content of the target container;

the new container in the container template is the same as the service data disk storage directory of the target container, the port of the new container recorded in the container template is the same as the port of the target container, and the container identifications of the new container and the target container are different.

Similarly, the container template contained in the upgrade content is stored in the apiserver, and after an upgrade instruction is received, the container template contained in the upgrade content is called from the apiserver, and a new container is created in the management node containing the target container.

The target container is a container needing to be upgraded, and the new container is the container after the target container is upgraded. Because the invention adopts the mode that the new container is created in the management node containing the target container, the management node of the created new container is still the original management node, and because the management node is not changed, the IP address which can be used by the created new container is not changed, and the new IP address does not need to be redistributed to the new container, thereby saving the time consumption of network distribution.

In the container template provided by the invention, the service data disk storage directories of the new container and the target container are the same, so that the server can access the service data stored in the disk by the new container and the target container.

Furthermore, for the mount management node in the remote device, it is desirable that the server local end can access the service data generated in the container, so when the service data disk storage directory in the new container and the target container are the same, the server local end can access the service data generated in the container, and at the same time, the directory does not need to be modified, so that the mount in the remote device does not need to be modified.

Meanwhile, the port of the new container recorded in the container template is the same as the port of the target container, and the port is the identifier of the service, that is, the port of the container capable of processing the service is carried in the service request sent by the user side to the server, and when the port is not changed, the service is not changed, so that the user side can send the service request at will without changing whether the container is upgraded or not. The embodiment of the invention limits that the container identifiers of the new container and the target container are different, and the container identifier is required to be used when the server searches for the container to process the service request, so that the container identifier corresponding to the port recorded by the server is still the container identifier of the target container in the process of creating the new container, the target container can be found through the container identifier to process the service, and the service request cannot be mistakenly transmitted to the new container.

Further, in order to enable the service to be processed normally during the container upgrade, after the new container is created, a health detection function of Kubernetes is adopted to detect whether the new container is healthy, if the new container passes the health detection of Kubernetes, a container identifier of the new container is generated, meanwhile, a container identifier corresponding to a port of a target container recorded in the server is updated to the container identifier of the new container, so that a service request carrying the port of the target container is sent to the new container according to the container identifier of the new container, and the target container is controlled to stop operating after a preset time length. Thereby realizing the uninterrupted service processing process.

For an example, when the port is 8080, container identifiers corresponding to 8080 and the target container are recorded in endpoints, and IOP is updated to be 8080 corresponding to IOW when the container identifier of the new container is generated as IOW after the new container is created.

In detail, the service request is distributed through the port and the identifier corresponding to the port, so that after the new container is created, meaning that the new container can process the service, the container identifier corresponding to the port of the target container recorded in the server is updated to the container identifier of the new container, so that if there is a new service request, the port in the new service request can be found in the server, and the service request is sent to the new container, which processes the service request.

And simultaneously, the kubel in the pod finds the target container according to the mirror image Version of the target container, the resource Version and other Version information, the target container continues to process the service request sent in the new container creation process, and the target container is stopped to operate after the service request is processed, wherein the process can be realized by setting preset time length. The value of the preset duration can be preset according to the time required by different containers to process the service, for example, a container with a faster service processing time can be set to have a preset duration of 20 milliseconds, and a container with a slower service processing time can be set to have a preset duration of 1 second.

For the above method, taking the apparatus in fig. 1 as an example, as shown in fig. 3, the container 1 in the pod1 needs to be upgraded, and the upgrade content is to upgrade the container template, then a new container 1 'may be created in the pod1 according to the container template in the upgrade content of the container 1, after the creation is completed, the container 1 processing service is stopped, and the container 1 is deleted, at which time the container 2 and the container 1' are operated in the pod 1.

Wherein, the directory indicating the created new container 1 'in the container template is the same as the directory in the container 1, and the port of the new container 1' recorded in the container template is the same as the port of the container 1.

At this time, because the node is not changed in the upgrading process, the position and the resource of the pod are not changed, and other containers in the pod are also in the running state, the influence on the service is reduced, and meanwhile, other containers which are not upgraded in the pod need to be created again, so that the time for pulling the mirror images of other containers is saved, and the upgrading efficiency is improved.

The embodiment of the invention provides a mode for determining the upgrading content of a target container as upgrading a container template, which comprises the following steps: detecting whether the annotation information of the upgrade content of the target container is the identifier of the container template; if yes, determining the upgrading content of the target container as the container template is upgraded. If not, determining that the upgrading content of the target container is not the container template.

If the original upgrading scheme is to upgrade the container template, annotation information can be automatically added to the upgraded content, and the annotation information is the identifier of the container template, the container template can be upgraded by the method of the invention directly after an upgrading instruction is received.

Specifically, a selection interface is generated to display according to the identification corresponding to each upgrading content of the target container; the identity of the container template selected by the user at the selection interface is placed in the annotation information.

Specifically, the whole upgrading scheme may be divided into multiple upgrading contents, a selection interface may be generated according to an identifier corresponding to each upgrading content to display, then a user may select an identifier corresponding to the upgrading content on the selection interface, and if the identifier selected by the user is a container template identifier, the container template identifier is set in annotation information of the upgrading content of the target container, so that it may be determined that the upgrading content is upgrading the container template by checking whether the annotation information includes the container template identifier.

Wherein, modifying the container mirror image, adding or deleting the environment variable, etc., can make a new container template, and update the container template.

Illustratively, the upgrade instruction may be implemented by a user triggering an upgrade button, in an actual application process, the upgrade button and an identifier corresponding to a content selected by the user to be upgraded may be on the same page, a container image may be upgraded and a pod may be upgraded in the scheme of this upgrade, an identifier 1 of a container template and an identifier 2 of the pod template may be used, first, a display interface may be generated according to the corresponding identifiers, as shown in fig. 4, the identifier corresponding to each upgrade content is displayed, and a meaning indicated by each identifier is displayed, where the identifier 1 is a container template and the identifier 2 is a pod, the user may select an identifier in the selection interface, and after selecting the identifier corresponding to the container template, an area corresponding to the identifier may display gray, that is, the selected identifier 1: if the container template is gray, the user selects the container template, and clicks the upgrade button, the server will add the identifier corresponding to the container template to the annotation information of the upgrade content. If other identifiers are selected, a deployment process is adopted, the management node containing the target container is deleted, and the creation of a new management node is executed. Therefore, no annotation information is required.

The upgrading button and the mark corresponding to the upgrading content selected by the user can be on different pages, firstly, a selection interface can be displayed, and after the user finishes the selection, the interface containing the upgrading button is displayed, so that the user starts upgrading.

Or firstly displaying an interface containing an upgrade button, enabling a user to start upgrading, then displaying a selection interface, and enabling the user to select upgrade content, after the selection is completed, if the user selects an identifier corresponding to the container template, placing the identifier of the container template selected by the user on the selection interface into annotation information, and enabling the server to create a new container in a management node containing the target container according to the container template contained in the upgrade content of the target container after detecting the identifier of the container template; and stopping the target container processing service after the creation of the new container is completed.

In the prior art, the deployment process is executed during the container upgrading process, and is used for deleting the management node containing the target container and creating a new management node. In the invention, a new container is directly created in the management node, and the steps of deleting the management node containing the target container and creating the new management node are not involved, so that when the container template is determined to be upgraded, the deployment process can be suspended, the management node containing the target container is prevented from being deleted by the deployment process, and the creation of the new management node is executed.

In detail, after a deployment process, for example, deploymentent, a manager of the deploymentent monitors a change of the apiserver, if the annotation information of the apiserver includes an identifier of a container template, that is, in-place upgrade service, the deplaymentent is suspended from creating a new repliaset, the new repliaset deletes a pod management node including a target container, and after the manager related to the repliaset monitors the change of the apiserver, and the annotation information of the apiserver includes the identifier of the container template, the rebuild work of the pod management node is not triggered.

As shown in fig. 5, an embodiment of the present invention provides a complete method for upgrading a container, including:

s500: generating a selection interface for displaying according to the identification corresponding to each upgrading content of the target container;

in the upgrading process, a user or an upgrading platform is required to record an upgrading packet into the apiserver, what upgrading content is upgraded can be recorded in the upgrading packet, namely, each upgrading content of the target container is known, and a selection interface is generated and displayed according to the identification corresponding to each upgrading content.

The type of the upgrade content is, for example, upgrading a container template, upgrading a container image, and then generating a control interface.

S501: and if the identifier of the container template selected by the user in the selection interface is included in the annotation information, placing the identifier of the container template in the annotation information.

The annotation information is also stored in the apiserver as well as the updated contents of the target container. If the user does not select the identity of the container template in the selection interface, no identity will be placed in the annotation information.

S502: after an upgrade instruction of a user for a target container is received, detecting whether annotation information of upgrade content of the target container is an identifier of a container template; if so, executing S503; otherwise, executing S504:

after an upgrading instruction of a user for a target container is received, detecting whether annotation information of upgrading content of the target container in the apiserver is an identifier of a container template;

in detail, the kubel component of the node where the pod management node is located monitors the change of the apiserver, finds whether the annotation information in the upgrade service is the identifier of the container template, if the annotation information is the identifier of the container template, calls the new container template to create a new container, and smoothly stops the old version container after the new container is normally started, so that the service in the upgrade process is lossless.

S503: suspending a deployment process, wherein the deployment process is used for deleting the management node containing the target container and executing the creation of a new management node;

s504: executing a deployment process;

s505: creating a new container in a management node containing the target container according to a container template contained in the upgrade content of the target container;

s506: after the creation of the new container is completed, detecting whether the new container is normal; if yes, executing S507; otherwise, executing S508;

s507: and stopping distributing the new service request for the target container, and controlling the target container to stop running after a preset time length.

S508: and according to the container template contained in the upgrading content of the target container, a new container is created in the management node containing the target container.

Based on the above description, an embodiment of the present invention further provides a server, which is shown in fig. 6, and includes: a processor 600 and a receiving unit 601;

the receiving unit 601 is configured to receive an upgrade instruction for a target container and receive the service request;

the processor 600 is configured to determine whether a target container is processing a service after receiving an upgrade instruction for the target container;

The processor 600 is a control center of the server, connects each component by using various interfaces and lines, and executes various functions of the server and processes data by operating or executing software programs and/or modules stored in the memory and calling data stored in the memory, thereby implementing various services based on the server.

Optionally, the processor 600 may include one or more processing units. Optionally, the processor 600 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, an application program, and the like, and the modem processor mainly processes wireless communication. It will be appreciated that the modem processor described above may not be integrated into the processor.

The receiving unit 601 may be used to receive numeric or character information input by a user and generate key signal inputs related to user settings and function control of the server. In this case, the receiving unit is configured to receive an upgrade instruction for a target container.

Optionally, the receiving unit 601 may include a touch panel and other input terminals.

The touch panel, also called a touch screen, may collect touch operations of a user on or near the touch panel (for example, operations of the user on or near the touch panel using any suitable object or accessory such as a finger, a stylus pen, etc.), and drive the corresponding connection device according to a preset program. Optionally, the touch panel may include two parts, namely a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor, and can receive and execute commands sent by the processor. In addition, the touch panel may be implemented in various types, such as resistive, capacitive, infrared, and surface acoustic wave.

Optionally, the other input terminals may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

Optionally, the processor 600 is further configured to:

Optionally, the processor 600 is specifically configured to:

Optionally, the processor 600 is further configured to:

Optionally, the processor 600 is specifically configured to:

In an exemplary embodiment, there is also provided a storage medium comprising instructions, such as a memory comprising instructions, executable by a processor of a server to perform the container upgrade method described above. Alternatively, the storage medium may be a non-transitory computer readable storage medium, which may be, for example, a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

An embodiment of the present invention further provides a computer program product, which, when running on a server, enables the server to execute any one of the container upgrading methods described above in the embodiments of the present invention.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims

1. A server, comprising: a processor and a receiving unit;

2. The server of claim 1, wherein the processor is further configured to:

3. The server of claim 2, wherein the processor is specifically configured to:

4. The server of claim 1, wherein the processor is further configured to:

5. The server according to any one of claims 1 to 4, wherein the processor is specifically configured to:

6. A method for upgrading a container, comprising:

7. The container upgrading method according to claim 6, wherein the upgrading content of the target container is determined as upgrading the container template by:

8. The container upgrade method according to claim 7, wherein the annotation information is obtained by:

9. The container upgrading method according to claim 6, wherein after determining that the upgrading content of the target container is upgrading the container template, the method further comprises:

10. The container upgrading method according to any of claims 6-9, further comprising: