Pod deployment method and apparatus

Abstract

A pod deployment method and apparatus, relating to the technical field of distributed systems. A control node acquires shared information of different pods, wherein the shared information is used for indicating a condition under which sharing a virtual machine is supported. The control node deploys at least two pods that satisfy the condition indicated by the shared information onto the same virtual machine. The correspondence between pods and virtual machines is that: at least two pods correspond to one virtual machine. Therefore, the number of virtual machines that need to be started when starting pods is reduced, thereby shortening the time required for starting the pods, and improving the efficiency of starting the pods.

Description

A container unit deployment method and apparatus

[0001] This application claims priority to Chinese Patent Application No. 202510468432.3, filed on April 14, 2025, entitled "A Container Unit Deployment Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of distributed system technology, and in particular to a container unit deployment method and apparatus. Background Technology

[0003] Serverless architecture is a technology for creating container workloads directly in the cloud. Users no longer manage clusters and nodes, but instead directly call the application programming interface (API) to create their own container workloads. Typically, when creating container workloads using serverless container technology, the cloud platform can use a virtual machine to host a container unit (pod) of the container workload. Starting a pod requires first starting the virtual machine hosting the pod, and then starting the pod itself after the virtual machine has started. This process, where the pod can only start after the virtual machine has started, impacts the pod's startup efficiency. Summary of the Invention

[0004] This application provides a container unit deployment method and apparatus to solve the problem of low container unit startup efficiency.

[0005] Firstly, this application provides a container unit deployment method. The method includes: obtaining shared information of multiple container units. The shared information of the multiple container units describes the condition that the multiple container units support sharing at least one virtual machine. The number of the multiple container units is greater than the number of at least one virtual machine. Based on the shared information of the multiple container units, determining the correspondence between each container unit and the virtual machine to be deployed in each container unit. The correspondence includes: a first container unit and a second container unit in the multiple container units corresponding to target virtual machines. And based on the correspondence, deploying the multiple container units on the corresponding virtual machines.

[0006] In this application, shared information from different container units is obtained, where the shared information indicates the conditions supporting shared virtual machines. At least two container units that meet the conditions indicated by the shared information are deployed on the same virtual machine. The correspondence between container units and virtual machines is that at least two container units correspond to one virtual machine, compared to the conventional technique where one container unit is deployed on one virtual machine (i.e., one container unit corresponds to one virtual machine). The method provided in this application can reduce the number of virtual machines that need to be started when starting a container unit, thereby shortening the time required to start the container unit and improving the efficiency of container unit startup.

[0007] In one possible implementation, the shared information includes at least one of affinity mode and resource sharing type. Affinity mode includes at least one of the following: affinity with a specified container unit or anti-affinity. Affinity indicates support for shared virtual machines, and anti-affinity indicates that shared virtual machines are not supported. Resource sharing type includes at least one of the following: lending type, borrowing type, and lending and borrowing type. Lending type indicates that the container unit supports lending resources of virtual machines deployed in the container unit. Borrowing type indicates that the container unit supports borrowing resources of virtual machines deployed in other container units. Lending and borrowing type indicates that the container unit supports lending resources of virtual machines deployed in the container unit, and borrowing resources of virtual machines deployed in other container units. Thus, tenants can set the resource sharing type and the affinity between container units and specified container units according to the needs of actual applications, enabling multiple container units to share the same virtual machine, reducing the number of virtual machines required to start a container unit, shortening the startup time of the container unit, and improving the startup efficiency of the container unit. It also allows setting anti-affinity between container units and designated container units, enabling container units to be set on different virtual machines, thus ensuring information isolation between container units and designated container units, and consequently ensuring the information security of tenants.

[0008] In another possible implementation, the shared information of the first container unit includes a first affinity mode and a first resource sharing type. The shared information of the second container unit includes a second affinity mode and a second resource sharing type. The first affinity mode and the second affinity mode are used to indicate the affinity between the first container unit and the second container unit. One of the first resource sharing type and the second resource sharing type supports lending resources of the deployed virtual machine, and the other supports borrowing resources of virtual machines deployed by other container units. Thus, with affinity between different container units, and with some container units supporting lending resources of the deployed virtual machines and some container units supporting borrowing resources of the deployed virtual machines, different container units can be deployed on the same virtual machine. This provides a guarantee for deploying more container units on fewer virtual machines, reduces the number of virtual machines required to deploy container units, shortens the time required to start the virtual machine corresponding to the container unit, and improves the startup efficiency of the container units.

[0009] In another possible implementation, the shared information of the first container unit includes a first affinity profile. The container unit deployment method further includes obtaining the scheduling logic of the first container unit. Based on the shared information of multiple container units, the correspondence between each container unit and the virtual machine to be deployed in each container unit is determined, including: based on the shared information of multiple container units, and provided the first affinity profile is satisfied, using the scheduling logic to determine the target virtual machine to be deployed in the first container unit. Provided the affinity profile of the container unit is satisfied, the target virtual machine corresponding to the container unit is determined. In this way, more container units can be deployed on fewer virtual machines while ensuring information security between incompatible container units.

[0010] In another possible implementation, the shared information of the first container unit includes a first resource sharing type. The first resource sharing type supports lending resources of the virtual machines deployed by the first container unit. The container unit deployment method further includes: obtaining a specified resource size of the virtual machines to be deployed by the first container unit. Based on the shared information of multiple container units, the correspondence between each container unit and the virtual machines to be deployed by each container unit is determined, including: determining a target virtual machine for the first container unit based on the first resource sharing type and the specified resource size. The resource size of the target virtual machine is greater than the specified resource size. Determining the target virtual machine of the container unit based on its resource sharing type ensures that the virtual machines deployed by the container unit can lend resources, thereby ensuring the deployment of multiple container units satisfying affinity for the same virtual machine.

[0011] In another possible implementation, the shared information of the first container unit includes a first resource sharing type. The first resource sharing type supports lending resources of the virtual machines deployed in the first container unit. The container unit deployment method further includes obtaining the resource size occupied by the first container unit. Based on the shared information of multiple container units, the correspondence between each container unit and the virtual machine to be deployed in each container unit is determined, including determining the target virtual machine for the first container unit based on its resource sharing type and the resource size occupied. Thus, selecting the target virtual machine corresponding to the container unit based on its container resource quantity improves the matching degree between the container resource quantity and the resource quantity supported by the target virtual machine, avoiding resource waste.

[0012] In another possible implementation, the first and second container units satisfy at least one of the following conditions: the same tenant, the same tenant set, the same service, the same service set, or the same container unit set. Container units that meet the boundary conditions can be deployed on the same virtual machine, thus ensuring information sharing between different container units and consequently protecting the tenant's information security.

[0013] In another possible implementation, obtaining shared information from multiple container units includes receiving shared information about multiple container units sent by the tenant through a client. This allows obtaining shared information from multiple container units without computation, improving the efficiency of obtaining such information.

[0014] In another possible implementation, at least two of the multiple container units belong to the first tenant. The container deployment method further includes determining the billing information of the first tenant based on the target container unit among the at least two container units. The target container unit is defined as a container unit that does not borrow resources from virtual machines deployed in other container units. Thus, by obtaining billing information based on the actual virtual machines used by the tenant's deployed container units, the alignment between billing information and the actual virtual machine resources used is improved, enhancing the user experience.

[0015] Secondly, this application provides a container unit deployment apparatus. The apparatus includes modules for performing the methods described in the first aspect or any possible design of the first aspect.

[0016] Thirdly, this application provides a cloud platform. The cloud platform includes a control node and at least one worker node. The control node is configured to: acquire shared information of multiple container units. The shared information of the multiple container units describes the conditions under which the multiple container units support sharing at least one virtual machine. The number of the multiple container units is greater than the number of at least one virtual machine. The control node is further configured to: determine, based on the shared information of the multiple container units, the correspondence between each container unit and the virtual machine to be deployed in each container unit. The correspondence includes: a first container unit and a second container unit in the multiple container units corresponding to a target virtual machine. The control node is also configured to: send a first deployment command to a first worker node in the at least one worker node based on the correspondence. The first worker node is configured to: deploy the first container unit and the second container unit on the target virtual machine in response to the first deployment command.

[0017] Fourthly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the at least one memory, causing the computing device cluster to perform operational steps of the container cell deployment method of the first aspect or any possible design of the first aspect.

[0018] Fifthly, this application provides a computer-readable storage medium, comprising: computer software instructions; which, when executed in a computing device, cause the computing device to perform operational steps of the method as described in the first aspect or any possible implementation thereof.

[0019] Sixthly, this application provides a computer program product. When the computer program product is run on a computer cluster, it causes the computing device cluster to perform the operational steps of the method as described in the first aspect or any possible implementation of the first aspect.

