WO2021103646A1 - 一种部署pod的方法及装置 - Google Patents

一种部署pod的方法及装置 Download PDF

Info

Publication number
WO2021103646A1
WO2021103646A1 PCT/CN2020/107865 CN2020107865W WO2021103646A1 WO 2021103646 A1 WO2021103646 A1 WO 2021103646A1 CN 2020107865 W CN2020107865 W CN 2020107865W WO 2021103646 A1 WO2021103646 A1 WO 2021103646A1
Authority
WO
WIPO (PCT)
Prior art keywords
scheduling domain
pod
instruction
resource
containers
Prior art date
Application number
PCT/CN2020/107865
Other languages
English (en)
French (fr)
Inventor
张文博
夏海
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20893282.2A priority Critical patent/EP4057139A4/en
Publication of WO2021103646A1 publication Critical patent/WO2021103646A1/zh
Priority to US17/752,102 priority patent/US20220283846A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5011—Pool

Definitions

  • the embodiments of the present application relate to the field of cloud computing technology, and in particular, to a method and device for deploying a pod.
  • a container is a virtual environment container, which can be regarded as a lightweight virtual machine, both of which can isolate applications. But the container is different from the virtual machine. The main difference between the two is that the virtual machine relies on the virtual machine management system (Hypervisor). Using the Hypervisor, multiple different slave operating systems can be run on the main operating system. Think of it as a virtual machine, and the container is managed by the container engine. It takes a few minutes for the virtual machine to start, and the container can start within a few milliseconds.
  • K8S kubernetes
  • the management system the kubernetes (K8S) container cluster management system
  • K8S can build container deployment services.
  • Pod is the basic deployment unit of K8S.
  • a pod is composed of a group of containers working on the same node.
  • managers issue instructions to deploy pods to the management system.
  • the instructions can include: the number of pods, the number of containers each pod contains, and the amount of each type of resource used by each container during work Information such as the maximum value.
  • the management system determines the sum of the maximum value of the multiple containers contained in the pod that use that type of resource when working, the sum The value is the theoretical resource value of the pod using this type of resource.
  • the management system selects appropriate business nodes to deploy pods, and the business nodes allocate resources corresponding to theoretical resource values for the deployed pods. For example, a pod includes two containers.
  • the embodiments of the present application provide a method and device for deploying a pod, which are used to solve the problem that resources are allocated to a pod according to the maximum value of resources used by each container in the pod at work, which causes a waste of resources.
  • a method for deploying pods which can be applied to management nodes.
  • the management node may receive an instruction to deploy a scheduling domain issued by an administrator or a tenant or a user.
  • the instruction includes the quantity of each type of resource occupied by the scheduling domain, and the resource occupied by the scheduling domain is used for at least one pod.
  • the management node selects a service node for deploying the scheduling domain, and sends an instruction for deploying the scheduling domain to the service node, where the instruction includes the quantity of each type of resource occupied by the scheduling domain.
  • the management node receives an instruction to deploy pods.
  • the instruction includes the number of pods, the number of containers included in each pod, and the associated information of the scheduling domain.
  • the management node sends a pod deployment instruction to the service node according to the associated information of the scheduling domain.
  • the instruction includes the number of pods, the number of containers included in each pod, and the resources used by the pod The ID of the scheduling domain. It should be noted that the order in which the management node receives the instruction to deploy the scheduling domain and receives the instruction to deploy the pod may not be limited.
  • the scheduling domain By first deploying the scheduling domain on the business node, some resources are reserved for the pod. Furthermore, when the pod is deployed, the pod is made to use the resources in the scheduling domain, and it is no longer necessary to allocate resources to the pod according to the maximum value of the resources used by each container in the pod when it is working. Containers in multiple pods can use resources in the scheduling domain, thereby reducing resource waste.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of the resource of this type required by any one of the containers during operation, so as to ensure that it can support the normal operation of all the containers when they work at different points in time. To further reduce waste of resources.
  • the associated information of the scheduling domain is the identifier of the scheduling domain or the type of the scheduling domain or the identifier of the service node. Then, the management node can determine the service node and the scheduling domain where the pod is deployed according to the identifier of the scheduling domain or the type of the scheduling domain or the identifier of the service node.
  • the service nodes and scheduling domains used to deploy pods can be flexibly determined, and the experience effect can be improved.
  • the management node after sending an instruction to deploy a scheduling domain to the service node, can update the remaining amount of each type of resource in the service node in the resource list, and update the resource pool The remaining amount of each type of resource is updated, and the resource pool includes multiple service nodes. In order to achieve the correct recording of resource usage, and further improve resource utilization.
  • the management node can select the service node for deploying the scheduling domain among multiple service nodes according to the resource optimization strategy; or, the command to deploy the scheduling domain received by the management node also includes the service node
  • the management node can use the service node corresponding to the identifier as the service node for deploying the scheduling domain.
  • the instruction to deploy the scheduling domain received by the management node may also include: container isolation in the pod The number of CPUs used and/or the number of CPUs shared by the containers in the pod.
  • the instruction to deploy the pod received by the management node may also include: using the first container identifier of the cpu in isolation from other containers. In this way, the service node allocates the corresponding number of CPUs in the scheduling domain to the first container for exclusive use, and the first container and other containers will not share these CPUs, which can improve the performance of the first container.
  • the management node may receive an instruction to delete the scheduling domain, where the instruction includes the identifier of the scheduling domain. Then the management node determines whether there is a pod using the resource in the identified scheduling domain; if it exists, it sends a prompt message that the scheduling domain cannot be deleted; if it does not exist, it can send delete to the service node that deploys the scheduling domain The instructions of the scheduling domain.
  • the instruction to delete the scheduling domain sent by the management node to the service node includes the identifier of the scheduling domain to be deleted.
  • a method for deploying pods which can be applied to business nodes.
  • the service node may receive an instruction to deploy the scheduling domain sent by the management node, where the instruction includes the quantity of each type of resource occupied by the scheduling domain, and then the service node deploys the scheduling domain according to the instruction to deploy the scheduling domain,
  • the deployed scheduling domain includes a corresponding number of resources of a corresponding type.
  • the service node may also receive a pod deployment instruction sent by the management node.
  • the pod deployment instruction may include the number of pods, the number of containers included in each pod, and the identifier of the scheduling domain for the pod to use resources.
  • the business node can deploy a corresponding number of pods, and each pod includes a corresponding number of containers.
  • the service node controls any of the containers to use the resources in the scheduling domain when working.
  • the scheduling domain By first deploying the scheduling domain on the business node, some resources are reserved for the pod. Furthermore, when the pod is deployed, the pod is made to use the resources in the scheduling domain, and it is no longer necessary to allocate resources to the pod according to the maximum value of the resources used by each container in the pod when it is working. Containers in multiple pods can use resources in the scheduling domain, thereby reducing resource waste.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of the resource of this type required by any one of the containers during operation, so as to ensure that it can support the normal operation of all the containers when they work at different points in time. To further reduce the waste of resources.
  • the instruction to deploy the scheduling domain received by the service node may also include: container isolation in the pod The number of CPUs used and/or the number of CPUs shared by the containers in the pod.
  • the instruction to deploy the pod received by the service node may also include: using the first container identifier of the cpu in isolation from other containers. Then, the service node controls the first container to use the cpu for isolation in the scheduling domain when working, and controls other containers other than the first container to use the CPU in the scheduling domain when working. Other cpus used to isolate the cpu used. In this way, the service node allocates the corresponding number of CPUs in the scheduling domain to the first container for exclusive use, and the first container and other containers will not share these CPUs, which can improve the performance of the first container.
  • a device for deploying a pod is provided, and the communication has the function of realizing the foregoing first aspect and any possible implementation of the first aspect.
  • These functions can be realized by hardware, or by hardware executing corresponding software.
  • the hardware or software includes one or more functional modules corresponding to the above-mentioned functions.
  • a device for pod deployment is provided, and the communication has the function of realizing the foregoing second aspect and any possible implementation of the second aspect.
  • These functions can be realized by hardware, or by hardware executing corresponding software.
  • the hardware or software includes one or more functional modules corresponding to the above-mentioned functions.
  • a device for deploying pods may be the management node in the foregoing method embodiment, or a chip set in the management node.
  • the device includes a communication interface, a processor, and optionally, a memory.
  • the memory is used to store a computer program or instruction
  • the processor is respectively coupled with the memory and a communication interface.
  • the processor executes the computer program or instruction
  • the device executes the first aspect and the first aspect through the communication interface.
  • the method executed by the management node in any possible implementation.
  • a device for deploying pods may be the service node in the foregoing method embodiment, or a chip set in the service node.
  • the device includes a communication interface, a processor, and optionally, a memory.
  • the memory is used to store a computer program or instruction
  • the processor is respectively coupled with the memory and a communication interface.
  • the processor executes the computer program or instruction
  • the device executes the second aspect and the second aspect through the communication interface.
  • the method executed by the business node in any possible implementation.
  • a computer program product comprising: computer program code, when the computer program code runs on a computer, the computer executes the first aspect and any one of the possible aspects of the first aspect. Implementation of the method executed by the management node.
  • a computer program product comprising: computer program code, when the computer program code is run on a computer, the computer executes any of the above-mentioned second aspect and any possible aspect of the second aspect The method executed by the business node in the implementation.
  • the present application provides a chip system that includes a processor and a memory, and the processor and the memory are electrically coupled; the memory is used to store computer program instructions; the processor , Used to execute part or all of the computer program instructions in the memory, when the part or all of the computer program instructions are executed, used to implement the above-mentioned first aspect and the management node in any possible implementation method of the first aspect Function.
  • the chip system may further include a communication interface, and the communication interface is used to send a signal processed by the processor or receive a signal input to the processor.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the present application provides a chip system that includes a processor and a memory, and the processor and the memory are electrically coupled; the memory is used to store computer program instructions; the processor , Used to execute part or all of the computer program instructions in the memory, when the part or all of the computer program instructions are executed, used to implement the second aspect and the service node in any possible implementation method of the second aspect Function.
  • the chip system may further include a communication interface, and the communication interface is configured to send a signal processed by the processor or receive a signal input to the processor.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • a computer-readable storage medium stores a computer program.
  • the computer program When the computer program is run, the first aspect and any possible implementation of the first aspect are managed by the management The method executed by the node is executed.
  • a computer-readable storage medium stores a computer program.
  • the computer program When the computer program is run, the first aspect and any possible implementation of the first aspect are determined by the business The method executed by the node is executed.
  • a system for deploying pods includes: a management node that executes the method in any one of the foregoing first aspect and the first aspect, and executes the foregoing second aspect and the second aspect The business node of any possible implementation of the method.
  • Figure 1 is a cloud computing system provided in an embodiment of the application
  • Figures 2a, 2b, and 2c are respectively schematic diagrams of allocating resources for pods provided in an embodiment of the application;
  • FIG. 3 is a schematic diagram of a process for deploying a pod provided in an embodiment of the application
  • FIG. 4 is a schematic diagram of a process of deploying a scheduling domain provided in an embodiment of this application.
  • FIG. 5 is a schematic diagram of a process for deploying a pod provided in an embodiment of the application.
  • Fig. 6, Fig. 7, Fig. 8, and Fig. 9 are respectively structural diagrams of a pod deployment device provided in an embodiment of the application.
  • k8s is a docker-based Kaiyuan container cluster management system, which can build a container scheduling service. The purpose is to allow users to manage cloud container clusters through k8s clusters without requiring users to perform complex settings. The system will automatically select appropriate working nodes to perform specific container cluster scheduling processing tasks.
  • the core concept is the container pod.
  • a pod is composed of a group of containers working on the same worker node.
  • Pod is the most basic deployment unit of k8s, which can include multiple container containers, logically identifying an instance of a certain application.
  • a web application consists of three components, a front end, a back end, and a database. These three components run in their respective containers. For this instance, a pod containing three containers can be common.
  • the scheduling domain also called resource collection, resource pool, etc.
  • the "and/or” in this application describes the association relationship of the associated objects, indicating that there can be three types of relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone. This situation.
  • the character “/” generally indicates that the associated objects before and after are in an "or” relationship.
  • the multiple involved in this application refers to two or more.
  • the word "exemplary” is used to mean serving as an example, illustration, or illustration. Any embodiments or implementations described as “examples” in this application should not be construed as being more preferred or advantageous than other embodiments or implementations. Rather, the term example is used to present the concept in a concrete way.
  • the embodiments of the present application provide a method and device for deploying a pod.
  • the method and device are based on the same technical concept. Since the principles of the method and device to solve the problem are similar, the implementation of the device and the method can be referred to each other, and there is no repetition. Go into details again.
  • the technical solutions of the embodiments of this application can be applied to various cloud-based communication systems, such as long-term evolution (LTE) systems, worldwide interoperability for microwave access (WiMAX) communication systems, and future The fifth generation (5th Generation, 5G) system, such as the new generation of radio access technology (NR), and future communication systems.
  • LTE long-term evolution
  • WiMAX worldwide interoperability for microwave access
  • 5G fifth generation
  • NR radio access technology
  • FIG. 1 it includes a master node and a worker node.
  • a container cloud management platform (manage platform) (hereinafter referred to as a management system) can be deployed on the management node.
  • the cloud management platform is the k8s management system.
  • the management system can select a suitable business node to deploy containers according to business requirements.
  • the management system can be regarded as a set of processes that manage the life cycle of the container.
  • it includes a control module (controller), a scheduling module (scheduler), an application programming interface service (application programming interface server, API server) module and so on.
  • control module controller
  • scheduling module scheduling module
  • application programming interface service application programming interface server
  • API server API server
  • the API server module provides the only operation entry for the resource object, that is, the interface module that provides users with functions. All other components must operate resource data through the API interface provided by it, and complete related network elements by monitoring related resource data.
  • the control module is responsible for the unified management and control of various container models, such as CRUD (add Create, read query Read, update Update, and delete delete) operations on the container model.
  • the container model for example, can indicate one or more of the following information: the number of containers included in the pod, the type of application running in the container, the maximum value of each type of resource used by the container when it is working, and which container needs it Exclusive cpu and other information.
  • the scheduling module is responsible for selecting the appropriate business node for the deployed unit (container or pod).
  • the agent component is responsible for the life cycle management of pod deployment, modification, monitoring, and deletion on the business node, and is also responsible for regularly reporting the status information of the node to the API server module in the management node.
  • the container engine component may be responsible for deploying the container, and the container engine component may be, for example, a Docker component.
  • pods are the basic deployment unit of k8s
  • users or tenants or managers can issue instructions to deploy pods to the management system according to business needs.
  • the instructions can include information such as the number of pods, the number of containers each pod contains, and the maximum value of each type of resource used by each container during work.
  • the management system determines the sum of the maximum values of each type of resource used by multiple containers in a pod when working, and selects the appropriate business node to deploy the pod.
  • the service node allocates resources of the sum of the maximum value to the deployed pod.
  • the business node takes the cpu resources used by the pod at work as an example: when the business node allocates cpu resources to the pod, it actually allocates the use time of the cpu for the pod. For example, if the business node allocates 3 CPUs to the pod, it can be understood that the business node allocates 3 CPU usage time to the pod.
  • each pod includes two containers.
  • containers a1 and a2 are working, they use two CPUs at most, and containers b1 and b2 are working.
  • the business node allocates 3 CPUs to pod1, namely cpu1, cpu2, and cpu3, and allocates 3 CPUs to pod2, namely cpu4, cpu5, and cpu6.
  • the container uses all the running time of its allocated cpu.
  • the resources allocated by the business node to different pods are isolated from each other. At any time, the container in one pod cannot use the resources allocated for other pods.
  • the container in pod1 cannot use cpu4, cpu5, and cpu6 allocated for pod2, and container a1 can use any two of the cpu1, cpu2, and cpu3 allocated for pod1, such as cpu1 and cpu2, and container b1 can use cpu1 allocated by pod1 , Any one of cpu2 and cpu3, such as cpu1 or cpu2 or cpu3.
  • the container in pod2 cannot use the cpu1, cpu2, and cpu3 allocated for pod1.
  • the container a2 can use any two of the cpu4, cpu5, and cpu6 allocated for pod2.
  • the container b2 can use the cpu4, cpu5, and cpu4 allocated by pod2. Any cpu in cpu6.
  • the resources allocated by the service node to different pods are physically shared, and different pods use the shared resources for different times.
  • the service node may specify a cpu group that can be used by pod1, and the number of cpu included in the cpu group is equal to the maximum number of cpu required by pod1.
  • the business node allocates cpu1-cpu6 to the pod, and can also instruct pod1 to use 50% of the running time of cpu1 to cpu6, and six 50% is 300%, that is, the time that pod1 uses cpu is 300%, which is pod1 3 cpus are allocated.
  • the business node can instruct pod2 to use cpu1-cpu6 for another 50% of the time, which is equivalent to allocating 3 cpu for pod2.
  • the working hours of multiple containers in a pod may be different.
  • allocating resources to the pod according to the maximum value of the resources used by each container during work will cause resource waste.
  • the maximum resource is generally not used.
  • the resources used by the container in a certain pod reach the maximum value during work, there will generally not be multiple containers in the pod that reach the maximum value. Therefore, the above allocation of resources to pods according to the maximum value of resources used by each container during work will result in a waste of resources.
  • the scheduling domain can be regarded as a collection of resources, which can include multiple types of resources, such as computing resources, memory resources, network bandwidth resources, and disk resources. Wait.
  • Resources in the scheduling domain can be used by containers in one pod or multiple pods. In this way, containers in multiple pods can use resources in the same resource set, which can improve resource utilization.
  • the business node deploys scheduling domain 1, and scheduling domain 1 occupies cpu1-cpu5.
  • the containers in pod1 and pod2 generally work at different points in time, and the containers in pod1 and pod2 are working
  • the cpu resources in the scheduling domain 1 can be used at any time.
  • the management node and service node shown in Figure 1 should also add related functions about the scheduling domain.
  • a CRUD interface that supports the scheduling domain can be set on the management node, for example, the interface is defined as a 1F1 interface, and the interface can execute CRUD instructions.
  • the control module in the management node can also be responsible for the unified management and control of various scheduling domain models.
  • this part of the function can be defined as a control sub-module.
  • the scheduling domain model can indicate the resource information of the scheduling domain, such as the type of resources occupied, and how much each type of resource occupies.
  • the scheduling domain model can also indicate information such as which types of applications use the resources in the scheduling domain.
  • the scheduling module in the management node can also select an appropriate service node for the scheduling domain to be deployed.
  • this part of the function can be defined as a scheduling sub-module.
  • the container model may also indicate the scheduling domain model of the pod model affinity.
  • the agent component in the business node can also be responsible for the management and control of resources in the scheduling domain, such as reserving resources or releasing resources.
  • the agent component may include a kunelet component, for example.
  • Step 301 The management node receives an instruction to deploy a scheduling domain, where the instruction to deploy the scheduling domain includes the quantity of each type of resource occupied by the scheduling domain, and the resource occupied by the scheduling domain is used for at least one pod.
  • a user When a user needs to deploy a pod, he can request a deployment scheduling domain from the management system to reserve resources for the pod to be deployed later.
  • the scheduling domain for example, it can execute an instruction to create a new scheduling domain on the display interface of the management system, or it can be a file describing the creation of a scheduling domain.
  • the management node where the management system is located can receive the instruction to deploy the scheduling domain.
  • one instruction may indicate the deployment of multiple scheduling domains, and the deployment method of the management node for each scheduling domain is the same. In this application, the deployment of a scheduling domain is taken as an example for description.
  • the number of resources of each type occupied by the deployed scheduling domain For example, the number of CPUs, the bandwidth value of the network bandwidth, the number of disks, and how many megabytes of memory are used.
  • the user can define the associated information of the scheduling domain, and the instruction to deploy the scheduling domain received by the management node may also include the associated information of the scheduling domain to be deployed.
  • the associated information may be the identifier of the scheduling domain, or the type of the scheduling domain, or the identifier of the service node, or the like.
  • the resource information of the scheduling domain may be input or selected by the user in the management system, that is, the user indicates the quantity of each type of resource occupied by the scheduling domain.
  • the scheduling domain model when a user, an administrator, or a tenant sets the scheduling domain model, they can define resource information for the scheduling domain model.
  • the instruction to deploy the scheduling domain received by the management node is for a certain scheduling domain model, indicating how many scheduling domains are created using the scheduling domain model. Then the instruction to deploy the scheduling domain includes resource information occupied by the scheduling domain.
  • the name of the scheduling domain model here can be understood as the type of the scheduling domain.
  • the management information of the scheduling domain in the instruction to deploy the scheduling domain may also include the type of the scheduling domain.
  • the number of the resource is less than the sum of the maximum value of all the containers that need this type of resource when working.
  • the value is not less than the maximum value of the resource of this type required by any one of the containers during operation, so as to ensure that it can support all the containers to work normally at different points in time.
  • Step 302 The management node selects the service node used to deploy the scheduling domain, and sends an instruction to deploy the scheduling domain to the service node.
  • the service node receives the command to deploy the scheduling domain sent by the management node.
  • the instruction includes the amount of each type of resource occupied by the scheduling domain.
  • the management node manages multiple service nodes. After receiving the instruction to deploy the scheduling domain, the management node can select a suitable service node from the multiple service nodes to deploy the scheduling domain. After selecting a suitable service node, the service node can be controlled to deploy the corresponding scheduling domain.
  • the management node may select the service node for deploying the scheduling domain among multiple service nodes according to the resource optimization strategy.
  • the identifier of the service node that instructs the deployment of the scheduling domain is instructed, that is, the command to deploy the scheduling domain received by the management node also includes the identifier of the service node.
  • the management node may use the service node corresponding to the identifier as the service node for deploying the scheduling domain.
  • the management node After the management node deploys the scheduling domain on a suitable service node, the management node can save the identifier of the scheduling domain and the corresponding relationship between the identifier of the service node. Further, the correspondence between the identifier of the scheduling domain, the type of the scheduling domain, and the identifier of the service node can also be saved.
  • Step 303 The service node deploys the scheduling domain, where the scheduling domain includes a corresponding number of resources of a corresponding type in the instruction.
  • the service node may feed back a response message of successful deployment to the management node.
  • the instruction to deploy the scheduling domain received by the management node includes the identifier of the service node, and the management node deploys the scheduling domain on the service node corresponding to the identifier.
  • the designated service node may have insufficient resources, and the service node may feed back a response message of deployment failure to the management node.
  • the management node receives the response message of the deployment failure, and then selects an appropriate node to deploy the scheduling domain until the deployment is successful.
  • the management node may maintain a resource list for all business nodes. After the management node sends the instruction to deploy the scheduling domain to the service node, the management node may also update the remaining amount of each type of resource in the service node in the resource list. And the management node can also update the remaining amount of each type of resource in the resource pool, and the resource pool includes multiple service nodes.
  • Step 304 The management node receives an instruction to deploy pods.
  • the instruction includes the number of pods, the number of containers included in each pod, and the associated information of the scheduling domain.
  • a user or a manager or a tenant may send a pod deployment instruction to the management system.
  • the pod deployment instruction may include the number of pods and the number of containers included in each pod. Because the management system has been deployed with a scheduling domain. Then the pod deployment instruction may include the associated information of the scheduling domain, so that the management system can find a suitable scheduling domain for the pod to be deployed to use the resources therein.
  • the number of containers included in each pod may be input or selected by the user in the management system, that is, the user indicates the number of containers included in the pod.
  • the user or manager or tenant when the user or manager or tenant sets the container model, they can define the number of containers included in the pod for the container model.
  • the pod deployment instruction received by the management node is for a certain container model, indicating how many pods are created using the container model.
  • the scheduling domain type indicates which type of resource in the scheduling domain is used by the deployed pod.
  • step 304 and step 301 is not limited.
  • Step 305 The management node sends a pod deployment instruction to the service node according to the associated information of the scheduling domain.
  • the service node receives the pod deployment instruction.
  • the instruction includes the number of pods and the containers each pod includes The number of, and the identifier of the scheduling domain for the pod to use resources.
  • the management node can find the service node used to deploy the pod according to the associated information of the scheduling domain, and determine which resource in the scheduling domain of the service node can be used by the pod to be deployed.
  • the associated information of the scheduling domain may include the identifier of the business node, and the management node may use the identified business node as the business node for deploying the pod .
  • the management node selects an appropriate scheduling domain on the service node for the pod to be deployed.
  • the associated information of the scheduling domain may include the type of the scheduling domain, and the management node may identify the service node according to the pre-saved correspondence between the type of the scheduling domain and the identifier of the service node, and use the identified service node as the deployment pod Business node.
  • the associated information of the scheduling domain includes the identifier of the scheduling domain
  • the management node can identify the service node where the pod is deployed according to the pre-saved correspondence between the identifier of the scheduling domain and the identifier of the service node.
  • the scheduling domain association information does not restrict the type of scheduling domain and the identifier of the scheduling domain, you can select it on the service node Any scheduling domain, used for pod use. If the type of the scheduling domain is restricted in the associated information of the scheduling domain, any scheduling domain of the corresponding type can be selected for use by the pod at the service node. If the identification of the scheduling domain is restricted in the associated information of the scheduling domain, the identified scheduling domain in the service node can be used for pod use.
  • the corresponding relationship between the identifier of the scheduling domain and the identifier of the pod can be stored on the management node.
  • Step 306 The service node creates a corresponding number of pods, and each pod includes a corresponding number of containers; the service node controls any of the containers to use the resources in the identified scheduling domain when working.
  • the performance requirements of applications run by containers in multiple pods are not the same, some have high performance requirements, and some have low performance requirements. Further, if the number of resources of each type occupied by the scheduling domain includes the number of CPUs occupied by the scheduling domain;
  • the instruction to deploy the scheduling domain received by the service node may also include: the cpu used for container isolation in the pod The number of and/or the number of cpus shared by the containers in the pod.
  • the instruction to deploy the pod received by the service node may also include: using the first container identifier of the cpu in isolation from other containers.
  • the service node controls the first container to use the cpu used for isolation in the scheduling domain when working, and controls other containers other than the first container to use the scheduling domain when working, except for Isolate the other cpu of the used cpu.
  • the use of resources for container isolation can be understood as the business node assigns the resource to a container for independent use, and other containers cannot use it.
  • the resource used for container sharing can be understood as the business node assigning the resource to multiple containers for use, and the multiple containers can use the resource at the same point in time or at different points in time.
  • the service node allocates the corresponding number of CPUs in the scheduling domain to the first container for exclusive use, and the first container and other containers will not share these CPUs, which can improve the performance of the first container.
  • the number of CPUs used for container isolation in the pod included in the instructions for deploying the scheduling domain is 2, and the container a1 in pod1 is instructed to use CPUs in isolation from other containers.
  • container a2 in pod2 uses cpu in isolation from other containers.
  • the business node can allocate cpu1 to the container a1 and cpu5 to the container according to the instructions.
  • the service node controls the container a1 in pod1 to use cpu1 when working, and the container a2 in pod2 to use cpu5 when working, and cpu1 and cpu5 cannot be used by other containers.
  • the business node can control the container b1 and the container b2 to use any one or more of cpu2, cpu3, and cpu4 when working.
  • scheduling module including scheduling sub-module
  • control module including control sub-module
  • step 41 shown in Figure 4 The user can call the API server interface module to issue an instruction to deploy the scheduling domain.
  • the instruction to deploy the scheduling domain includes the number of scheduling domains and resource information of the scheduling domain. That is, the number of resources of each type occupied by the scheduling domain.
  • step 302 For the specific process of step 302, refer to step 42 to step 46 shown in FIG. 4.
  • Step 42 The control sub-module in the control module in the management node can pay attention to whether the API server module receives the instruction to deploy the scheduling domain.
  • Step 43 If the control sub-module determines that the API server module receives the instruction to deploy the scheduling domain, it can obtain the content in the instruction to deploy the scheduling domain, such as the number of deployed scheduling domains and the resource information occupied by each scheduling domain. Further, the control sub-module saves the content in the instruction to a database, such as storage db, through the API server module.
  • Step 44 The scheduling sub-module in the scheduling module in the management node can pay attention to whether the API server module receives an instruction to deploy the scheduling domain, that is, to determine whether there is a scheduling domain that needs to be deployed. If the scheduling sub-module determines that the API server module has received the instruction to deploy the scheduling domain, it can request the API server to access the database, and inform the scheduling sub-module of the information of the scheduling domain that needs to be deployed.
  • Step 45 If the scheduling sub-module determines that there is a scheduling domain to be deployed, it can select an appropriate service node for the scheduling domain to be deployed, and notify the API server module of the identifier of the selected service node.
  • Step 46 The API server module can send an instruction to deploy the scheduling domain to the agent component in the business node.
  • the agent component receives the instruction to deploy the scheduling domain.
  • the deployment scheduling domain instruction indicates the resource information occupied by the scheduling domain, and It can indicate the identifier of the scheduling domain, etc.
  • the agent component can subscribe to the API server module for the status information of its own business node, and when the API server module needs to update the status of the business node, it can notify the agent component of the business node.
  • the status update for example, deploys a scheduling domain on the service node. Specifically, when there is a scheduling domain to be deployed on a business node, the API server module actively sends an instruction to deploy the scheduling domain to the agent component of the business node.
  • step 303 For the specific process of step 303, refer to step 47 in FIG. 4: the agent component deploys the corresponding scheduling domain according to the deployment scheduling domain instruction.
  • the agent reserves resources according to the resource information in the deployment scheduling domain instruction, for example, including cpu, memory and other resources. And allocate the corresponding resources for the corresponding scheduling domain.
  • the agent can also create configuration information for the scheduling domain, for example, create a directory corresponding to the resource, and create resource-related constraints, that is, what resources are allocated for the scheduling domain, and can also create a network namespace.
  • the user can call the API server interface module to issue a pod deployment instruction.
  • the pod deployment instruction includes the number of pods and the number of containers each pod includes. It can also include the associated information of the scheduling domain.
  • step 35 The specific process of the above step 35 can participate in step 52 to step 56 shown in FIG. 5:
  • Step 52 The control module in the management node can pay attention to whether the API server module receives the instruction to deploy the pod.
  • Step 53 If the control module determines that the API server module has received the pod deployment instruction, it can obtain the content information in the pod deployment instruction, that is, the number of pods to be deployed and the associated information of the scheduling domain. Further, the control module saves the content of the instruction to the database through the API server module.
  • Step 54 The scheduling module in the management node can pay attention to whether the API server module receives the instruction to deploy the pod, that is, determines whether there is a pod that needs to be deployed. If the scheduling module determines that the API server module has received the instruction to deploy the pod, it can request the API server to access the database and inform the scheduling module of the information about the pod that needs to be deployed.
  • Step 55 If the scheduling module determines that there is a pod to be deployed, it can select an appropriate service node according to the associated information of the scheduling domain, and notify the API server module of the identifier of the selected service node.
  • Step 56 The API server module sends a pod deployment instruction to the agent component on the selected business node.
  • the agent component receives the pod deployment instruction.
  • the instruction indicates the number of pods, the number of containers included in the pod, and can also indicate The identifier of the scheduling domain, etc.
  • the agent component can subscribe to the API server module for the status information of its own business node, and when the API server module needs to update the status of the business node, it can notify the agent component of the business node.
  • Status update for example, deploy pods on business nodes. Specifically, when a pod is to be deployed on a business node, the API server module actively sends an instruction to deploy the pod to the agent component on the business node.
  • step 57 in FIG. 5 the agent component notifies the container engine component of the instruction to create the pod, and the container engine component deploys the corresponding pod according to the instruction.
  • the Agent component can also create configuration information for the pod, for example, create a directory corresponding to the resource, and create resource-related constraints, that is, which resource in the scheduling domain is used, and can also create a network namespace.
  • the user can also request to delete the pod according to business requirements.
  • the management node receives an instruction to delete a pod, and the instruction to delete the pod includes an identifier of the pod.
  • the management node determines the business node to deploy the identified pod according to the correspondence between the stored pod identifier and the business node identifier.
  • send a pod deletion instruction to the service node e.g., the service node receives the pod deletion instruction sent by the management node.
  • the pod deletion instruction includes the identification of the pod, and the business node can delete the identified pod. It can be explained that the resources in a scheduling domain can be used for multiple pods at the same time.
  • the management node can select an appropriate scheduling domain for the pod to be deployed according to the resources in the scheduling domain and the pod that uses the resource, so as to avoid resource waste.
  • the user can also request to delete the scheduling domain according to business requirements. For example, it may be that the management node receives an instruction to delete the scheduling domain, the instruction includes the identifier of the scheduling domain; the management node can determine whether there is a pod using the resource in the identified scheduling domain; if so, the identified scheduling domain cannot be deleted At this time, a prompt message that the scheduling domain cannot be deleted can be issued; if there is no pod using the resources in the identified scheduling domain, an instruction to delete the scheduling domain is sent to the service node that deploys the scheduling domain, correspondingly Yes, the service node receives an instruction to delete the identified scheduling domain. The service node can execute the instruction to delete the identified scheduling domain, that is, to release the resources in the scheduling domain.
  • the service node may also determine whether there is a pod using the resource in the identified scheduling domain. For example, the management node receives an instruction to delete the scheduling domain, and the instruction to delete the scheduling domain includes the information of the scheduling domain. Identification, the management node sends the instruction to delete the scheduling domain to the service node, and correspondingly, the service node receives the instruction to delete the scheduling domain. The service node determines whether there is a pod using the resource in the identified scheduling domain; if so, the identified scheduling domain cannot be deleted.
  • the service node can feed back the information that the scheduling domain cannot be deleted to the management node; if it does not exist
  • the pod uses the resources in the identified scheduling domain, and the service node executes the instruction to delete the identified scheduling domain, and may also report the success of the deletion to the management node.
  • an apparatus 600 for deploying pods is provided.
  • the apparatus 600 for deploying pods can execute the steps performed by the management node in the method of FIG. 3 above. To avoid repetition, I will not go into details here.
  • the apparatus 600 for deploying pods may be a management node or a chip applied to the management node.
  • the apparatus 600 for deploying pods may include: a transceiver module 620, a processing module 610, and optionally, a storage module 630; the processing module 610 may be connected to the storage module 630 and the transceiver module 620 respectively, and the storage module 630 may also be connected to the transceiver module 620. Module 620 is connected;
  • the transceiver module 620 is configured to receive an instruction to deploy a scheduling domain, where the instruction includes the quantity of each type of resource occupied by the scheduling domain, and the resource occupied by the scheduling domain is used by at least one pod;
  • the processing module 610 is configured to select a service node for deploying the scheduling domain
  • the transceiver module 620 is further configured to send an instruction to deploy a scheduling domain to the service node, where the instruction includes the quantity of each type of resource occupied by the scheduling domain; and to receive an instruction to deploy a pod, the instruction includes the number of pods, The number of containers included in each pod and the associated information of the scheduling domain; and according to the associated information of the scheduling domain, an instruction to deploy the pod is sent to the service node.
  • the instruction includes the number of pods, and each pod includes The number of containers and the identifier of the scheduling domain for the pod to use resources.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of resources of this type required by any of the containers during operation.
  • the associated information of the scheduling domain is the identifier of the scheduling domain or the type of the scheduling domain or the identifier of the service node.
  • the processing module 610 is further configured to update the remaining amount of each type of resource in the service node in the resource list, and to update the remaining amount of each type of resource in the resource pool.
  • the resource pool includes multiple business nodes.
  • the storage module 630 may be used to store the remaining amount of each type of resource in the resource pool, and/or the remaining amount of each type of resource in the service node.
  • the processing module 610 when used to select a service node for deploying the scheduling domain, it is specifically used for: selecting a plurality of service nodes for deployment of the scheduling domain according to the resource optimization strategy
  • the received instruction to deploy the scheduling domain also includes the identifier of the service node, and the service node corresponding to the identifier is used as the service node for deploying the scheduling domain.
  • the instructions for deploying the scheduling domain also include: the CPU used for container isolation in the pod The number and/or the number of cpu shared and used by the containers in the pod; the instruction for deploying the pod further includes: the identification of the first container that uses the cpu in isolation from other containers.
  • the transceiver module 620 is further configured to receive an instruction to delete the scheduling domain, the instruction including the identifier of the scheduling domain; the processing module 610 is also configured to determine whether there is a pod using the identifier If it is, send a prompt message that the scheduling domain cannot be deleted; if not, send an instruction to delete the scheduling domain to the service node that deploys the scheduling domain through the transceiver module.
  • the storage module 630 may be used to store the identifier of the service node, the identifier and/or type correspondence of the scheduling domain deployed on the service node.
  • the identity of the business node and the identity of the pod deployed on the business node can also be stored. It can also store the identifier of the pod and the identifier of the scheduling domain to which the resource used by the pod belongs.
  • the processing module 610 shown in FIG. 6 may include the functions of the control module and the scheduling module in FIG. 4 described above.
  • the transceiver module 620 shown in FIG. 6 may include the function of the API server module in FIG. 4 described above.
  • an apparatus 700 for deploying a pod can execute each step performed by a service node in the method of FIG.
  • the pod deployment apparatus 700 may be a service node, or may be a chip applied to the service node.
  • the device 700 for deploying pod may include: a transceiver module 720, a processing module 710, and optionally, a storage module 730; the processing module 710 may be connected to the storage module 730 and the transceiver module 720 respectively, and the storage module 730 may also be connected to the transceiver module 720.
  • Module 720 is connected;
  • the transceiver module 720 is configured to receive an instruction to deploy a scheduling domain sent by a management node, where the instruction includes the quantity of each type of resource occupied by the scheduling domain;
  • the processing module 710 is configured to deploy the scheduling domain, and the scheduling domain includes a corresponding number of resources of a corresponding type;
  • the transceiver module 720 is further configured to receive a pod deployment instruction sent by the management node, the instruction including the number of pods, the number of containers included in each pod, and the identifier of the scheduling domain for the pod to use resources;
  • the processing module 710 is further configured to deploy a corresponding number of pods, each pod includes a corresponding number of containers; and control any of the containers to use the resources in the scheduling domain when working.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of resources of this type required by any of the containers during operation.
  • the instructions for deploying the scheduling domain also include: the CPU used for container isolation in the pod The number and/or the number of cpu used by the containers in the pod; the instructions for deploying the pod further include: the identification of the first container that uses the cpu in isolation from other containers; the processing module 710 is used to control tasks When the container uses the resources in the scheduling domain during work, it is specifically used to: control the first container to use the cpu for isolation use in the scheduling domain during work, and control the outside of the first container When working, other containers use other cpus in the scheduling domain except for the cpu used for isolation.
  • the storage module 730 may be used to store the identifier of the pod and the identifier of the scheduling domain to which the resource used by the identified pod belongs.
  • the processing module 710 shown in FIG. 7 may include the functions of the container engine component shown in FIG. 5 and other functions in the agent component except for sending and receiving signals.
  • the transceiver module 720 shown in FIG. 7 may include functions other than signal transmission and reception in the agent component shown in FIG. 5.
  • FIG. 8 is a schematic block diagram of a pod deployment apparatus 800 according to an embodiment of the present application. It should be understood that the apparatus 800 for deploying pods can execute each step performed by the management node in the method shown in FIG. 3, and in order to avoid repetition, details are not described herein again.
  • the device 800 for pod deployment includes a processor 810 and a communication interface 820, and optionally, a memory 830, where the processor 810 and the memory 830 are electrically coupled;
  • the memory 830 is configured to store a computer program; the processor 810 may be configured to call a computer program or instruction stored in the memory to receive an instruction to deploy a scheduling domain through the communication interface 820, the instruction Including the quantity of each type of resource occupied by the scheduling domain, the resource occupied by the scheduling domain is used for at least one pod; and the service node for deploying the scheduling domain is selected; and the service node is communicated to the service node through the communication interface 820 Send an instruction to deploy the scheduling domain, the instruction including the quantity of each type of resource occupied by the scheduling domain; and receive an instruction to deploy the pod, the instruction including the number of pods, the number of containers included in each pod, and the scheduling domain And according to the associated information of the scheduling domain, send a pod deployment instruction to the service node, the instruction includes the number of pods, the number of containers included in each pod, and the use of resources for the pod The ID of the scheduling domain.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of resources of this type required by any of the containers during operation.
  • the associated information of the scheduling domain is the identifier of the scheduling domain or the type of the scheduling domain or the identifier of the service node.
  • the processor 810 is further configured to update the remaining amount of each type of resource in the service node in the resource list, and to update the remaining amount of each type of resource in the resource pool.
  • the resource pool includes multiple business nodes.
  • the memory 830 may be used to store the remaining amount of each type of resource in the resource pool, and/or the remaining amount of each type of resource in the service node.
  • the processor 810 when used to select the service node for deploying the scheduling domain, it is specifically configured to: according to the resource optimization strategy, select among multiple service nodes for deployment of the scheduling domain Or, the received instruction to deploy the scheduling domain also includes the identifier of the service node, and the service node corresponding to the identifier is used as the service node for deploying the scheduling domain.
  • the instructions for deploying the scheduling domain also include: the CPU used for container isolation in the pod The number and/or the number of cpu shared and used by the containers in the pod; the instruction for deploying the pod further includes: the identification of the first container that uses the cpu in isolation from other containers.
  • the communication interface 820 is further configured to receive an instruction to delete a scheduling domain, and the instruction includes an identifier of the scheduling domain; the processor 810 is also configured to determine whether there is a pod using the identifier. If it is, send a prompt message that the scheduling domain cannot be deleted; if not, send an instruction to delete the scheduling domain to the service node that deploys the scheduling domain through the transceiver module.
  • the memory 830 may be used to store the identifier of the service node, the identifier and/or type correspondence of the scheduling domain deployed on the service node.
  • the identity of the business node and the identity of the pod deployed on the business node can also be stored. It can also store the identifier of the pod and the identifier of the scheduling domain to which the resource used by the pod belongs.
  • the processor 810 shown in FIG. 8 may include the functions of the control module and the scheduling module in FIG. 4 described above.
  • the communication interface 820 shown in FIG. 8 may include the function of the API server module in FIG. 4 described above.
  • FIG. 9 is a schematic block diagram of a pod deployment apparatus 900 according to an embodiment of the present application. It should be understood that the apparatus 900 for deploying pods can execute each step executed by the service node in the method shown in FIG. 3, and in order to avoid repetition, details are not described herein again.
  • the device 900 for deploying a pod includes a processor 910 and a communication interface 920, and optionally, a memory 930, where the processor 910 and the memory 930 are electrically coupled;
  • the memory 930 is configured to store a computer program; the processor 910 may be configured to call a computer program or instruction stored in the memory to receive an instruction to deploy a scheduling domain sent by the management node through the communication interface 920 ,
  • the instruction includes the quantity of each type of resource occupied by the scheduling domain; it can also be used to deploy the scheduling domain, and the scheduling domain includes a corresponding number of resources of the corresponding type; it can also be received through the communication interface 920 A pod deployment instruction sent by the management node.
  • the instruction includes the number of pods, the number of containers included in each pod, and the identifier of the scheduling domain for the pod to use resources; a corresponding number of pods can also be deployed, each The pod includes a corresponding number of containers; and controls any of the containers to use the resources in the scheduling domain when working.
  • the number of the resource is less than the maximum value of all the containers that require this type of resource during operation
  • the sum value is not less than the maximum value of resources of this type required by any of the containers during operation.
  • the instructions for deploying the scheduling domain also include: the CPU used for container isolation in the pod The number and/or the number of cpu used for shared use by containers in the pod; the instructions for deploying the pod further include: the identification of the first container that uses the cpu in isolation from other containers; the processor 910 is used to control tasks When the container uses the resources in the scheduling domain during work, it is specifically used to: control the first container to use the cpu for isolation use in the scheduling domain during work, and control the outside of the first container When working, other containers use other cpus in the scheduling domain except for the cpu used for isolation.
  • the memory 930 may be used to store the identifier of the pod and the identifier of the scheduling domain to which the resource used by the identified pod belongs.
  • the processor 910 shown in FIG. 9 may include the functions of the container engine component shown in FIG. 5 and other functions in the agent component except for sending and receiving signals.
  • the communication interface 920 shown in FIG. 9 may include functions other than sending and receiving signals in the agent component shown in FIG. 5.
  • the aforementioned processor may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.
  • the processor may further include a hardware chip or other general-purpose processors.
  • the above-mentioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof.
  • the above-mentioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (generic array logic, GAL) and other programmable logic devices , Discrete gates or transistor logic devices, discrete hardware components, etc. or any combination thereof.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the memory mentioned in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), and electrically available Erase programmable read-only memory (Electrically EPROM, EEPROM) or flash memory.
  • the volatile memory may be a random access memory (Random Access Memory, RAM), which is used as an external cache.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • DRAM synchronous dynamic random access memory
  • DDR SDRAM Double Data Rate Synchronous Dynamic Random Access Memory
  • Enhanced SDRAM, ESDRAM Enhanced Synchronous Dynamic Random Access Memory
  • Synchronous Link Dynamic Random Access Memory Synchronous Link Dynamic Random Access Memory
  • DR RAM Direct Rambus RAM
  • the embodiment of the present application also provides a computer storage medium that stores a computer program, and when the computer program is executed by a computer, the computer can be used to execute the above-mentioned method for deploying a pod.
  • the embodiment of the present application also provides a computer program product containing instructions, which when running on a computer, enables the computer to execute the method for deploying a pod provided above.
  • the embodiment of the present application also provides a pod deployment system, the system includes: a management node and a business node that execute the above-mentioned pod deployment method.
  • this application can be provided as methods, systems, or computer program products. Therefore, this application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