[0020] The beneficial effects of aspects two through six above can be described with reference to the first aspect or any implementation thereof, and will not be repeated here. Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0021] Figure 1 is a schematic diagram of the architecture of a cloud platform provided in this application;

[0022] Figure 2 is a schematic diagram of the layered architecture of a cloud platform provided in this application;

[0023] Figure 3 is a schematic diagram of the structure of a system provided in this application;

[0024] Figure 4 is a flowchart illustrating a container unit deployment method provided in this application;

[0025] Figure 5 is an example diagram of a container unit deployment method provided in this application;

[0026] Figure 6 is a structural schematic diagram of a container unit deployment device provided in this application;

[0027] Figure 7 is a schematic diagram of the structure of a computing device provided in this application;

[0028] Figure 8 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0029] Figure 9 is a schematic diagram of a network connection structure between computing devices provided in this application. Detailed Implementation

[0030] To ensure clarity and brevity in the description of the following embodiments, a brief introduction will first be given of some concepts that may be involved in this application.

[0031] (1) Container.

[0032] Containers are a lightweight and portable virtualization technology. A container packages an application and its dependencies into a single, self-contained unit. A container contains the necessary elements for the successful execution of an application, such as code, environment variables, processes, runtime environment, and software dependencies.

[0033] (2) Container unit.

[0034] A pod is the smallest unit of scheduling in a container cluster management system (Kubernetes, K8s). A pod contains at least one container, and the containers within a pod share the pod's network, storage, and other resources.

[0035] Because dozens, hundreds, or thousands of temporary containers can run on hardware devices, there is a need for container unit deployment. Kubernetes is used to automatically manage and schedule applications defined by a single container.

[0036] In Kubernetes (K8s), a node is a machine that hosts a pod; a node can be a physical machine or a virtual machine. K8s is a distributed system, and its core architecture includes a master node and worker nodes (also called the control node). The control node and worker nodes work together to build and manage a cluster of containerized applications. The control node is used for control plane management, while the worker nodes are used to host containers and run applications.

[0037] (3) Virtual machine.

[0038] A virtual machine (VM) is a complete computer system that is simulated by software, has full hardware system functionality, and runs in a completely isolated environment.

[0039] The main difference between containers and virtual machines is their architecture. Virtual machines contain a complete operating system instance and run on virtual hardware. Containers, on the other hand, share the host operating system kernel and only contain applications and their dependencies.

[0040] (4) Cloud platform.

[0041] A cloud computing platform, also known as a cloud computing service, refers to a service that provides computing, networking, and storage capabilities based on hardware and software resources. In other words, the platform provider combines cloud (remote hardware resources) and computing (remote software resources) to form a platform that provides various services to users.

[0042] Cloud platforms offer services such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). SaaS involves service providers deploying application software on cloud platform servers, with users subscribing to these services via the internet. PaaS provides a development environment as a service, offering users a development environment, server platform, and hardware resources. Users develop applications within this cloud platform environment and share them with other users via the cloud platform and the internet. IaaS provides users with a cloud infrastructure comprised of multiple servers, integrating memory, input / output devices, storage, and computing resources into a virtual resource pool, providing storage resources and virtualized servers.

[0043] Based on the brief introduction of some concepts that may be involved in this application above, the prior art related to this application will be briefly introduced below.

[0044] Deployment information for serverless containers (or cloud containers) built using serverless container technology is invisible to users. To ensure that containers from different tenants can run securely on the same host machine, a virtual machine hosts one pod. In other words, for security reasons, serverless containers use one virtual machine to host one pod. When starting a pod, the virtual machine hosting the pod must be started first, and then the pod hosted by that virtual machine must be started after the virtual machine has started. This process, where the virtual machine starts before the pod can be started, impacts the pod startup efficiency.

[0045] Based on this, this application provides a pod deployment method. In this method, shared information of different pods is obtained, where the shared information indicates the conditions supporting a shared virtual machine. At least two pods that meet the conditions indicated by the shared information are deployed on the same virtual machine. The correspondence between pods and virtual machines is that at least two pods correspond to one virtual machine, compared to the conventional technique where one pod is deployed on one virtual machine (i.e., one pod corresponds to one virtual machine). The method provided by this application can reduce the number of virtual machines that need to be started when starting a pod, thereby shortening the time required to start a pod and improving the efficiency of pod startup.

[0046] This pod deployment method can be applied to the cloud platform shown in Figure 1. Figure 1 is a schematic diagram of the architecture of a cloud platform provided in this application. As shown in Figure 1, the cloud platform 100 includes a computing server cluster 110, a storage server cluster 120, a management server cluster 130, a network device cluster 140, and a user terminal 150. The computing server cluster 110, storage server cluster 120, and management server cluster 130 communicate with the user terminal 150 through the network device cluster 140.

[0047] The computing server cluster 110 serves as a computing resource within the cloud platform 100. The computing server cluster 110 includes one or more computing servers (computing server 111 and computing server 112 shown in Figure 1). The computing servers can be electronic devices with data processing capabilities, including but not limited to servers and desktop computers. The computing servers are used to generate and allocate computing resources based on virtualization technology and user needs. In terms of hardware, the computing servers are equipped with processors and memory (not shown in Figure 1), and the computing functions of the computing servers are implemented by the processor running programs in memory. The computing servers can also read / write data on various storage servers in the storage server cluster 120 according to user needs.

[0048] Storage server cluster 120 serves as a storage resource within cloud platform 100. Storage server cluster 120 includes one or more storage servers (storage server 121 and storage server 122 as shown in Figure 1). Storage servers can be electronic devices with data storage capabilities, including but not limited to: servers, desktop computers, or controllers and hard disk enclosures of storage arrays. Storage servers provide logical disk storage, unstructured data storage, and integrated backup services for cloud virtual machines within cloud platform 100. In terms of hardware, storage servers are equipped with network interface cards (NICs), processors, and memory. The processor in the storage server processes data from outside the storage server. The NIC controls the access process to the memory, such as by controlling address signals, data signals, and various command signals, enabling the storage server to provide the memory as a storage resource to users. Memory is used to store data and may include RAM and / or hard disks. RAM refers to internal memory that directly exchanges data with the processor; RAM can quickly read and write data at any time, serving as temporary data storage for the operating system or other running programs. Unlike RAM, hard disks are slower to read and write data and are typically used for persistent data storage.

[0049] The management server cluster 130 is used to manage all computing services, shared storage, and network of the entire cloud platform 100, and to provide users or administrators with an API to manage the entire node. The management server cluster 130 includes one or more management servers (management server 131 and management server 132 as shown in Figure 1). Similarly, management servers can be electronic devices with data processing capabilities, including but not limited to servers, desktop computers, etc.

[0050] Network device cluster 140 includes one or more network devices. These network devices include, but are not limited to, switches and routers. For example, network device cluster 140 includes router 141, switch 142, switch 143, switch 144, and switch 145. User terminal 150 is connected to router 141 via the Internet. Router 141 is connected to switch 143 via switch 142, and switch 143 is connected to each computing server in computing server cluster 110. Switch 144 is connected to each computing server in computing server cluster 110 and each storage server in storage server cluster 120. Switch 145 is connected to each computing server in computing server cluster 110, each storage server in storage server cluster 120, and each management server in management server cluster 130.

[0051] The number and type of network devices included in the network device cluster 140 can be adjusted according to the needs of the cloud platform 100. For example, switches 142, 143, 144, and 145 can be switches with different functions, such as switch 142 being the core switch, and switches 143, 144, and 145 being switches used to manage specific network segments (e.g., switch 143 can be an internal / external switching network segment switch, switch 144 can be a storage network segment switch, and switch 145 can be a management network segment switch).

[0052] User terminal 150 includes one or more user terminals (user terminal 151 and user terminal 152 shown in FIG1). The user terminal contains the interfaces and applications required for accessing cloud platform 100.

[0053] It is worth noting that Figure 1 is merely a schematic diagram and should not be construed as limiting this application. The cloud platform 100 may include more or fewer devices, and this application does not limit this. For example, the computing server cluster 110 of the cloud platform 100 may include more or fewer computing servers. Similarly, the storage server cluster 120 of the cloud platform 100 may include more or fewer storage servers. Furthermore, the management server cluster 130 of the cloud platform 100 may include more or fewer management servers. Moreover, the network device cluster 140 of the cloud platform 100 may include more or fewer network devices. Finally, the user terminal 150 of the cloud platform 100 may include more or fewer user terminals. And, depending on the needs of actual applications, the cloud platform may also include other devices; this application does not limit the specific content included in the cloud platform 100.

[0054] Based on the cloud platform 100 shown in Figure 1, the cloud platform 100 can implement service node functions based on IaaS, PSSS, and SaaS. The cloud platform 100 provides users with computing services, storage services, network services, and other services through these service nodes. Service nodes can be cloud nodes (such as control nodes, worker nodes, etc.) virtualized using the resources of the cloud platform 100 (such as computing resources and storage resources).

[0055] The layered structure of the cloud platform 100 will be explained next with reference to Figure 2.

[0056] Figure 2 is a schematic diagram of the layered architecture of a cloud platform provided in this application. As shown in Figure 2, the cloud platform 100 can be divided into the following three layers: Infrastructure as a Service platform 210, Platform as a Service platform 220, and Software as a Service application 230.

[0057] Infrastructure as a Service (IaaS) platform 210 is used to virtualize all infrastructure resources in cloud platform 100 and to provide virtual resources (such as computing resources, network resources, and storage resources) to users in a software-defined manner. Infrastructure resources include those provided by the computing server cluster 110, storage server cluster 120, management server cluster 130, and / or network device cluster 140 of cloud platform 100.

[0058] The Platform as a Service (PaaS) platform 220 provides the runtime environment and application support functions for the cloud platform 100, allowing users to apply for computing units within their quotas instead of virtual resources to run their services. These computing units can be containers, and the cloud platform 100 deploys and runs user code by scheduling containers. The number of containers in the PaaS platform 220 can be one or more; Figure 2 uses two containers as an example.

[0059] As one possible implementation, Cloud Platform 100 can inject one or more components into a container to deploy and run the code. Components can include database components, message queue components, orchestration components, logging components, virtualization components, business database components, configuration database components, and permission management components. The resources (computing or storage resources) used by multiple components within the same container can belong to the same hardware device (such as a compute server, storage server, or management server) or different hardware devices within Cloud Platform 100.

[0060] Software as a Service (SaaS) application 230 is used to provide services to users by composing user-deployed applications as API responses, based on Infrastructure as a Service (IaaS) platform 210 and Platform as a Service (PAS) platform 220. The application and container of SaaS application 230 can communicate via a web server.

[0061] The layered structure of the cloud platform 100 has been described above using the layered structure shown in Figure 2 as an example. In some possible cases, the layered structure of the cloud platform 100 may also include other modules not shown in Figure 2, which are not limited in this application.

[0062] The pod deployment method provided in this application can be executed by a system consisting of service nodes (such as control nodes and worker nodes) provided by the cloud platform 100.

[0063] Figure 3 is a schematic diagram of the structure of a system provided in this application. As shown in Figure 3, system 300 includes: a control node 310 and at least one working node (working node 320, working node 330, and working node 340 shown in Figure 3). The control node 310 and each of the at least one working node are communicatively connected. The above-mentioned communication connections include wired communication connections and wireless communication connections. Wired communication connections include, but are not limited to, connections using optical fibers, electrical cables, twisted pairs, etc. Wireless communication connections include, but are not limited to, connections using local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), wireless network communication technologies (WIFI), and Bluetooth, etc.

[0064] Control node 310 is used to obtain shared information from multiple pods, and based on this information, determines the correspondence between each pod and the virtual machine to be deployed on each pod, and deploys the multiple pods on the corresponding virtual machines based on this correspondence. Specifically, control node 310 sends deployment commands to the worker nodes where the virtual machines corresponding to the multiple pods reside, based on the correspondence, to deploy the multiple pods on the corresponding virtual machines. Control node 310 can be a management server in the management server cluster 130 shown in Figure 1, and worker nodes 320 to 340 can be computing servers in the computing server cluster 110 shown in Figure 1. Control node 310 and worker nodes 320 to 340 can also be service nodes with management or computing functions as shown in Figure 2.

[0065] The worker nodes collaborate with the control node 310 to deploy multiple pods on corresponding virtual machines. Specifically, the worker nodes receive deployment commands from the control node 310 and, in response to these commands, deploy the pods on the corresponding virtual machines.

[0066] The above description uses system 300, including control node 310 and worker nodes 320 to 340, as an example to illustrate the architecture of the system provided in this application. In some possible cases, system 300 may also include more or fewer nodes, such as system 300 may also include worker node 350, etc. This application does not limit the number and type of nodes included in system 300.

[0067] The following example, using the system shown in Figure 3, illustrates the pod deployment method provided in this application. For details regarding the system, control node, and worker nodes, please refer to the explanations in Figures 1 to 3 above; these will not be repeated here.

[0068] Figure 4 is a flowchart of a pod deployment method provided in this application. As shown in Figure 4, the pod deployment method includes the following steps S410 to S430.

[0069] S410, the control node obtains shared information from multiple pods.

[0070] The shared information among multiple pods describes the condition that multiple pods can share at least one virtual machine. The number of multiple pods is greater than the number of at least one virtual machine.

[0071] The control node can obtain shared information from multiple pods in several ways. Examples of two possible methods are given below.

[0072] Example 1: The control node receives shared information about multiple pods sent by the tenant through the client.

[0073] In this example, the control node can receive shared information about multiple pods sent by a user through a user client. For instance, the control node receives shared information 1 sent by the user through the user client. Shared information 1 includes shared information for pods 11 to pod 13 and pods 21 to pod 25.

[0074] Example 2: The control node obtains shared information from multiple pods based on a shared information acquisition strategy.

[0075] In this example, the shared information acquisition strategy is used to indicate that, if the tenant identifier / service identifier of the pod to be created is a specified tenant identifier / service identifier, the pod to be created has specified shared information. For example, if the tenant identifier is a specified tenant identifier, the pod created by the tenant indicated by the tenant identifier has first shared information. Similarly, if the service identifier is a specified service identifier, the pod corresponding to the service indicated by the service identifier has second shared information, and so on. The shared information acquisition strategy can be preset or set according to user needs; this application does not limit this. The control node acquires the shared information acquisition strategy, as well as the tenant identifier, service identifier, etc., of the pod to be created. The control node determines the shared information of multiple pods based on the tenant identifier / service identifier and the shared information acquisition strategy.

[0076] In some possible scenarios, if a service creates a pod, that pod can be referred to as the pod corresponding to the service, or simply the pod corresponding to the service; and the service can be referred to as the service corresponding to the pod, or simply the service corresponding to the pod. Similarly, if a tenant creates a pod, that pod can be referred to as the pod corresponding to the tenant, or simply the pod corresponding to the tenant; and the tenant can be referred to as the tenant corresponding to the pod, or simply the tenant corresponding to the pod.

[0077] The above provides two possible examples of a control node obtaining shared information from multiple pods. Depending on the specific application, the control node may use other methods to obtain this information, which this application does not limit. For example, the control node may use a combination of Example 1 and Example 2 to obtain shared information from multiple pods, etc.

[0078] The above section explained how the control node obtains shared information; the following section explains how multiple pods are used.

[0079] Multiple pods can correspond to one service or multiple services. In the case where multiple pods correspond to multiple services, these services can be services of a single tenant or services of multiple tenants; this application does not impose such restrictions.

[0080] For example, there are multiple pods, including pod1 through pod8. pod1 through pod3 correspond to service 1, and pod4 through pod8 correspond to service 2. Both service 1 and service 2 are services of tenant 1.

[0081] For example, there are multiple pods, including pod1 through pod8. pod1 through pod3 correspond to service 1, and pod4 through pod8 correspond to service 2. Service 1 is the service for tenant 1, and service 2 is the service for tenant 2.

[0082] The previous section explained the concept of multiple pods. The following section explains the correspondence between multiple pods and shared information.

[0083] Depending on the needs of the actual application, one pod can correspond to one shared information, and pods of the same type can also correspond to one shared information. The following explains the correspondence between pods and shared information.

[0084] In scenario a, one pod corresponds to one shared information.

[0085] In this scenario, one pod corresponds to one shared information. For example, if multiple pods include pod1 to pod8, the shared information for these pods includes shared information 1 to shared information 8, as well as shared information i corresponding to pod i. Here, 8 ≥ i ≥ 1, and i is an integer.

[0086] In scenario b, pods of the same type share information.

[0087] In this scenario, if at least two pods are created by the same service, then these at least two pods can be considered to be of the same type. Similarly, if at least two pods are created by the same tenant, then these at least two pods can also be considered to be of the same type. For example, multiple pods include pods 1 through pod 8. Pods 1 through pod 3 are created by service 1, and pods 4 through pod 8 are created by service 2. In this case, pods 1 through pod 3 can be considered to be of the same type, and pods 4 through pod 8 can be considered to be of the same type. Pods 1 through pod 3 correspond to shared information 1, and pods 4 through pod 8 correspond to shared information 2.

[0088] The above text explained the correspondence between pods and shared information. The following text explains how shared information from multiple pods can be shared within the same virtual machine.