Abstract

本申请涉及云计算技术领域，公开了一种部署pod的方法及装置，解决按照pod中容器在工作时使用的资源的最大值来为pod分配资源造成资源浪费的问题。管理节点接收部署调度域的指令，指令包括调度域占用的每种类型的资源的数量；选择用于部署调度域的业务节点，并向业务节点发送部署调度域的指令，指令包括调度域占用的每种类型的资源的数量；根据调度域的关联信息，向业务节点发送部署pod的指令，指令包括pod的数量，每个pod包括的容器的数量，用于pod使用资源的调度域的标识。不必再按照pod中每个容器在工作时使用的资源的最大值来为pod分配资源。多个pod均可以使用调度域中的资源，可以减少资源的浪费。

Description

一种部署pod的方法及装置
本申请要求于2019年11月26日提交中国国家知识产权局、申请号为201911172893.7、发明名称为“一种部署pod的方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及云计算技术领域，尤其涉及一种部署pod的方法及装置。
背景技术
各种虚拟机技术开启了云计算时代，而容器作为下一代虚拟化技术，正在逐渐兴起。容器是一个虚拟环境容器，可以看做一种轻量级的虚拟机，两者都可以对应用进行隔离。但容器不同于虚拟机，两者的主要区别在于：虚拟机依赖于虚拟机管理系统(Hypervisor)，利用Hypervisor，在主操作系统之上运行多个不同的从操作系统，每个从操作系统可以看作是一个虚拟机，而容器由容器引擎管理。虚拟机启动需要数分钟，而容器可以在数毫秒内启动。
目前，在容器编排领域，最流行的是kubernetes(K8S)容器集群管理系统(以下简称管理系统)。K8S可以构建容器的部署服务，pod是K8S的基本部署单位，一个pod由一组工作在同一节点的容器构成。
在现有技术中，管理人员向管理系统下发部署pod的指令，指令中可以包括：pod的数量，每个pod包含的容器的数量，每个容器在工作时使用的每种类型的资源的最大值等信息。以部署一个pod为例，说明为pod分配资源的方式：针对每种类型的资源，管理系统确定pod包含的多个容器在工作时使用该种类型的资源的最大值的和值，所述和值即pod使用该种类型的资源的理论资源值。管理系统挑选合适的业务节点部署pod，业务节点为部署的pod分配对应理论资源值的资源。例如一个pod包括两个容器，一个容器a在工作时，理论上最多使用2个cpu，另一容器b在工作时，理论上最多使用1个cpu，则业务节点为该pod分配3个cpu。如果两个容器在不同时间点使用资源，理论上业务节点为该pod分配2个cpu就足够容器a和容器b够用，则按照每个容器在工作时使用的资源的最大值来分配3个cpu，会造成资源浪费。
发明内容
本申请实施例提供一种部署pod的方法及装置，用以解决目前按照pod中每个容器在工作时使用的资源的最大值来为pod分配资源，而造成资源浪费的问题。
第一方面，提供了一种部署pod的方法，可以应用于管理节点。管理节点可以接收管理人员或租户或者用户下发的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用。然后，管理节点选择用于部署调度域的业务节点，并向所述业务节点发送部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量。管理节点接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息。进一步地，管理节点根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，所述指令包括pod的数量，每个pod 包括的容器的数量，以及用于所述pod使用资源的调度域的标识。需要注意的是，管理节点接收部署调度域的指令与接收部署pod的指令的先后顺序可以不限制。
通过先在业务节点上部署调度域，为pod预留一部分资源。进而，在部署pod时，使pod使用调度域中的资源，不必再按照pod中每个容器在工作时使用的资源的最大值来为pod分配资源。多个pod中的容器均可以使用调度域中的资源，从而减少资源的浪费。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值，保证能够支持所有的所述容器在不同时间点工作时的正常工作。以进一步减少资源浪费。
在一种可能的实现中，所述调度域的关联信息为调度域的标识或调度域的类型或业务节点的标识。则管理节点可以根据调度域的标识或调度域的类型或业务节点的标识，确定出部署pod的业务节点以及调度域。通过多种方式，可以灵活地确定出用于部署pod的业务节点以及调度域，提高体验效果。
在一种可能的实现中，管理节点在向所述业务节点发送部署调度域的指令之后，可以对资源列表中所述业务节点中每种类型的资源的剩余量进行更新，以及对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。以实现正确记录资源的使用情况，进一步提高资源利用率。
在一种可能的实现中，管理节点可以根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点；或者，管理节点接收到的部署调度域的指令中还包括业务节点的标识，管理节点可以将所述标识对应的业务节点作为用于部署调度域的业务节点。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；管理节点接收到的部署调度域的指令还可以包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量。管理节点接收的部署pod的指令也可以包括：与其它容器隔离使用cpu的第一容器标识。这样，业务节点将调度域中的对应数量的cpu分配给第一容器独享，第一容器与其它容器不会共享这些cpu，可以提高第一容器的性能。
在一种可能的实现中，管理节点可以接收删除调度域的指令，所述指令包括调度域的标识。然后管理节点确定是否存在pod使用所述标识的调度域中的资源；如果存在，则发出不能删除所述调度域的提示信息；如果不存在，则可以向部署所述调度域的业务节点发送删除所述调度域的指令。管理节点向业务节点发送的删除调度域的指令中包括待删除的调度域的标识。
第二方面，提供了一种部署pod的方法，可以应用于业务节点。业务节点可以接收管理节点发送的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，然后所述业务节点根据所述部署调度域的指令，部署所述调度域，部署的所述调度域中包括对应数量的对应类型的资源。业务节点还可以接收管理节点发送的部署pod的指令，所述部署pod的指令可以包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。然后业务节点可以部署对应数量的pod，每个pod包括对应数量的容器。并且业务节点控制任一所述容器在工作时使用所述调度域中的资源。
通过先在业务节点上部署调度域，为pod预留一部分资源。进而，在部署pod时，使pod使用调度域中的资源，不必再按照pod中每个容器在工作时使用的资源的最大值来为 pod分配资源。多个pod中的容器均可以使用调度域中的资源，从而减少资源的浪费。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值，保证能够支持所有的所述容器在不同时间点工作时的正常工作。以进一步减少资源量浪费。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；业务节点接收到的部署调度域的指令还可以包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量。业务节点接收的部署pod的指令也可以包括：与其它容器隔离使用cpu的第一容器标识。接而，所述业务节点控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。这样，业务节点将调度域中的对应数量的cpu分配给第一容器独享，第一容器与其它容器不会共享这些cpu，可以提高第一容器的性能。
第三方面，提供了一种部署pod的装置，所述通信具有实现上述第一方面及第一方面任一可能的实现中的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的功能模块。
第四方面，提供了一种部署pod的装置，所述通信具有实现上述第二方面及第二方面任一可能的实现中的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的功能模块。
第五方面，提供了一种部署pod的装置，该装置可以为上述方法实施例中的管理节点，或者为设置在管理节点中的芯片。该装置包括通信接口以及处理器，可选的，还包括存储器。其中，该存储器用于存储计算机程序或指令，处理器分别与存储器和通信接口耦合，当处理器执行所述计算机程序或指令时，使装置通过所述通信接口执行上述第一方面及第一方面任一可能的实现中由管理节点执行的方法。
第六方面，提供了一种部署pod的装置，该装置可以为上述方法实施例中的业务节点，或者为设置在业务节点中的芯片。该装置包括通信接口以及处理器，可选的，还包括存储器。其中，该存储器用于存储计算机程序或指令，处理器分别与存储器和通信接口耦合，当处理器执行所述计算机程序或指令时，使装置通过所述通信接口执行上述第二方面及第二方面任一可能的实现中由业务节点执行的方法。
第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面及第一方面任一可能的实现中由管理节点执行的方法。
第八方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面及第二方面任一可能的实现中由业务节点执行的方法。
第九方面，本申请提供了一种芯片系统，该芯片系统包括处理器和存储器，所述处理器、所述存储器之间电耦合；所述存储器，用于存储计算机程序指令；所述处理器，用于执行所述存储器中的部分或者全部计算机程序指令，当所述部分或者全部计算机程序指令被执行时，用于实现上述第一方面及第一方面任一可能的实现的方法中管理节点的功能。
在一种可能的设计中，所述芯片系统还可以包括通信接口，所述通信接口，用于发送 所述处理器处理后的信号，或者接收输入给所述处理器的信号。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十方面，本申请提供了一种芯片系统，该芯片系统包括处理器和存储器，所述处理器、所述存储器之间电耦合；所述存储器，用于存储计算机程序指令；所述处理器，用于执行所述存储器中的部分或者全部计算机程序指令，当所述部分或者全部计算机程序指令被执行时，用于实现上述第二方面及第二方面任一可能的实现的方法中业务节点的功能。
在一种可能的设计中，所述芯片系统还可以包括通信接口，所述通信接口，用于发送所述处理器处理后的信号，或者接收输入给所述处理器的信号。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十一方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序被运行时，上述第一方面及第一方面任一可能的实现中由管理节点执行的方法被执行。
第十二方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序被运行时，上述第一方面及第一方面任一可能的实现中由业务节点执行的方法被执行。
第十三方面，提供了一种部署pod的系统，所述系统包括：执行上述第一方面及第一方面任一可能的实现中的方法的管理节点，以及执行上述第二方面及第二方面任一可能的实现中的方法的业务节点。
附图说明
图1为本申请实施例中提供的一种云计算系统；
图2a、图2b、图2c分别为本申请实施例中提供的一种为pod分配资源的示意图；
图3为本申请实施例中提供的一种部署pod的流程示意图；
图4为本申请实施例中提供的一种部署调度域的流程示意图；
图5为本申请实施例中提供的一种部署pod的流程示意图；
图6、图7、图8、图9分别为本申请实施例中提供的一种部署pod的装置结构图。
具体实施方式
下面将结合附图，对本申请实施例进行详细描述。
为便于理解本申请实施例，以下对本申请实施例的部分用语进行解释说明，以便于本领域技术人员理解。
1)、k8s是基于docker的开元容器集群管理系统，可以构建一个容器的调度服务，目的是让用户通过k8s集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作。系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。其核心概念是容器仓(container pod)。一个pod由工作在同一工作节点上的一组容器构成。pod是k8s的最基本的部署单元，可以包括多个容器container，逻辑上标识某种应用的一个实例。如一个web应用由前端、后端和数据库三个组件构成，这三个组件运行在各自的容器中，针对这个实例可以常见包含三个container的pod。
2)调度域，又称资源集合，资源池等，可以包含各种类型的资源、例如cpu资源、存储资源(例如卷信息)、网络资源(例如网络空间)、内存资源(例如大页)。
本申请中的“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本申请中所涉及的多个，是指两个或两个以上。
在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
另外，在本申请实施例中，“示例的”一词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或实现方案不应被解释为比其它实施例或实现方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。
本申请实施例提供一种部署pod的方法及装置，其中，方法、装置是基于同一技术构思的，由于方法、装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。
本申请实施例的技术方案可以应用于各种云化的通信系统，例如：长期演进(long term evolution，LTE)系统，全球互联微波接入(worldwide interoperability for microwave access，WiMAX)通信系统，未来的第五代(5th Generation，5G)系统，如新一代无线接入技术(new radio access technology，NR)，及未来的通信系统等。
为便于理解本申请实施例，接下来对本请的应用场景进行介绍，本申请实施例描述的业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
如图1所示，包括管理节点(master node)和业务节点(worker node)。管理节点上可以部署容器云管理平台(manage platform)(以下简称管理系统)，例如云管理平台为k8s管理系统，该管理系统可以根据业务需求，选择合适的业务节点部署容器。
具体的，管理系统可以看作是对容器生命周期进行管理的一组进程。例如包括控制模块(controller)、调度模块(scheduler)、应用程序编程接口服务(application programming interface server，API server)模块等。这些进程实现了整个集群的资源管理、pod部署、系统建立等管理功能。
API server模块提供了资源对象的唯一操作入口，即为用户提供功能的接口模块，其他所有组件都必须通过其提供的API接口来操作资源数据，通过对相关的资源数据监听，完成相关的网元功能。
控制模块负责对各种容器模型的统一管控，例如对容器模型进行CRUD(增加Create、读取查询Read、更新Update和删除Delete)操作。容器模型例如可以指示以下信息中的一种或多种：pod中包括的容器的数量，容器中运行的应用程序的类型，容器在工作时使用的每种类型的资源的最大值，哪个容器需要独占cpu等信息。
调度模块负责为部署的单元(容器或pod)选择合适的业务节点。
在每个业务节点上运行有代理(agent)、容器引擎(container engine)等组件，负责对本节点上的pod的生命周期进行管理。例如agent组件负责业务节点上的pod的部署、修改、监控、删除等生命周期管理，同时负责定时向管理节点中的API server模块上报本节点的状态信息。容器引擎组件可以负责部署容器，容器引擎组件例如可以是Docker组件。
以管理系统为k8s为例进行说明，由于pod是k8s的基本部署单位，用户或者租户或 者管理人员可以根据业务需求，向管理系统下发部署pod的指令。指令中可以包括：pod的数量，每个pod包含的容器的数量，每个容器在工作时使用的每种类型的资源的最大值等信息。管理系统确定一个pod包含的多个容器在工作时使用每种类型的资源的最大值的和值，并挑选合适的业务节点部署pod。业务节点为部署的pod分配所述最大值的和值的资源。
以pod在工作时使用的cpu资源为例进行说明：业务节点在为pod分配cpu资源时，实际上是为pod分配cpu的使用时间。例如，业务节点为pod分配3个cpu，可以理解为业务节点为pod分配3个cpu的使用时间。
如图2a所示，业务节点上部署两个pod，分别为pod1和pod2，任一个pod包括两个容器，容器a1和a2在工作时，分别最多使用2个cpu，容器b1和b2在工作时，分别最多使用1个cpu，则业务节点为两个pod分别分配3个cpu。假设业务节点上包括11个cpu。
在一种示例中，业务节点为pod1分配3个cpu，分别为cpu1、cpu2和cpu3，并为pod2分配的3个cpu，分别为cpu4、cpu5和cpu6。容器使用为其分配的cpu全部的运行时间。在该示例中，业务节点为不同的pod分配的资源是相互隔离的，在任何时间，一个pod中的容器不能使用为其他pod分配的资源。即pod1中的容器不能使用为pod2分配的cpu4、cpu5和cpu6，容器a1可以使用为pod1分配的cpu1、cpu2和cpu3中的任意两个cpu，例如cpu1和cpu2，容器b1可以使用pod1分配的cpu1、cpu2和cpu3中的任意一个cpu，例如cpu1或cpu2或cpu3。同理，pod2中的容器不能使用为pod1分配的cpu1、cpu2和cpu3，容器a2可以使用为pod2分配的cpu4、cpu5和cpu6中的任意两个cpu，容器b2可以使用pod2分配的cpu4、cpu5和cpu6中的任意一个cpu。
在另一种示例中，业务节点为不同的pod分配的资源在物理上是共享的，不同的pod使用该共享的资源的时间不同。具体的，业务节点可以指定pod1能够使用的cpu组，该cpu组中包括的cpu的数量等于pod1需要的cpu的最大数量。例如业务节点为pod分配cpu1-cpu6，并且还可以指示pod1分别使用cpu1至cpu6的运行时间的50％，6个50％即为300％，也就是pod1使用cpu的时间为300％，即为pod1分配了3个cpu。同理，业务节点可以指示pod2在另外的50％的时间里使用cpu1-cpu6，也相当于为pod2分配了3个cpu。
在实际应用中，由于一个pod中不同的容器中运行的应用不同，则一个pod中的多个容器的工作时间可能是不同的。这样，在一个pod中的至少两个容器在不同时间点使用资源时，按照每个容器在工作时使用的资源的最大值为pod分配资源，则会造成资源浪费。另外，一个pod中的多个容器在工作时，一般不会使用所述最大值的资源。并且，即使某一个pod中的容器在工作时使用的资源达到最大值，一般也不会存在多个pod中容器均达到最大值。则以上按照每个容器在工作时使用的资源的最大值来为pod分配资源分配，会造成资源浪费。
有鉴于此，本申请提出了在业务节点上部署调度域的方案，调度域可以看作是一个资源集合，可以包括多种类型的资源，例如包括计算资源、内存资源、网络带宽资源、磁盘资源等。调度域中的资源可以由一个pod或多个pod中的容器使用。这样，多个pod中的容器可以使用同一个资源集合中的资源，可以提高资源利用率。例如图2b所示，在图2a的基础上，业务节点部署调度域1，调度域1占用cpu1-cpu5，pod1和pod2中的容器一般会在不同时间点工作，pod1和pod2中的容器在工作时均可以使用调度域1中的cpu资源。
在提出部署调度的方案的基础上，图1所示的管理节点和业务节点中也应增加关于调度域的相关功能。
例如，管理节点上可以设置支持调度域的CRUD接口，例如将该接口定义为1F1接口，该接口可以执行CRUD指令。管理节点中的控制模块还可以负责各种调度域模型的统一管控，为了方便描述，可以将这部分功能定义为控制子模块。调度域模型可以指示调度域的资源信息，例如占用的资源类型，每种类型的资源占用多少数量。调度域模型还可以指示调度域中的资源为哪些类型的应用程序所使用等信息。管理节点中的调度模块还可以为即将部署的调度域选择合适的业务节点，为了方便描述，可以将这部分功能定义为调度子模块。进一步地，为了使即将部署的pod亲和到对应的调度域上，容器模型还可以指示该pod模型亲和的调度域模型。
再例如，业务节点中的代理agent组件还可以负责调度域中资源的管控，例如预留资源或者释放资源等。代理组件例如可以包括kunelet组件。
接下来，如图3所示，以一个具体的示例详细说明，在结合调度域的基础上部署pod的流程。
步骤301：管理节点接收部署调度域的指令，所述部署调度域的指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用。
当用户有部署pod的需求时，可以向管理系统请求部署调度域，以便为后续部署的pod预留资源。用户在部署调度域时，例如可以是在管理系统的显示界面上执行新建调度域的指令，也可以是描述一个创建调度域的文件。相应的，管理系统所在的管理节点可以接收到部署调度域的指令。在部署调度域时，可能会在一个指令中指示部署多个调度域，管理节点针对每个调度域的部署方式是相同的。在本申请中，以部署一个调度域为例进行说明。
一般在部署调度域时，还可以指定部署的该调度域占用的每种类型的资源的数量。例如cpu的数量、网络带宽的带宽值，磁盘的数量、内存占用多少兆等。
用户在部署调度域时，可以定义调度域的关联信息，则管理节点接收到的部署调度域的指令中还可以包括待部署的调度域的关联信息。该关联信息可以是调度域的标识，或者调度域的类型、或者业务节点的标识等。
在一种示例中，调度域的资源信息可以是用户在管理系统中输入或者选择的，即用户指示调度域占用的每种类型的资源的数量。
在另一种示例中，用户或者管理人员或者租户在设置调度域模型时，可以为调度域模型定义资源信息。管理节点接收到的部署调度域的指令为针对某一调度域模型，指示采用该调度域模型创建多少个调度域。则该部署调度域的指令中包括调度域占用的资源信息。
进一步地，在设置调度域模型时，如果还定了调度域模型名称，此处的调度域模型名称则可以理解为调度域的类型。则部署调度域的指令中的调度域的管理信息中还可以包括调度域的类型。
为了进一步提高资源利用率，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值，保证能够支持所有的所述容器在不同时间点工作时的正常工作。
步骤302：管理节点选择用于部署调度域的业务节点，并向所述业务节点发送部署调度域的指令，相应的，业务节点接收管理节点发送的部署调度域的指令，所述部署调度域 的指令包括调度域占用的每种类型的资源的数量。
管理节点管理着多个业务节点，管理节点在接收到部署调度域的指令后，可以在多个业务节点中选择合适的业务节点来部署调度域。在选择出合适的业务节点后，可以控制该业务节点部署对应的调度域。
在选择用于部署调度域的业务节点时，可以是管理节点根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点。或者，也可以是用户在向管理节点下发部署调度域的指令时，指示部署该调度域的业务节点的标识，也就是管理节点接收到的部署调度域的指令中还包括业务节点的标识。管理节点可以将所述标识对应的业务节点作为用于部署调度域的业务节点。
管理节点在合适的业务节点上部署调度域后，管理节点可以保存调度域的标识以及业务节点的标识对应关系。进一步，还可以保存调度域的标识，调度域的类型，以及业务节点的标识的对应关系。
步骤303：业务节点部署所述调度域，所述调度域包括所述指令中的对应数量的对应类型的资源。
可选的，业务节点在部署所述调度域后，可以向管理节点反馈部署成功的响应消息。
当然也存在业务节点资源不足的情况，例如管理节点接收到的部署调度域的指令中包括业务节点的标识，则管理节点在所述标识对应的业务节点上部署调度域。在该情况下，指定的业务节点可能会存在资源不足的情况，则该业务节点可以向管理节点反馈部署失败的响应消息。相应的，管理节点接收部署失败的响应消息，再选择合适的节点部署调度域，直至部署成功。
在一个示例中，管理节点可以针对所有的业务节点，维护一个资源列表。管理节点在向所述业务节点发送部署调度域的指令之后，管理节点还可以对资源列表中所述业务节点中每种类型的资源的剩余量进行更新。并且管理节点还可以对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。
以上介绍了调度域被部署到业务节点上的过程。接下来介绍在基于调度域的基础上，部署pod的过程。
步骤304：管理节点接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息。
用户或者管理人员或者租户，可以向管理系统发送部署pod的指令，所述部署pod指令可以包括pod的数量，每个pod包括的容器的数量。由于管理系统已经部署有调度域。则部署pod的指令中可以包括调度域的关联信息，以便管理系统找到合适的调度域，用于待部署的pod使用其中的资源。
在一种示例中，每个pod中包括的容器的数量可以是用户在管理系统中输入或选择的，即用户指示pod中包括的容器的数量。
在另一种示例中，用户或者管理人员或者租户在设置容器模型时，可以为容器模型定义pod中包括的容器的数量。管理节点接收到的部署pod的指令为针对某一容器模型，指示采用该容器模型创建多少个pod。
进一步地，在设置容器模型时，还可以定义调度域的类型，也就是调度域模型名称。通过调度域类型指示部署的pod使用哪个类型的调度域中的资源。
需要注意的是，上述步骤304与步骤301的先后顺序不限。
步骤305：管理节点根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，相应的，业务节点接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。
管理节点可以根据所述调度域的关联信息，找到用于部署pod的业务节点，并确定出该业务节点上的哪个调度域中的资源可以用于待部署的pod使用。
在根据所述调度域的关联信息，找到用于部署pod的业务节点时，例如，调度域的关联信息可以包括业务节点的标识，则管理节点可以将该标识的业务节点作为部署pod的业务节点。管理节点在该业务节点上选择合适的调度域为待部署的pod使用。再例如，调度域的关联信息可以包括调度域的类型，管理节点可以根据预先保存的调度域的类型与业务节点的标识的对应关系，识别出业务节点，将识别出的业务节点作为部署pod的业务节点。再例如，调度域的关联信息包括调度域的标识，管理节点可以根据预先保存的调度域的标识与业务节点的标识的对应关系，识别出部署pod的业务节点。
在确定业务节点上的哪个调度域中的资源可以用于待部署的pod使用时，如果调度域的关联信息中未对调度域的类型以及调度域的标识做限制，则可以在业务节点上选择任一调度域，用于pod使用。如果调度域的关联信息中限制了调度域的类型，则可以在业务节点选择对应的类型的任一调度域用于pod使用。如果调度域的关联信息中限制了调度域的标识，则可以将业务节点中的所述标识的调度域用于pod使用。
进一步地，管理节点上可以保存调度域的标识与pod的标识的对应关系。
步骤306：业务节点创建对应数量的pod，每个pod包括对应数量的容器；业务节点控制任一所述容器在工作时使用所述标识的调度域中的资源。
在图3所示实施例中，通过先在业务节点上部署调度域，为pod预留一部分资源。进而，在部署pod时，使pod使用调度域中的资源。业务节点不必再按照pod中每个容器在工作时使用的资源的最大值的和值来为pod分配资源。多个pod中的容器可以在不同时间点使用调度域中的资源，从而减少资源的浪费。
多个pod中的容器运行的应用的性能要求不尽相同，有的性能要求高，有的性能要求低。进一步地，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；
在一示例中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；业务节点接收到的部署调度域的指令还可以包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量。业务节点接收的部署pod的指令也可以包括：与其它容器隔离使用cpu的第一容器标识。进而，所述业务节点控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。用于容器隔离使用资源可以理解为业务节点将该资源分配给一个容器单独使用，其他容器不能使用。用于容器共享使用的资源可以理解为业务节点将该资源分配给多个容器使用，该多个容器可以在相同的时间点，或不同的时间点使用该资源。
这样，业务节点将调度域中的对应数量的cpu分配给第一容器独享，第一容器与其它容器不会共享这些cpu，可以提高第一容器的性能。
如图2c所示，在图2b的基础上，部署调度域的指令中包括的用于pod中的容器隔离使用的cpu的数量为2，并且指示pod1中的容器a1与其他容器隔离使用cpu，以及pod2中的容器a2与其他容器隔离使用cpu。业务节点可以根据指示，为容器a1分配cpu1，为 容器分配cpu5。进而，业务节点控制pod1中的容器a1在工作时使用cpu1，pod2中的容器a2在工作时使用cpu5，cpu1和cpu5不能被其他容器使用。业务节点可以控制容器b1和容器b2在工作时使用cpu2、cpu3和cpu4中任一个或多个。
接下来结合前述介绍的管理节点中API server接口模块、调度模块(包括调度子模块)、控制模块(包括控制子模块)，以及业务节点中的agent组件，容器引擎组件等，对图3所示实施例中的细节进一步地描述。
如图4所示，提供了一种部署调度域的流程。
上述步骤301的具体过程可以参见图4所示的步骤41：用户可以调用API server接口模块下发部署调度域的指令，该部署调度域的指令中包括调度域的数量，调度域的资源信息，即调度域占用的每种类型的资源的数量。
上述步骤302的具体过程可以参见图4所示的步骤42-步骤46：
步骤42：管理节点中的控制模块中的控制子模块可以关注API server模块是否接收到部署调度域的指令。
步骤43：如果控制子模块确定API server模块接收到部署调度域的指令，可以获取所述部署调度域的指令中的内容，例如部署的调度域的数量，以及每个调度域占用的资源信息。进一步地，控制子模块将该指令中的内容通过API server模块保存至数据库，例如storage db。
步骤44：管理节点中的调度模块中的调度子模块可以关注API server模块是否接收到部署调度域的指令，也就是确定是否存在调度域需要部署。如果调度子模块确定API server模块接收到部署调度域的指令，可以请求API server访问数据库，将需要部署的调度域的信息告知调度子模块。
步骤45：调度子模块如果确定存在待部署的调度域，则可以为该待部署的调度域选择合适的业务节点，并将选择的业务节点的标识告知API server模块。
步骤46：API server模块可以向业务节点中的agent组件发送部署调度域的指令，相应的，agent组件接收部署调度域的指令，该部署调度域的指令中指示调度域的占用的资源信息，还可以指示调度域的标识等。
在一种示例中，agent组件可以向API server模块订阅自身业务节点的状态信息，当API server模块要对业务节点的状态更新时，可以通知给业务节点的agent组件。状态更新例如在业务节点上部署调度域。具体的，当有调度域要部署到业务节点上时，API server模块主动向业务节点的agent组件发送部署调度域的指令。
上述步骤303的具体过程可以参见图4中的步骤47：agent组件根据部署调度域指令，部署对应的调度域。
agent根据部署调度域指令中的资源信息，对资源进行预留，例如包括cpu、内存等资源。并为对应的调度域分配对应的资源。
agent还可以为调度域创建配置信息，例如，创建资源对应的目录，并创建资源相关约束，即为调度域分配的资源有哪些，还可以创建网络命名空间等。
如图4所示，提供了一种部署调度域的流程。
上述步骤304的具体过程可以参见图5所示的步骤51：用户可以调用API server接口模块下发部署pod的指令，该部署pod的指令中包括pod的数量，每个pod包括的容器的数量，还可以包括调度域的关联信息。
上述步骤35的具体过程可以参加图5所示的步骤52-步骤56：
步骤52：管理节点中的控制模块可以关注API server模块是否接收到部署pod的指令。
步骤53：如果控制模块确定API server模块接收到部署pod的指令，可以获取部署pod的指令中的内容息，即待部署的pod的数量，以及调度域的关联信息。进一步地，控制模块通过API server模块将该指令中的内容保存到数据库。
步骤54：管理节点中的调度模块可以关注API server模块是否接收到部署pod的指令，也就是确定是否存在pod需要部署。如果调度模块确定API server模块接收到部署pod的指令，可以请求API server访问数据库，将需要部署的pod的信息告知调度模块。
步骤55：调度模块如果确定存在待部署的pod，则可以根据调度域的关联信息选择合适的业务节点，并将选择的业务节点的标识告知API server模块。
步骤56：API server模块向选择的业务节点上的agent组件发送部署pod的指令，相应的，agent组件接收部署pod的指令，该指令中指示pod的数量，pod包括的容器的数量，还可以指示调度域的标识等。
在一种示例中，agent组件可以向API server模块订阅自身业务节点的状态信息，当API server模块要对业务节点的状态更新时，可以通知给业务节点的agent组件。状态更新例如在业务节点上部署pod。具体的，当有pod要部署到业务节点上时，API server模块主动向业务节点上的agent组件发送部署pod的指令。
上述步骤306的具体过程可以参见图5中的步骤57：agent组件将创建pod的指令告知容器引擎组件，容器引擎组件根据指令部署对应的pod。
Agent组件还可以为pod创建配置信息，例如，创建资源对应的目录，并创建资源相关约束，即使用哪个调度域中的资源，还可以创建网络命名空间等。
在一个示例中，用户还可以根据业务需求，请求删除pod。例如可以是管理节点接收删除pod的指令，所述删除pod的指令中包括pod的标识。管理节点根据保存的pod的标识与业务节点的标识的对应关系，确定部署该标识的pod的业务节点。并向所述业务节点发送删除pod的指令，相应的，业务节点接收管理节点发送的删除pod的指令，所述删除pod的指令中包括pod的标识，业务节点可以将所述标识的pod删除。由此可以说明，一个调度域中的资源可以同时用于多个pod使用。如果因为业务需求，其中一个pod被删除，则该调度域中的资源会有闲置。此时，如果有用户需要部署pod，管理节点可以根据调度域中的资源，以及使用该资源的pod的情况，为待部署的pod选则合适的调度域，以避免资源浪费。
在一个示例中，用户还可以根据业务需求，请求删除调度域。例如可以是管理节点接收删除调度域的指令，所述指令包括调度域的标识；管理节点可以确定是否存在pod使用所述标识的调度域中的资源；如果是，则不能删除该标识的调度域，此时可以发出不能删除所述调度域的提示信息；如果不存在pod使用所述标识的调度域中的资源，则向部署所述调度域的业务节点发送删除所述调度域的指令，相应的，业务节点接收删除所述标识的调度域的指令。业务节点可以执行该指令，删除所述标识的调度域，即释放调度域中的资源。
在另一种示例中，也可以由业务节点来确定是否存在pod使用所述标识的调度域中的资源，例如管理节点接收删除调度域的指令，所述删除调度域的指令中包括调度域的标识，管理节点向业务节点发送所述删除调度域的指令，相应的，业务节点接收所述删除调度域 的指令。业务节点确定是否存在pod使用所述标识的调度域中的资源；如果是，则不能删除该标识的调度域，此时业务节点可以向管理节点反馈不能删除所述调度域的信息；如果不存在pod使用所述标识的调度域中的资源，则业务节点执行该指令，删除所述标识的调度域，还可以向管理节点反馈删除成功。
前文结合介绍的本申请实施例的部署pod的方法，下文中将介绍本申请实施例中的装置。基于与上述部署pod的方法的同一技术构思，如图6所示，提供了一种部署pod的装置600，部署pod的装置600能够执行上述图3的方法中由管理节点执行的各个步骤，为了避免重复，此处不再详述。部署pod的装置600可以为管理节点，也可以为应用于管理节点中的芯片。部署pod的装置600可以包括：收发模块620，处理模块610，可选的，还包括存储模块630；处理模块610可以分别与存储模块630和收发模块620相连，所述存储模块630也可以与收发模块620相连；
收发模块620，用于接收部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用；
处理模块610，用于选择用于部署调度域的业务节点；
收发模块620，还用于向所述业务节点发送部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；以及接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息；并根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
在一种可能的实现中，所述调度域的关联信息为调度域的标识或调度域的类型或业务节点的标识。
在一种可能的实现中，所述处理模块610，还用于对资源列表中所述业务节点中每种类型的资源的剩余量进行更新，以及对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。
在一种可能的实现中，所述存储模块630，可以用于存储资源池中每种类型的资源的剩余量，和/或业务节点中每种类型的资源的剩余量。
在一种可能的实现中，所述处理模块610，在用于选择用于部署调度域的业务节点时，具体用于：根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点；或者，接收到的部署调度域的指令中还包括业务节点的标识，将所述标识对应的业务节点作为用于部署调度域的业务节点。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识。
在一种可能的实现中，所述收发模块620，还用于接收删除调度域的指令，所述指令包括调度域的标识；所述处理模块610，还用于确定是否存在pod使用所述标识的调度域中的资源；如果是，则发出不能删除所述调度域的提示信息；如果否，则通过所述收发模 块向部署所述调度域的业务节点发送删除所述调度域的指令。
在一种可能的实现中，所述存储模块630可以用于存储业务节点的标识，业务节点上部署的调度域的标识和/或类型的对应关系。还可以存储业务节点的标识，以及业务节点上部署的pod的标识。还可以存储pod的标识，以及pod使用的资源所属的调度域的标识。
图6所示的处理模块610可以包括上述图4中的控制模块和调度模块的功能。
图6所示的收发模块620可以包括上述图4中的API server模块的功能。
如图7所示，提供了一种部署pod的装置700，部署pod的装置700能够执行上述图3的方法中由业务节点执行的各个步骤，为了避免重复，此处不再详述。部署pod的装置700可以为业务节点，也可以为应用于业务节点中的芯片。部署pod的装置700可以包括：收发模块720，处理模块710，可选的，还包括存储模块730；处理模块710可以分别与存储模块730和收发模块720相连，所述存储模块730也可以与收发模块720相连；
所述收发模块720，用于接收管理节点发送的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；
所述处理模块710，用于部署所述调度域，所述调度域中包括对应数量的对应类型的资源；
所述收发模块720，还用于接收管理节点发送的部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识；
所述处理模块710，还用于部署对应数量的pod，每个pod包括对应数量的容器；并控制任一所述容器在工作时使用所述调度域中的资源。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识；所述处理模块710，在用于控制任一所述容器在工作时使用所述调度域中的资源时，具体用于：控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。
在一种可能的实现中，所述存储模块730可以用于存储pod的标识以及该标识的pod使用的资源所属的调度域的标识。
图7所示的处理模块710可以包括图5所示的容器引擎组件的功能以及agent组件中除收发信号外的其它功能。
图7所示的收发模块720可以包括图5所示agent组件中收发信号外的功能。
图8是本申请实施例的部署pod的装置800的示意性框图。应理解，所述部署pod的装置800能够执行图3所示的方法中由管理节点执行的各个步骤，为了避免重复，此处不再详述。部署pod的装置800包括：处理器810和通信接口820，可选的，还包括存储器830，所述处理器810和所述存储器830之间电偶合；
示例的，存储器830，用于存储计算机程序；所述处理器810，可以用于调用所述存储器中存储的计算机程序或指令，以通过所述通信接口820接收部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用；以及选择用于部署调度域的业务节点；并通过所述通信接口820向所述业务节点发送部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；以及接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息；并根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
在一种可能的实现中，所述调度域的关联信息为调度域的标识或调度域的类型或业务节点的标识。
在一种可能的实现中，所述处理器810，还用于对资源列表中所述业务节点中每种类型的资源的剩余量进行更新，以及对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。
在一种可能的实现中，所述存储器830，可以用于存储资源池中每种类型的资源的剩余量，和/或业务节点中每种类型的资源的剩余量。
在一种可能的实现中，所述处理器810，在用于选择用于部署调度域的业务节点时，具体用于：根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点；或者，接收到的部署调度域的指令中还包括业务节点的标识，将所述标识对应的业务节点作为用于部署调度域的业务节点。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识。
在一种可能的实现中，所述通信接口820，还用于接收删除调度域的指令，所述指令包括调度域的标识；所述处理器810，还用于确定是否存在pod使用所述标识的调度域中的资源；如果是，则发出不能删除所述调度域的提示信息；如果否，则通过所述收发模块向部署所述调度域的业务节点发送删除所述调度域的指令。
在一种可能的实现中，所述存储器830可以用于存储业务节点的标识，业务节点上部署的调度域的标识和/或类型的对应关系。还可以存储业务节点的标识，以及业务节点上部署的pod的标识。还可以存储pod的标识，以及pod使用的资源所属的调度域的标识。
图8所示的处理器810可以包括上述图4中的控制模块和调度模块的功能。
图8所示的通信接口820可以包括上述图4中的API server模块的功能。
图9是本申请实施例的部署pod的装置900的示意性框图。应理解，所述部署pod的装置900能够执行图3所示的方法中由业务节点执行的各个步骤，为了避免重复，此处不再详述。部署pod的装置900包括：处理器910和通信接口920，可选的，还包括存储器930，所述处理器910和所述存储器930之间电偶合；
示例的，存储器930，用于存储计算机程序；所述处理器910，可以用于调用所述存储器中存储的计算机程序或指令，以通过所述通信接口920接收管理节点发送的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；还可以用于部署所述调度域，所述调度域中包括对应数量的对应类型的资源；还可以通过所述通信接口920接收管理节点发送的部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识；还可以部署对应数量的pod，每个pod包括对应数量的容器；并控制任一所述容器在工作时使用所述调度域中的资源。
在一种可能的实现中，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
在一种可能的实现中，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识；所述处理器910，在用于控制任一所述容器在工作时使用所述调度域中的资源时，具体用于：控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。
在一种可能的实现中，所述存储器930可以用于存储pod的标识以及该标识的pod使用的资源所属的调度域的标识。
图9所示的处理器910可以包括图5所示的容器引擎组件的功能以及agent组件中除收发信号外的其它功能。
图9所示的通信接口920可以包括图5所示agent组件中收发信号外的功能。
上述的处理器可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。处理器还可以进一步包括硬件芯片或其他通用处理器。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic，GAL)及其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等或其任意组合。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器 (Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。应注意，本申请描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例还提供了一种计算机存储介质，存储有计算机程序，该计算机程序被计算机执行时，可以使得所述计算机用于执行上述部署pod的方法。
本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述提供的部署pod的方法。
本申请实施例还提供了一种部署pod的系统，所述系统包括：执行上述部署pod的方法的管理节点和业务节点。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包括有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包括这些改动和变型在内。

Claims (26)

  1. 一种部署pod的方法，其特征在于，所述方法包括：
    管理节点接收部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用；
    管理节点选择用于部署调度域的业务节点，并向所述业务节点发送部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；
    管理节点接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息；
    管理节点根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。
  2. 如权利要求1所述的方法，其特征在于，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
  3. 如权利要求1或2所述的方法，其特征在于，所述调度域的关联信息为调度域的标识或调度域的类型或业务节点的标识。
  4. 如权利要求1-3任一项所述的方法，其特征在于，管理节点在向所述业务节点发送部署调度域的指令之后，还包括：
    管理节点对资源列表中所述业务节点中每种类型的资源的剩余量进行更新，以及对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。
  5. 如权利要求1-4任一项所述的方法，其特征在于，管理节点选择用于部署调度域的业务节点，包括：
    管理节点根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点；或者，
    管理节点接收到的部署调度域的指令中还包括业务节点的标识，管理节点将所述标识对应的业务节点作为用于部署调度域的业务节点。
  6. 如权利要求1-5任一项所述的方法，其特征在于，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；
    所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；
    所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识。
  7. 如权利要求1-6任一项所述的方法，其特征在于，还包括：
    管理节点接收删除调度域的指令，所述指令包括调度域的标识；
    管理节点确定是否存在pod使用所述标识的调度域中的资源；
    如果是，则发出不能删除所述调度域的提示信息；
    如果否，则向部署所述调度域的业务节点发送删除所述调度域的指令。
  8. 一种部署pod的方法，其特征在于，所述方法包括：
    业务节点接收管理节点发送的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；并部署所述调度域，所述调度域中包括对应数量的对应类型的资源；
    业务节点接收管理节点发送的部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识；
    业务节点部署对应数量的pod，每个pod包括对应数量的容器；业务节点控制任一所述容器在工作时使用所述调度域中的资源。
  9. 如权利要求8所述的方法，其特征在于，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
  10. 如权利要求8或9所述的方法，其特征在于，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；
    所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；
    所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识；
    所述业务节点控制任一所述容器在工作时使用所述调度域中的资源，包括：
    所述业务节点控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。
  11. 一种部署pod的装置，其特征在于，所述装置包括：
    收发模块，用于接收部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量，所述调度域占用的资源用于至少一个pod使用；
    处理模块，用于选择用于部署调度域的业务节点；
    收发模块，还用于向所述业务节点发送部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；以及接收部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及调度域的关联信息；并根据所述调度域的关联信息，向所述业务节点发送部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识。
  12. 如权利要求11所述的装置，其特征在于，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
  13. 如权利要求11或12所述的装置，其特征在于，所述调度域的关联信息为调度域的标识或调度域的类型或业务节点的标识。
  14. 如权利要求11-13任一项所述的装置，其特征在于，所述处理模块，还用于对资源列表中所述业务节点中每种类型的资源的剩余量进行更新，以及对资源池中每种类型的资源的剩余量进行更新，资源池中包括多个业务节点。
  15. 如权利要求11-14任一项所述的装置，其特征在于，所述处理模块，在用于选择用于部署调度域的业务节点时，具体用于：
    根据资源最优策略，在多个业务节点中选择用于部署调度域的业务节点；或者，
    接收到的部署调度域的指令中还包括业务节点的标识，将所述标识对应的业务节点作为用于部署调度域的业务节点。
  16. 如权利要求11-15任一项所述的装置，其特征在于，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；
    所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；
    所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识。
  17. 如权利要求11-16任一项所述的装置，其特征在于，所述收发模块，还用于接收删除调度域的指令，所述指令包括调度域的标识；
    所述处理模块，还用于确定是否存在pod使用所述标识的调度域中的资源；如果是，则发出不能删除所述调度域的提示信息；如果否，则通过所述收发模块向部署所述调度域的业务节点发送删除所述调度域的指令。
  18. 一种部署pod的装置，其特征在于，所述装置包括：
    收发模块，用于接收管理节点发送的部署调度域的指令，所述指令包括调度域占用的每种类型的资源的数量；
    处理模块，用于部署所述调度域，所述调度域中包括对应数量的对应类型的资源；
    所述收发模块，还用于接收管理节点发送的部署pod的指令，所述指令包括pod的数量，每个pod包括的容器的数量，以及用于所述pod使用资源的调度域的标识；
    所述处理模块，还用于部署对应数量的pod，每个pod包括对应数量的容器；并控制任一所述容器在工作时使用所述调度域中的资源。
  19. 如权利要求18所述的装置，其特征在于，针对所述用于所述pod使用的调度域占用的任一类型的资源，该资源的数量小于所有的所述容器在工作时需要该类型的资源的最大值的和值，且不小于任一所述容器在工作时需要该类型的资源的最大值。
  20. 如权利要求18或19所述的装置，其特征在于，如果调度域占用的每种类型的资源的数量包括调度域占用的cpu的数量；
    所述部署调度域的指令还包括：用于pod中的容器隔离使用的cpu的数量和/或用于pod中的容器共享使用的cpu的数量；
    所述部署pod的指令还包括：与其它容器隔离使用cpu的第一容器的标识；
    所述处理模块，在用于控制任一所述容器在工作时使用所述调度域中的资源时，具体用于：
    控制所述第一容器在工作时使用所述调度域中的用于隔离使用的cpu，并控制第一容器外的其它容器在工作时使用所述调度域中除了用于隔离使用的cpu的其它cpu。
  21. 一种部署pod的装置，其特征在于，包括处理器、存储器和通信接口；
    所述存储器存储有计算机程序或指令；
    所述通信接口用于接收和/或发送信号；
    所述处理器在执行所述计算机程序或指令时，使得所述装置执行如权利要求1-7中任一项所述的方法。
  22. 一种部署pod的装置，其特征在于，包括处理器、存储器和通信接口；
    所述存储器存储有计算机程序或指令；
    所述通信接口用于接收和/或发送信号；
    所述处理器在执行所述计算机程序或指令时，使得所述装置执行如权利要求8-10中任一项所述的方法。
  23. 一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如权利要求1-7中任一项所述的方法。
  24. 一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如权利要求8-10中任一项所述的方法。
  25. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如权利要求1-7中任一项所述的方法。
  26. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如权利要求8-10中任一项所述的方法。
PCT/CN2020/107865 2019-11-26 2020-08-07 一种部署pod的方法及装置 WO2021103646A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20893282.2A EP4057139A4 (en) 2019-11-26 2020-08-07 POD DEPLOYMENT METHOD AND APPARATUS
US17/752,102 US20220283846A1 (en) 2019-11-26 2022-05-24 Pod deployment method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911172893.7 2019-11-26
CN201911172893.7A CN112948050A (zh) 2019-11-26 2019-11-26 一种部署pod的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/752,102 Continuation US20220283846A1 (en) 2019-11-26 2022-05-24 Pod deployment method and apparatus

Publications (1)

Publication Number Publication Date
WO2021103646A1 true WO2021103646A1 (zh) 2021-06-03

Family

ID=76129950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/107865 WO2021103646A1 (zh) 2019-11-26 2020-08-07 一种部署pod的方法及装置

Country Status (4)

Country Link
US (1) US20220283846A1 (zh)
EP (1) EP4057139A4 (zh)
CN (1) CN112948050A (zh)
WO (1) WO2021103646A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024036940A1 (zh) * 2022-08-16 2024-02-22 华为云计算技术有限公司 一种容器管理方法及相关设备
CN115145695B (zh) * 2022-08-30 2022-12-06 浙江大华技术股份有限公司 资源调度方法、装置、计算机设备和存储介质
CN117687739A (zh) * 2022-09-05 2024-03-12 华为云计算技术有限公司 资源调度方法及其相关设备
CN117009060B (zh) * 2023-09-27 2024-01-12 腾讯科技（深圳）有限公司 资源调度方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101354663A (zh) * 2007-07-25 2009-01-28 联想(北京)有限公司 应用于虚拟机系统的真实cpu资源的调度方法及调度装置
US8255915B1 (en) * 2006-10-31 2012-08-28 Hewlett-Packard Development Company, L.P. Workload management for computer system with container hierarchy and workload-group policies
CN105224392A (zh) * 2015-10-13 2016-01-06 中国联合网络通信集团有限公司 一种虚拟计算资源配额管理方法及平台
CN109471725A (zh) * 2018-10-24 2019-03-15 新华三大数据技术有限公司 资源分配方法、装置和服务器
CN110287029A (zh) * 2019-06-27 2019-09-27 中国—东盟信息港股份有限公司 一种基于kubernetes容器资源动态调整的方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255915B1 (en) * 2006-10-31 2012-08-28 Hewlett-Packard Development Company, L.P. Workload management for computer system with container hierarchy and workload-group policies
CN101354663A (zh) * 2007-07-25 2009-01-28 联想(北京)有限公司 应用于虚拟机系统的真实cpu资源的调度方法及调度装置
CN105224392A (zh) * 2015-10-13 2016-01-06 中国联合网络通信集团有限公司 一种虚拟计算资源配额管理方法及平台
CN109471725A (zh) * 2018-10-24 2019-03-15 新华三大数据技术有限公司 资源分配方法、装置和服务器
CN110287029A (zh) * 2019-06-27 2019-09-27 中国—东盟信息港股份有限公司 一种基于kubernetes容器资源动态调整的方法

Also Published As

Publication number Publication date
US20220283846A1 (en) 2022-09-08
CN112948050A (zh) 2021-06-11
EP4057139A1 (en) 2022-09-14
EP4057139A4 (en) 2022-12-14

Similar Documents

Publication Publication Date Title
WO2021103646A1 (zh) 一种部署pod的方法及装置
EP3761170B1 (en) Virtual machine creation method and apparatus
WO2020001320A1 (zh) 一种资源分配方法、装置及设备
CN110941481A (zh) 资源调度方法、装置及系统
CN113296792B (zh) 存储方法、装置、设备、存储介质和系统
US20170024251A1 (en) Scheduling method and apparatus for distributed computing system
JP2013513174A (ja) 仮想マシンのストレージスペースおよび物理ホストを管理するための方法およびシステム
US9092272B2 (en) Preparing parallel tasks to use a synchronization register
US20230266999A1 (en) Resource scheduling method, resource scheduling system, and device
CN114138434B (zh) 一种大数据任务调度系统
CN109992373B (zh) 资源调度方法、信息管理方法和装置及任务部署系统
WO2017181829A1 (zh) 虚拟化平台的运行方法及虚拟化平台
KR20220070020A (ko) 네트워크 자원 관리 방법, 시스템, 네트워크 디바이스 및 판독 가능한 저장 매체
CN114518955A (zh) 一种基于kubernetes的Flink云原生部署架构方法及系统
JP2024501005A (ja) コンテナクラスタのための管理方法および装置
US20230037293A1 (en) Systems and methods of hybrid centralized distributive scheduling on shared physical hosts
CN116954816A (zh) 容器集群控制方法、装置、设备及计算机存储介质
CN115987872A (zh) 一种基于资源路由的云系统
CN110399206B (zh) 一种基于云计算环境下idc虚拟化调度节能系统
WO2021057405A1 (zh) 资源共享方法及装置
CN102681881B (zh) 跨机调度方法及其系统
CN113127186B (zh) 配置集群节点资源的方法、装置、服务器和存储介质
CN116720179B (zh) Api接口管理方法、终端设备及计算机可读存储介质
KR20190061241A (ko) 리소스 통합관리를 위한 메소스 처리 장치 및 방법
EP4345615A1 (en) Storage resource management method, apparatus, and system for container cluster

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20893282

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020893282

Country of ref document: EP

Effective date: 20220607

NENP Non-entry into the national phase

Ref country code: DE