[0089] The shared information for multiple pods describes the following: multiple pods support the conditions for sharing at least one virtual machine. The number of multiple pods is greater than the number of at least one virtual machine. Furthermore, pods that meet the boundary conditions support sharing the same virtual machine within at least one virtual machine. Boundary conditions can include at least one of the following: same tenant, same tenant set, same service, same service set, or same pod set.

[0090] Depending on the boundary conditions, multiple pods can share virtual machines in different ways, which are described below.

[0091] Case 1, the boundary condition is the same tenant.

[0092] In this scenario, pods belonging to the same tenant can share the same virtual machine. For example, multiple pods include pod1 to pod8. Among them, pod1 to pod3 correspond to tenant 1, and pod4 to pod8 correspond to tenant 2. In this scenario, pod1 to pod3 can share the same virtual machine (e.g., virtual machine 1), and pod4 to pod8 can share the same virtual machine (e.g., virtual machine 2).

[0093] Case 2, the boundary condition is the same tenant set.

[0094] A single tenant set can include at least two tenants that cooperate, belong to the same organization, trust each other, or are designated by the tenant. For example, if tenant 1 and tenant 2 trust each other, tenant 1 and tenant 2 can be grouped into a single tenant set.

[0095] In this scenario, pods belonging to the same tenant set can share the same virtual machine. For example, multiple pods include pod1 to pod8. Among them, pod1 to pod3 correspond to tenant set 1, and pod4 to pod8 correspond to tenant set 2. In this scenario, pod1 to pod3 can share the same virtual machine (e.g., virtual machine 1), and pod4 to pod8 can share the same virtual machine (e.g., virtual machine 2).

[0096] Scenario 3: The boundary condition is the same service.

[0097] In this scenario, the same service across multiple pods can share the same virtual machine. For example, multiple pods might include pod1 through pod8. pod1 through pod3 correspond to service 1, and pod4 through pod8 correspond to service 2. In this case, pod1 through pod3 can share the same virtual machine (e.g., virtual machine 1), and pod4 through pod8 can share the same virtual machine (e.g., virtual machine 2).

[0098] Case 4: The boundary condition is the same service set.

[0099] The same service set may include at least two services that have information dependencies, information interactions, or are specified by a tenant. These two services can be services of the same tenant or services of different tenants; this application does not limit this. For example, if services 1 and 2 have information dependencies, services 1 and 2 can be grouped into one service set. Services 1 and 2 can both be services of tenant 1, or one can be a service of tenant 1 and the other a service of tenant 2.

[0100] In this scenario, multiple pods corresponding to the same service set can share the same virtual machine. For example, multiple pods include pod1 to pod8. Among them, pod1 to pod3 correspond to service set 1, and pod4 to pod8 correspond to service set 2. In this scenario, pod1 to pod3 can share the same virtual machine (e.g., virtual machine 1), and pod4 to pod8 can share the same virtual machine (e.g., virtual machine 2).

[0101] Case 5, the boundary condition is that they are in the same pod set.

[0102] The same set of pods may include at least two pods that have information dependencies, information exchanges, or are specified by a tenant. These at least two pods can be pods corresponding to one service or pods corresponding to multiple services. The aforementioned multiple services can be multiple services of the same tenant or multiple services of different tenants; this application does not limit this.

[0103] For example, multiple pods include pod1 through pod8. Pods1 through pod3 correspond to pod set 1 specified by the tenant, and pods4 through pod8 correspond to pod set 2 specified by the tenant. In this scenario, pods1 through pod3 can share the same virtual machine (e.g., virtual machine 1), and pods4 through pod8 can share the same virtual machine (e.g., virtual machine 2).

[0104] The above describes how multiple pods can share information within the same virtual machine. The following section explains the specific details of this shared information.

[0105] Depending on the needs of practical applications, shared information may include at least one of affinity form and resource sharing type. The affinity form and resource sharing type of shared information will be explained below.

[0106] ①Affinity form.

[0107] Affinity patterns include at least one of the following: affinity with a specified pod, and anti-affinity with a specified pod. Affinity indicates support for shared virtual machines. Anti-affinity indicates that shared virtual machines are not supported. In some possible cases, affinity patterns may also be referred to as affinity properties, etc., and this application is not limited to this.

[0108] For example, multiple pods include pod1 through pod8. pods1 through pod3 are anti-affinity to each other, while pods4 through pod8 are affinity to pods1 through pod3. That is, pods1 through pod3 do not support sharing the same virtual machine; they should be deployed on different virtual machines. pods4 through pod8 support sharing the same virtual machine with any of pods1 through pod3. For example, pod1 and pod8 share VM1, pod2, pod6, and pod7 share VM2, and pod3, pod4, and pod5 share VM3.

[0109] ② Resource sharing type.

[0110] Resource sharing types include at least one of the following: lending type, borrowing type, or a combination of lending and borrowing. A lending type indicates that a pod supports lending resources of virtual machines deployed by the pod. A borrowing type indicates that a pod supports borrowing resources of virtual machines deployed by other pods. A combination of lending and borrowing type indicates that a pod supports both lending resources of virtual machines deployed by the pod and borrowing resources of virtual machines deployed by other pods.

[0111] For example, multiple pods include pod1 through pod8. The resource sharing type for pods 1 through pod3 allows them to lend resources from the virtual machines they deploy on, while the resource sharing type for pods 4 through pod8 allows them to borrow resources from virtual machines deployed on other pods. pods 1 through pod3 are deployed on VM1 through VM3, respectively. In this scenario, pod1 can lend resources from VM1, and pod8 can borrow resources from the VM1 where pod1 is deployed; that is, pod1 and pod8 share VM1. pod2 can lend resources from VM2, and pods 6 and pod7 can borrow resources from the VM2 where pod2 is deployed; that is, pod2, pod6, and pod7 share VM2. pod3 can lend resources from VM3, and pods 4 and pod5 can borrow resources from the VM3 where pod5 is deployed; that is, pod3, pod4, and pod5 share VM3.

[0112] In some possible scenarios, resource identifiers can be used to distinguish different resource sharing types. For example, "EnableResourceLendingAndBorrowing" can represent "lending and borrowing type," "EnableResourceLending" can represent "lending type," and "EnableResourceBorrowing" can represent "borrowing type," and so on. The control node can set the corresponding resource identifier to true to enable the corresponding resource sharing mode. For example, setting "EnableResourceLendingAndBorrowing" to true indicates that the pod's resource type is lending and borrowing. Similarly, setting "EnableResourceLending" to true indicates that the pod's resource type is lending. And setting "EnableResourceBorrowing" to true indicates that the pod's resource type is borrowing.

[0113] The above section explained the shared information. In some possible scenarios, the control node can also obtain other information about multiple pods. This other information includes at least one of the following: pod identifiers, scheduling logic, container resource quantity, or virtual machine resource quantity, etc.

[0114] ①Pod identifier.

[0115] Pod identifiers are used to indicate pods, and include, but are not limited to, pod name, pod code, etc. In some possible scenarios, the control node can obtain the pod name corresponding to the container load and the number of pod replicas corresponding to the container load, and determine the pod identifier based on the pod name and the number of pod replicas. For example, based on shared information about multiple pods sent by a tenant through a client, the control node obtains the name 1 and replica count 3 of the pod to be created, and the name 2 and replica count 5 of the pod to be created. In this case, the control node can obtain the pod identifier based on the name and replica count of the pod to be created. For example, based on the name 1 and replica count 3 of the pod to be created, the control node obtains pod identifiers 1 to 3 as pod name 1-1 to pod name 1-3. And based on the name 2 and replica count 5 of the pod to be created, the control node obtains pod identifiers 4 to 8 as pod name 2-1 to pod name 2-5.

[0116] ② Scheduling logic.

[0117] The scheduling logic includes rules for determining which virtual machines a given pod will be deployed on. This scheduling logic includes, but is not limited to, bin-packing logic, spread-first distribution to schedulable virtual machines, etc. For further descriptions of these two scheduling logics, please refer to the general technical specifications; they will not be repeated here. The scheduling logic can be preset or user-defined as needed; this application does not limit this. Depending on the actual application requirements, scheduling logic can be set for or not set for a pod. Furthermore, if no scheduling logic is set for a pod, the control node can use preset scheduling logic to determine which virtual machine a given pod will be deployed on.

[0118] ③ Container resource quantity.

[0119] Container resource quantity is used to indicate the amount of resources required for a pod to run. For example, the container resource quantity of pod1 is 2 virtual processors (vCPU) and 4 gigabytes (GB) (hereinafter referred to as 2u4g), that is, the resource size required for pod1 to run is 2u4g. In some possible cases, container resource quantity may also be referred to as container specification, etc., which is not limited in this application.

[0120] ④ Virtual machine resource quantity.

[0121] Virtual machine resource quantity indicates the amount of resources that the virtual machine hosting a pod can provide, or the resource size of the virtual machine to which the pod will be deployed. For example, the virtual machine hosting pod1 has 4 virtual processors (vCPUs) and 8 gigabytes (GB) (hereinafter referred to as 4u8g), meaning the virtual machine hosting pod1 can provide 4u8g of resources. In some possible cases, virtual machine resource quantity can also be referred to as total specification.

[0122] Depending on the actual application requirements, the amount of virtual machine resources corresponding to a pod can be set, or it can be left unset. Additionally, if the pod's resource sharing type indicates that it supports lending resources from the virtual machines deployed on that pod, then the amount of virtual machine resources corresponding to that pod can be set. Conversely, if the pod's resource sharing type indicates that it supports borrowing resources from virtual machines deployed on other pods, but does not support lending resources from virtual machines deployed on other pods, then the amount of virtual machine resources corresponding to that pod can be left unset.

[0123] In some possible scenarios, when the virtual machine resource quantity corresponding to a pod is set, the control node can deploy the pod on a virtual machine with a resource quantity greater than or equal to the virtual machine resource quantity corresponding to the pod. For example, if the virtual machine resource quantity corresponding to pod1 is 4u8g, the control node can deploy pod1 on VM1 with a resource quantity of 4u8g.

[0124] In other possible scenarios, without setting the virtual machine resource size corresponding to the pod, the control node can deploy the pod on a virtual machine with a resource size greater than or equal to the container resource size corresponding to the pod. For example, if the container resource size corresponding to pod1 is 2u4g, the control node can deploy pod1 on VM2 with a resource size of 3u5g.

[0125] Having explained the shared information of multiple pods above, the following section, in conjunction with S420, explains the correspondence between determining pods and the virtual machines to be deployed on them.

[0126] In S420, the control node determines the correspondence between each pod and the virtual machine to be deployed in each pod based on shared information from multiple pods.

[0127] The correspondence indicates that the first and second pods in a set of multiple pods will be deployed on the same virtual machine.

[0128] In some possible scenarios, the first pod includes a first affinity profile and first resource-sharing information, and the second pod includes a second affinity profile and second resource-sharing information. The first and second affinity profiles indicate that the first and second pods are compatible, and one of the first and second resource-sharing information indicates support for lending resources from the deployed virtual machine, while the other indicates support for borrowing resources from virtual machines deployed in other pods. When the first affinity profile, second affinity profile, first resource-sharing information, and second resource-sharing information satisfy the above conditions, the control node can deploy the first and second pods on the same virtual machine.

[0129] Depending on the content of the shared information, the control node determines the correspondence between pods and the virtual machines to be deployed in different ways, which are described below.

[0130] In scenario A, the shared information includes affinity patterns.

[0131] In this scenario, the control node can obtain the shared information of each pod based on the shared information of multiple pods. Furthermore, given the affinity profile of each pod, the control node determines which virtual machine will be deployed on each pod.

[0132] Depending on whether the user specifies or does not specify the pod's scheduling logic, the process by which the control node determines which virtual machine will be deployed for the pod differs.

[0133] In the first scenario, when the user specifies the scheduling logic for a pod, the control node needs to obtain the pod's scheduling logic before determining the virtual machine to be deployed. If the pod's affinity condition is met, the control node uses the scheduling logic corresponding to that pod to determine the virtual machine to be deployed.

[0134] In the second scenario, if the user does not specify the scheduling logic for a pod, and the pod affinity condition is met, the control node directly uses the preset scheduling logic to determine the virtual machine to be deployed for that pod. Depending on the needs of the actual application, each pod can correspond to the same preset scheduling logic or different preset scheduling logics; this application does not limit this.

[0135] The following example, using the first pod among multiple pods, illustrates the process by which the control node determines the correspondence between a pod and the virtual machine to be deployed on it. The shared information of the first pod includes: its first affinity mode and the scheduling logic used to schedule the first pod. Specifically, the process includes: the control node obtaining the shared information of the first pod based on the shared information of multiple containers; and the control node obtaining the scheduling logic of the first pod. Given that the first affinity mode of the first pod is satisfied, the control node uses the scheduling logic to determine the target virtual machine to be deployed on the first pod.

[0136] For example, multiple pods include pod1 through pod8. pod1 through pod8 are scheduled using scheduling logic 1. pod1 has an affinity pattern of anti-affinity with pod2 and pod3, while pod4 through pod8 have an affinity pattern of affinity with pod1 through pod3. In this scenario, if VM1 does not deploy pod2 and pod3, the control node can use scheduling logic 1 to determine that pod1 is deployed on VM1. Similarly, the control node uses scheduling logic to determine that pod2 is deployed on VM2 and pod3 is deployed on VM3. Furthermore, if VM1 deploys any of pods from pod1 to pod3 (such as pod1), the control node can use scheduling logic 1 to determine that at least one pod from pod4 to pod8 (such as pod8) is deployed on VM1. Similarly, the control node can use scheduling logic 1 to determine that pod6 and pod7 are deployed on VM2, and pod4 and pod5 are deployed on VM3.

[0137] In scenario B, shared information includes resource sharing types.

[0138] In this scenario, depending on the other information obtained, the control node determines the correspondence between the pod and the virtual machine to be deployed in different ways, which are described below.

[0139] ① Other information includes container resource quantity.

[0140] In other words, a pod includes both resource sharing type and container resource quantity. In this scenario, the control node can determine the correspondence between the pod and the virtual machines to be deployed on it based on the pod's resource sharing type and container resource quantity. Depending on the pod's resource sharing type, the control node determines different virtual machines to be deployed on the pod; that is, the correspondence between the pod determined by the control node and the virtual machines to be deployed on the pod differs. These will be described separately below.

[0141] In the first possible scenario, when the pod's resource sharing type is "lending," the control node can determine the virtual machine to be deployed on the pod using the following process: Specifically, the control node obtains the pod's container resource size, i.e., the resource size occupied by the pod. Based on the pod's resource sharing type and container resource size, the control node determines the target virtual machine for the pod. The resource size of this target virtual machine is greater than or equal to the resource size indicated by the pod's container resource size. Similar to scenario A above, the control node can use specified scheduling logic or preset scheduling logic to determine the virtual machine corresponding to the pod; please refer to the above description for relevant details, which will not be repeated here.

[0142] The control node can determine the target virtual machine corresponding to a pod using the following process: The control node can determine at least one candidate virtual machine for the pod based on the pod's resource sharing type and container resource size. The resource size of each of these candidate virtual machines is greater than the resource size indicated by the pod's container resource size. The control node then selects a target virtual machine from these at least one virtual machine and designates it as the target virtual machine for the pod.

[0143] For example, multiple pods include pod1, where pod1's resource sharing type is "loan" and its container resource size is 2u4g. In this scenario, the control node determines VMs 1 through 3 for pod1 based on pod1's loan type and container resource size of 2u4g. VM1 has a resource size of 4u8g, VM2 has a resource size of 2u5g, and VM3 has a resource size of 3u8g. The control node can then use any one of VMs 1 through 3 as the target virtual machine (e.g., VM3) corresponding to pod1.

[0144] In the second possible scenario, where the pod's resource sharing type is borrowing, the control node can determine the virtual machine to be deployed to the pod using the following process. Specifically, the control node obtains the pod's container resource size, i.e., the resource size occupied by the pod. From the virtual machines already deployed to the pod, the control node determines the target virtual machine corresponding to the pod. The target virtual machine supports providing resources larger than or equal to the sum of the resource size indicated by the already deployed pod's container resource size and the minimum resource size of the pod's container resource size. Similar to scenario A above, the control node can use specified scheduling logic or preset scheduling logic to determine the virtual machine corresponding to the pod; please refer to the above description for relevant details, which will not be repeated here.

[0145] The control node can determine the target virtual machine corresponding to the pod using the following process: The control node can select at least one candidate virtual machine from the virtual machines where the pod is already deployed. The resource sharing type of the deployed pod indicates support for lending resources for the deployed virtual machine. The control node selects the target virtual machine corresponding to the pod from the at least one candidate virtual machine. And, if no virtual machine with the pod already deployed exists, the control node can determine the target virtual machine corresponding to the pod from virtual machines without deployed pods.

[0146] For example, multiple pods include pod1 through pod4. The resource sharing type of pods1 through pod3 indicates that pod1 through pod3 all support lending resources of the deployed virtual machines. The container resource size of pod1 through pod3 is 2u4g. pod1 is deployed on VM1, pod2 is deployed on VM2, and pod3 is deployed on VM3. The resource size of VM1 is 4u8g, the resource size of VM2 is 3u7g, and the resource size of VM3 is 4u5g. The resource sharing type of pod4 is borrowing, and the container resource size of pod4 is 1u2g. In this case, the control node determines VM1 and VM2 for pod4 based on the borrowing type of pod4 and the container resource size of pod4 (1u2g). The control node can also use either VM1 or VM2 as the target virtual machine (such as VM1) corresponding to pod4.

[0147] In the third possible scenario, where the resource sharing type of the pod is lending or borrowing, the control node can determine the virtual machine corresponding to the pod in several ways. Examples of two possible methods are given below.

[0148] Method 1: The control node prioritizes identifying the target virtual machine corresponding to the deployed pod from among the virtual machines containing the pod. If the resources available to the deployed pod from the virtual machines are less than the resource size indicated by the pod's container resource limit, the control node identifies the target virtual machine from among the virtual machines where the pod has not been deployed. This allows more pods to be deployed on fewer virtual machines, improving virtual machine resource utilization.

[0149] Specifically, the control node obtains the container resource quantity of the pod. The control node obtains the virtual machines of the deployed pod and selects at least one candidate virtual machine from them. The resource sharing type of the deployed pod on each candidate virtual machine indicates that the deployed pod supports lending resources from the deployed virtual machine, and that the resource size supported by each virtual machine for the pod is greater than the resource size indicated by the container resource quantity. The control node then determines the target virtual machine corresponding to the pod from the at least one candidate virtual machine. If no deployed pod exists, or the virtual machine of the deployed pod can provide resources smaller than the resource size indicated by the pod's container resource quantity, the control node can use the method described in Method 2 below to determine the target virtual machine corresponding to the pod.

[0150] For example, multiple pods include pod1 through pod8. The resource sharing type of pods1 through pod3 indicates that pods1 through pod3 support lending resources of the deployed virtual machines. The container resource size of pods1 through pod3 is 2u4g. pod1 is deployed on VM1, pod2 is deployed on VM2, and pod3 is deployed on VM3. The resource size of VM1 is 4u8g, the resource size of VM2 is 3u7g, and the resource size of VM3 is 4u5g. The resource sharing type of pod4 is both lend and borrow, and the container resource size of pod4 is 1u2g. In this scenario, the control node can select VM1 and VM2 as candidate virtual machines from VM1 through VM3, and the control node can choose either VM1 or VM2 as the target virtual machine (such as VM1) corresponding to pod4.

[0151] Method 2: The control node prioritizes identifying the target virtual machine (VM) corresponding to the pod from among the VMs where no pod has been deployed. This method reduces the time required to determine the VM, improving efficiency, because the control node doesn't need to calculate the available resources from the VMs containing the deployed pods based on their container resources and the VMs themselves. Specifically, the control node obtains the pod's container resources. It then selects at least one candidate VM from among the VMs where no pod has been deployed. Each candidate VM has a resource size greater than or equal to the resource size indicated by the pod's container resources. Finally, the control node selects any VM from these candidate VMs as the target VM for the pod.

[0152] For example, multiple pods include pod1 through pod8. pod1 is deployed on VM1, pod2 on VM2, and pod3 on VM3. pod4 has a resource sharing type of lending and borrowing, and its container resource size is 1u2g. In this scenario, the control node can select VM4 through VMn for pod4, where n is an integer greater than or equal to 5. The virtual machine resource size of any VM from VM4 to VMn is greater than or equal to the container resource size of pod4. The control node determines any VM from VM4 to VMn as the target virtual machine (e.g., VM4) corresponding to pod4.

[0153] ② Other information includes container resource quantity and virtual machine resource quantity.

[0154] In other words, a pod includes resource sharing type, container resource size, and virtual machine resource size. The difference between scenario B, ① above, is that before the control node determines the target virtual machine corresponding to the pod, the control node also obtains the specified resource size of the virtual machine to be deployed on the pod. Furthermore, the control node determines the target virtual machine corresponding to the pod based on the specified resource size of the virtual machine to be deployed on the pod. Other related descriptions can be found in scenario B, ① above, and will not be repeated here.

[0155] For example, if the resource sharing type of the first pod is "loan," the control node also obtains the specified resource size of the virtual machine to be deployed in the first pod. Based on the first pod's loan type, container resource size, and the specified resource size of the virtual machine to be deployed, the control node determines the target virtual machine corresponding to the pod. The resource size of the target virtual machine is greater than the specified resource size of the virtual machine to be deployed in the pod. For instance, multiple pods include pod1. pod1 has a resource sharing type of "loan," a container resource size of 2u4g, and a virtual machine resource size of 4u8g. In this case, the control node determines the target virtual machine VM1 corresponding to pod1 from VM1 to VM3 based on pod1's loan type, pod1's container resource size of 2u4g, and the virtual machine resource size of 4u8g.

[0156] The above section explained how the control node determines the target virtual machine corresponding to a pod. After the control node determines the target virtual machine corresponding to each of the multiple pods, it can establish a mapping between each pod and the target virtual machine to be deployed on each pod. Based on this mapping, the control node can execute S430 to deploy multiple pods to the corresponding virtual machines.

[0157] In S430, the control node deploys multiple pods to corresponding virtual machines based on the corresponding relationships.

[0158] Based on the correspondence, the control node sends deployment commands to the worker nodes of the virtual machines corresponding to the pods, and the worker nodes respond to the deployment commands by deploying the pods to the corresponding virtual machines.

[0159] The following example illustrates the process by which a control node deploys multiple pods to corresponding virtual machines, using the example of a control node deploying the first and second pods from multiple pods to the same virtual machine (e.g., the first virtual machine). Specifically, the control node can execute the following steps (1) and (2) to deploy the first and second pods to the first virtual machine.

[0160] (1) The control node sends the first deployment command to the first worker node where the first virtual machine is deployed, based on the corresponding relationship.

[0161] (2) The first worker node responds to the first deployment command and deploys the first pod and the second pod to the first virtual machine.

[0162] The control node can be deployed to the corresponding virtual machine in the same way as the first and second pods. This will not be elaborated on here.

[0163] The above text, in conjunction with Figure 4, describes the pod deployment method provided in this application. The following text, taking the function service to be deployed as an example, in conjunction with Figure 5, provides a specific illustrative explanation of the pod deployment method provided in this application.

[0164] When deploying a function service, you can deploy an agent as the function controller and a business pod (such as a func) as the function carrier. Different agents need to be deployed on different virtual machines, and the func needs to be deployed on the virtual machine where the agent is deployed. During the deployment process, you need to create an agent workload (or container workload 1) and a business workload (or container workload 2). Before creating container workload 1 and container workload 2, you can configure the pod information for container workload 1 and container workload 2. For example, you can set the pod name for container workload 1 to "agent", the number of agent replicas to 3, the agent's container size to 2u4g, the total size to 4u8g, the affinity to "anti-affinity" with the agent, and the resource sharing type to "lending" (i.e., "EnableResourceLending" is "true"). Set the pod name for container load 2 to func, the number of func replicas to 5, the container size of func to 1u2g, the scheduling logic to scheduling logic 1, the affinity mode to affinity with agent, and the resource sharing type to borrow type (i.e., "EnableResourceBorrowingg" is "true").

[0165] Tenants can use user clients to send shared information about multiple pods to the control node based on the above information. The control node can then use the process shown in Figure 5 to deploy the various pods included in Container Load 1 and Container Load 2, thereby completing the deployment of the function service.

[0166] Figure 5 is an example diagram of a pod deployment method provided in this application. As shown in Figure 5, the control node can perform the following (1) to (3) to complete the pod deployment.

[0167] (1) The control node obtains shared information from multiple pods sent by the user client.

[0168] The control node receives container creation requests sent by user clients and obtains shared information about multiple pods based on these requests. The container creation request includes: Information 1 for container load 1 and Information 2 for container load 2. Information 1 includes the name of the pod to be created for container load 1: agent; the number of replicas of the pod to be created (i.e., agent): 3; container size: 2u4g; total size: 4u8g; affinity type: anti-affinity with agent; resource sharing type: lending type (e.g., "EnableResourceLending" is true). Information 2 includes the name of the pod to be created for container load 2: func; the number of replicas of the pod to be created (i.e., func): 5; container size: 1u2g; affinity type: affinity with agent; scheduling logic: scheduling logic 1; resource sharing type: borrowing type (e.g., "EnableResourceBorrowing" is true).

[0169] (2) The control node determines the correspondence between each pod and the virtual machine to be deployed in each pod based on the shared information of multiple pods.

[0170] Based on the method described above, the control node determines that agent-1 and func-5 will be deployed to VM1, agents-2, func-3, and func-4 will be deployed to VM2, and agents-3, func-1, and func-2 will be deployed to VM3. The control node also establishes a mapping relationship based on the VM1 to VM3 deployments of agents-1 to agent-3 and func-1 to func-5. This mapping relationship indicates that agents-1 and func-5 correspond to VM1, agents-2, func-3, and func-4 correspond to VM2, and agents-3, func-1, and func-2 correspond to VM3.

[0171] (3) Based on the above correspondence, the control node deploys agent-1 to agent-3 and func-1 to func-5 to VM1 to VM3.

[0172] Specifically, the control node deploys agent-1 and func-5 to VM1, agent-2, func-3 and func-4 to VM2, and agent-3, func-1 and func-2 to VM3.

[0173] In this application, the control node obtains shared information from different container units, where the shared information indicates the conditions supporting shared virtual machines. The control node then deploys at least two container units that meet the conditions indicated by the shared information on the same virtual machine. The correspondence between container units and virtual machines is at least two container units to one virtual machine, compared to the conventional technique where one container unit is deployed on one virtual machine (i.e., one container unit to one virtual machine). The method provided in this application can reduce the number of virtual machines that need to be started when starting a container unit, thereby shortening the time required to start the container unit and improving the efficiency of container unit startup.

[0174] In some possible scenarios, after deploying multiple pods to their corresponding virtual machines, the control node can also obtain the billing information for those pods. The control node can obtain this billing information in several ways; examples of two possible methods are given below.

[0175] Example 1: The control node obtains the tenant's billing information based on the number of pods and the container resources of the pods.

[0176] In this scenario, the control node retrieves at least two pods from multiple pods that correspond to the same tenant (e.g., the first tenant). The control node then retrieves the container resource quantity of each of these two pods. Finally, the control node performs a summation operation on the container resource quantities of the two pods to obtain the total container resource quantity. Based on this sum, the control node retrieves the billing information for the first tenant.

[0177] For example, multiple pods include pod1 through pod8. pods1 through pod3 correspond to tenant 1, and each pod in pod1 through pod3 has a container resource size of 2u4g. pods4 through pod8 correspond to tenant 2, and each pod in pod4 through pod8 has a container resource size of 1u2g. In this scenario, the control node obtains the sum of the container resources of pods1 through pod3, which is 6u12g. Based on this 6u12g, the control node obtains the billing information 1 for tenant 1. The control node also obtains the sum of the container resources of pods4 through pod8, which is 5u10g. Based on this 5u10g, the control node obtains the billing information 2 for tenant 2.

[0178] Example 2: The control node obtains billing information for multiple pods based on the resource size of the virtual machines corresponding to those pods.

[0179] The control node obtains at least two pods from multiple pods that correspond to the same tenant (e.g., the first tenant). Based on the virtual machines deployed in the target pods from these at least two pods, the control node determines the billing information of the first tenant. The target pod is defined as: the pod among the at least two pods that does not borrow resources from virtual machines deployed in other pods.

[0180] For example, multiple pods include pod1 through pod8. pod1 through pod3 correspond to tenant 1, and the container resource size of each pod from pod1 to pod3 is 2u4g. pod1 is deployed on VM1, pod2 is deployed on VM2, and pod3 borrows resources from VM3 where pod4 is deployed. In this scenario, the control node obtains the sum of the resource size of VM1 (e.g., 4u8g) and the resource size of VM2 (e.g., 3u5g) (i.e., 7u13g) to determine the billing information for tenant 1.

[0181] It is understood that, in order to achieve the functions in the above embodiments, the computing device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0182] The container unit deployment method provided by this application has been described above with reference to Figures 4 and 5. The container unit deployment device provided by this application is described below with reference to Figure 6.

[0183] Figure 6 is a schematic diagram of a container unit deployment device provided in this application. As shown in Figure 6, the container unit deployment device 600 includes an acquisition module 610 and a processing module 620. The container unit deployment device can be used to implement the functions of the control node and the first working node in the above method embodiments.

[0184] When the container unit deployment device shown in Figure 6 is used to implement the function of the control node, the container unit deployment device can be the management server cluster 130 in Figure 1, or a management server of the management server cluster 130, or a service node in Figure 2, or a control node 310 in Figure 3. The acquisition module 610 can be used to implement the function implemented in S410 in the above method embodiment, and the processing module 620 can be used to implement the functions implemented in S420 and S430 in the above method embodiment. For more details on the acquisition module 610 and the processing module 620, please refer to the relevant description of the control node in the container unit deployment method above; it will not be repeated here.

[0185] When the container unit deployment device shown in Figure 6 is used to implement the function of the first worker node, the container unit deployment device can be the compute server cluster 130 in Figure 1, or a management server of the compute server cluster 130, or a service node in Figure 2, or a worker node 320 in Figure 3. It also includes an acquisition module 610 for receiving deployment commands from the control node, and a processing module 620 for deploying container units to the corresponding virtual machines in response to the deployment commands. For further description of the acquisition module 610 and the processing module 620, please refer to the relevant description of the first worker node in the container unit deployment method above; it will not be repeated here.

[0186] When the container unit deployment device 600 corresponds to the steps executed by the control node and the first working node in the container unit deployment method described in the embodiments of this application, the above and other operations and / or functions of each module in the container unit deployment device 600 are respectively to implement the method flow executed by the control node and the first working node in the foregoing figures.

[0187] It is worth noting that if the above-mentioned container unit deployment devices are implemented through software modules, for example, the software modules can be provided to users through a cloud service subscription model, and users can choose different subscription levels according to their needs; or, for example, the software modules can also provide enterprise-level customized services with professional domain customization, interface personalization and extended functions according to the needs of users or enterprises.

[0188] In addition, the container unit deployment device 600 provided in this application can also be provided to users as a value-added service, and this application does not limit this.

[0189] Both the acquisition module 610 and the processing module 620 described above can be implemented in software or in hardware. For example, the implementation of the processing module 620 will be described below. Similarly, the implementation of the acquisition module 610 can be referenced from the implementation of the processing module 620.

[0190] As an example of a software functional unit, processing module 620 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, processing module 620 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0191] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0192] As an example of a hardware functional unit, the processing module 620 may include at least one computing device, such as a server. Alternatively, the processing module 620 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0193] The processing module 620 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the processing module 620 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing module 620 includes multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0194] It should be noted that, in other embodiments, the acquisition module 610 can be used to execute any step in the container unit deployment method, and the processing module 620 can be used to execute any step in the container unit deployment method. The steps implemented by the acquisition module 610 and the processing module 620 can be specified as needed. By implementing different steps in the container unit deployment method through the acquisition module 610 and the processing module 620, all functions of the container unit deployment device 600 can be realized.

[0195] This application also provides a computing device 700. Figure 7 is a schematic diagram of the structure of a computing device provided in this application. As shown in Figure 7, the computing device 700 includes: a bus 716, a processor 711, a memory 712, and a communication interface 714. The processor 711, the memory 712, and the communication interface 714 communicate with each other via the bus 716. The computing device 700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 700.

[0196] Bus 716 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 7, but this does not imply that there is only one bus or one type of bus. Bus 716 can include pathways for transmitting information between various components of computing device 700 (such as memory 712, processor 711, and communication interface 714).

[0197] The processor 711 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0198] The memory 712 may include volatile memory, such as random access memory (RAM). The processor 711 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0199] The memory 712 stores executable program code, which the processor 711 executes to implement the functions of the aforementioned acquisition module 610 and processing module 620, thereby realizing the container unit deployment method. That is, the memory 712 stores instructions for executing the container unit deployment method.

[0200] The communication interface 714 uses acquisition modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 700 and other devices or communication networks.

[0201] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0202] Figure 8 is a schematic diagram of a computing device cluster provided in this application. As shown in Figure 8, the computing device cluster includes at least one computing device 700. The memory 712 of one or more computing devices 700 in the computing device cluster may store the same instructions for executing container cell deployment methods.

[0203] In some possible implementations, the memory 712 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the container cell deployment method. In other words, a combination of one or more computing devices 700 can jointly execute the instructions for executing the container cell deployment method.

[0204] It should be noted that the memory 712 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the container unit deployment device 600. That is, the instructions stored in the memory 712 of different computing devices 700 can implement the functions of one or more modules in the acquisition module 610 and processing module 620.

[0205] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 9 illustrates one possible implementation. Figure 9 is a schematic diagram of a network connection between computing devices provided in this application. As shown in Figure 9, two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 712 in computing device 700A stores instructions for executing the functions of the acquisition module 610. Simultaneously, the memory 712 in computing device 700B stores instructions for executing the functions of the processing module 620.

[0206] It should be understood that the functions of computing device 700A shown in Figure 9 can also be performed by multiple computing devices 700. Similarly, the functions of computing device 700B can also be performed by multiple computing devices 700.

[0207] This application embodiment also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to the connection method of the computing device cluster described in Figures 8 and 9. The difference is that the memory 712 of one or more computing devices 700 in this computing device cluster can store the same instructions for executing the container unit deployment method.

[0208] In some possible implementations, the memory 712 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the container cell deployment method. In other words, a combination of one or more computing devices 700 can jointly execute the instructions for executing the container cell deployment method.

[0209] It should be noted that the memory 712 in different computing devices 700 within the computing device cluster can store different instructions for executing some functions of the system. That is, the instructions stored in the memory 712 of different computing devices 700 can implement the functions of one or more nodes, including the control node and the first working node.

[0210] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform a container cell deployment method.

[0211] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, or magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive). The computer-readable storage medium includes instructions that instruct a computing device to perform a container unit deployment method.

Claims

1. A container unit deployment method, characterized in that, The method includes: Obtain shared information from multiple container units; the shared information from the multiple container units is used to describe: the multiple container units support the condition of sharing at least one virtual machine, and the number of the multiple container units is greater than the number of the at least one virtual machine; Based on the shared information of the multiple container units, the correspondence between each container unit and the virtual machine to be deployed in each container unit is determined; the correspondence includes: the first container unit and the second container unit in the multiple container units correspond to the target virtual machine; Based on the aforementioned correspondence, the multiple container units are deployed on their respective virtual machines.

2. The method according to claim 1, characterized in that, The shared information includes at least one of: affinity patterns and resource sharing types; The affinity pattern includes at least one of the following: affinity or anti-affinity with a specified container unit, wherein the affinity indicates support for shared virtual machines, and the anti-affinity indicates that shared virtual machines are not supported; The resource sharing type includes at least one of the following: lending type, borrowing type, and lending and borrowing type. The lending type indicates that a container unit supports lending resources of virtual machines deployed in the container unit. The borrowing type indicates that a container unit supports borrowing resources of virtual machines deployed in other container units. The lending and borrowing type indicates that a container unit supports lending resources of virtual machines deployed in the container unit and borrowing resources of virtual machines deployed in other container units.

3. The method according to claim 2, characterized in that, The shared information of the first container unit includes: a first affinity mode and a first resource sharing type. The shared information of the second container unit includes: a second affinity mode and a second resource sharing type. The first affinity mode and the second affinity mode are used to indicate: the affinity between the first container unit and the second container unit. One of the first resource sharing type and the second resource sharing type supports lending the resources of the deployed virtual machine, and the other supports borrowing the resources of the virtual machine deployed by other container units.

4. The method according to claim 2 or 3, characterized in that, The shared information of the first container unit includes: a first affinity mode; The method further includes: obtaining the scheduling logic of the first container unit; The step of determining the correspondence between each container unit and the virtual machine to be deployed in each container unit based on the shared information of the multiple container units includes: Based on the shared information of the multiple container units, and provided that the first affinity condition is met, the scheduling logic is used to determine the target virtual machine to be deployed by the first container unit.

5. The method according to any one of claims 2-4, characterized in that, The shared information of the first container unit includes: a first resource sharing type, which supports lending resources of the virtual machines deployed in the first container unit; The method further includes: obtaining the specified resource size of the virtual machine to be deployed by the first container unit; The step of determining the correspondence between each container unit and the virtual machine to be deployed in each container unit based on the shared information of the multiple container units includes: Based on the first resource sharing type of the first container unit and the specified resource size, the target virtual machine is determined for the first container unit; the resource size of the target virtual machine is greater than the specified resource size.

6. The method according to any one of claims 2-4, characterized in that, The shared information of the first container unit includes: a first resource sharing type, which supports lending resources of the virtual machines deployed in the first container unit; The method further includes: obtaining the resource size occupied by the first container unit; The step of determining the correspondence between each container unit and the virtual machine to be deployed in each container unit based on the shared information of the multiple container units includes: Based on the resource sharing type of the first container unit and the resource size occupied by the first container unit, the target virtual machine is determined for the first container unit.

7. The method according to any one of claims 1-6, characterized in that, The first container unit and the second container unit satisfy at least one of the following conditions: the same tenant, the same tenant set, the same service, the same service set, or the same container unit set.

8. The method according to any one of claims 1-7, characterized in that, The process of obtaining shared information from multiple container units includes: Receive shared information from multiple container units sent by tenants using the client.

9. The method according to any one of claims 1-8, characterized in that, At least two of the plurality of container units belong to the first tenant. The method further includes: The billing information of the first tenant is determined based on the virtual machines deployed in the target container unit of the at least two container units; wherein the target container unit is a container unit that does not borrow resources from virtual machines deployed in other container units.

10. A container unit deployment device, characterized in that, The device includes: The acquisition module is used to: acquire shared information of multiple container units; the shared information of the multiple container units is used to describe: the multiple container units support the condition of sharing at least one virtual machine, and the number of the multiple container units is greater than the number of the at least one virtual machine; The processing module is configured to: determine, based on shared information of the plurality of container units, the correspondence between each container unit and the virtual machine to be deployed in each container unit; the correspondence includes: the first container unit and the second container unit in the plurality of container units correspond to the target virtual machine; The processing module is further configured to: deploy the plurality of container units on the corresponding virtual machines based on the correspondence.

11. The apparatus according to claim 10, characterized in that, The shared information includes at least one of: affinity patterns and resource sharing types; The affinity pattern includes at least one of the following: affinity or anti-affinity with a specified container unit, wherein the affinity indicates support for shared virtual machines, and the anti-affinity indicates that shared virtual machines are not supported; The resource sharing type includes at least one of the following: lending type, borrowing type, and lending and borrowing type. The lending type indicates that a container unit supports lending resources of virtual machines deployed in the container unit. The borrowing type indicates that a container unit supports borrowing resources of virtual machines deployed in other container units. The lending and borrowing type indicates that a container unit supports lending resources of virtual machines deployed in the container unit and borrowing resources of virtual machines deployed in other container units.

12. The apparatus according to claim 11, characterized in that, The shared information of the first container unit includes: a first affinity mode and a first resource sharing type. The shared information of the second container unit includes: a second affinity mode and a second resource sharing type. The first affinity mode and the second affinity mode are used to indicate: the affinity between the first container unit and the second container unit. One of the first resource sharing type and the second resource sharing type supports lending the resources of the deployed virtual machine, and the other supports borrowing the resources of the virtual machine deployed by other container units.

13. The apparatus according to claim 11 or 12, characterized in that, The shared information of the first container unit includes: a first affinity mode; The acquisition module is further configured to: acquire the scheduling logic of the first container unit; The processing module is specifically used to: based on the shared information of the multiple container units, and under the condition of satisfying the first affinity mode, use the scheduling logic to determine the target virtual machine to be deployed by the first container unit.

14. The apparatus according to any one of claims 11-13, characterized in that, The shared information of the first container unit includes: a first resource sharing type, which supports lending resources of the virtual machines deployed in the first container unit; The acquisition module is further configured to: acquire the specified resource size of the virtual machine to be deployed by the first container unit; The processing module is further specifically configured to: determine the target virtual machine for the first container unit based on the first resource sharing type of the first container unit and the specified resource size; the resource size of the target virtual machine is greater than the specified resource size.

15. The apparatus according to any one of claims 11-13, characterized in that, The shared information of the first container unit includes: a first resource sharing type, which supports lending resources of the virtual machines deployed in the first container unit; The acquisition module is further configured to: acquire the resource size occupied by the first container unit; The processing module is further specifically used to: determine a target virtual machine for the first container unit based on the resource sharing type of the first container unit and the resource size occupied by the first container unit.

16. The apparatus according to any one of claims 10-15, characterized in that, The first container unit and the second container unit satisfy at least one of the following conditions: the same tenant, the same tenant set, the same service, the same service set, or the same container unit set.

17. The apparatus according to any one of claims 10-16, characterized in that, The acquisition module is specifically used to: receive shared information of multiple container units sent by the tenant using the client.

18. The apparatus according to any one of claims 10-17, characterized in that, At least two of the plurality of container units belong to the first tenant. The processing module is further configured to: determine the billing information of the first tenant based on the target container unit among the at least two container units; wherein the target container unit is a container unit that does not borrow resources from virtual machines deployed in other container units.

19. A cloud platform, characterized in that, Includes a control node and at least one worker node. The control node is configured to: acquire shared information of multiple container units; the shared information of the multiple container units is used to describe: the multiple container units support the condition of sharing at least one virtual machine, and the number of the multiple container units is greater than the number of the at least one virtual machine; The control node is configured to: determine the correspondence between each container unit and the virtual machine to be deployed in each container unit based on the shared information of the plurality of container units; the correspondence includes: the first container unit and the second container unit in the plurality of container units correspond to the target virtual machine; The control node is configured to: send a first deployment command to a first working node among the at least one working nodes based on the correspondence; The first working node is configured to: deploy the first container unit and the second container unit on the target virtual machine in response to the first deployment command.

20. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-9.

21. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the method as described in any one of claims 1-9.

22. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-9.

Images