Pod deployment method, electronic device, and storage medium

Abstract

The present application provides a pod deployment method, an electronic device, and a storage medium. The method comprises: acquiring label information of pods to be processed in a Kubernetes platform; respectively determining scheduling priorities of said pods on the basis of the label information of said pods; and scheduling said pods according to the scheduling priorities of said pods.

Description

Pod deployment method, electronic device, and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to patent application No. 202310699482.3 filed with the China Patent Office on June 13, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to, but is not limited to, the field of cloud computing technology. Background Art

[0004] Kubernetes (K8s) is used to manage containerized applications across multiple hosts in a cloud platform. Kubernetes' goal is to make deploying containerized applications simple and efficient. A pod is the smallest unit created or deployed by Kubernetes. Kubernetes can deploy multiple pods within the Kubernetes platform based on unified scheduling rules.

[0005] However, during the deployment process, the order in which pods are dequeued is somewhat random, which may cause pod restarts or pod reconstructions, reducing deployment efficiency.

[0006] Summary of the Invention

[0007] The present application provides a pod deployment method, electronic device, and storage medium.

[0008] An embodiment of the present application provides a pod deployment method, the method comprising: obtaining label information of a pod to be processed in a Kubernetes platform; determining a scheduling priority of each pod to be processed based on the label information of each pod to be processed; and scheduling each pod to be processed according to the scheduling priority of the pod to be processed.

[0009] An embodiment of the present application provides an electronic device, including: one or more processors; a memory on which one or more programs are stored. When the one or more programs are executed by the one or more processors, the one or more processors implement any one of the pod deployment methods in the embodiments of the present application.

[0010] An embodiment of the present application provides a readable storage medium, which stores a computer program. When the computer program is executed by a processor, any one of the pod deployment methods in the embodiments of the present application is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG1 is a flow chart showing a pod deployment method in a Kubernetes platform provided by a related technical solution.

[0012] FIG2 is a flow chart showing a method for checking the health of a Kubernetes platform according to a related technical solution.

[0013] FIG3 shows a schematic flow chart of a pod deployment method provided in an embodiment of the present application.

[0014] FIG4 shows a schematic diagram of pod scheduling provided in an embodiment of the present application.

[0015] FIG5 is a schematic diagram showing a configuration file provided in an embodiment of the present application.

[0016] FIG6 is a schematic diagram showing a flow chart of a pod deployment method provided in an embodiment of the present application.

[0017] FIG7 shows a block diagram of a pod deployment device according to an embodiment of the present application.

[0018] FIG8 shows a structural diagram of an exemplary hardware architecture of a computing device capable of implementing the pod deployment method and apparatus according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] To make the purpose, technical solutions and advantages of this application more clear, the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of this application can be combined with each other in any way.

[0020] Currently, the application of Kubernetes in the communications field is usually based on the Kubernetes platform to achieve flexible deployment of communication services, to achieve control of network element devices, and to improve business traffic.

[0021] However, when deploying pods to various network elements in the Kubernetes platform, the Kubernetes platform typically deploys each pod according to a unified scheduling rule. For example, multiple pods are deployed according to a unified scheduling rule based on one or more YAML files (files used to express data serialization format).

[0022] Among them, multiple pods are scheduled to a node for deployment in a serial order. Since the deployment order corresponding to each pod is random, pod restart or pod reconstruction may occur, reducing the deployment efficiency.

[0023] For example, a network element device includes pod-A, pod-B, and pod-C. During the deployment process, pod-B is scheduled first; however, pod-A, as the basic pod, has not been scheduled yet and cannot provide services for pod-B. Therefore, pod-B cannot enter the ready state; pod-B may choose to restart or rebuild in order to put pod-B back into the scheduling queue, which will cause pod-B to waste time in the first scheduling process and has no effect. Furthermore, when the dequeue order of the scheduling queue is pod-A first, pod-B second, and pod-C last; at this time, the three pods can enter the ready state one after another. From the above example, it can be seen that the randomness of the deployment order of different pods reduces the efficiency of deployment.

[0024] In order to solve the above problems, the relevant technical solution provides two processing methods as shown in Figures 1 and 2.

[0025] Figure 1 shows a schematic flow diagram of a pod deployment method in a Kubernetes platform provided by a related technical solution. As shown in Figure 1 , the pod deployment method in the Kubernetes platform includes the following steps S101 to S106.

[0026] In step S101, the priority configuration information of the pod is extracted.

[0027] In step S102, it is determined whether each pod has been deployed.

[0028] If it is determined that each pod has been deployed to the deployment node, step S103 is executed; if it is determined that each pod has not been deployed to the deployment node, step S106 is executed.

[0029] In step S103 , it is determined whether there is a pod whose priority is lower than a preset priority threshold among the deployed pods.

[0030] If it is determined that there is a pod whose priority is lower than the preset priority threshold among the deployed pods, step S104 is executed; otherwise, step S106 is executed.

[0031] In step S104 , a “victim” pod is searched from a plurality of pods whose priorities are lower than a preset priority threshold.

[0032] In step S105 , if it is determined that a “victim” pod is found, the “victim” pod is terminated.

[0033] In step S106, the pod is deployed to the deployment node normally.

[0034] In the above process, a preemptive approach is used to terminate "sacrificial" pods whose priorities are lower than the preset priority threshold among multiple pods to ensure that high-priority pods can be deployed normally to the deployment node. However, the process of finding "sacrificial" pods still takes a considerable amount of time, reducing the efficiency of pod deployment.

[0035] FIG2 is a schematic flow diagram of a Kubernetes platform health check method provided by a related technical solution. This health check method can be applied to pod-B. As shown in FIG2 , this Kubernetes platform health check method includes the following steps S201 to S205.

[0036] In step S201 , pod-A is powered on successfully.

[0037] In step S202, an interface detection message is sent to pod-A.

[0038] In step S203, it is determined whether an interface detection response fed back by pod-A is received.

[0039] If it is determined that the interface detection response fed back by pod-A is received, step S205 is executed; if it is determined that the interface detection response fed back by pod-A is not received, step S204 is executed.

[0040] In step S204, pod-A enters a waiting state.

[0041] At this point, pod-B does not need to restart or rebuild, but waits for a while and then returns to execute step S202 , that is, sends an interface detection message to pod-A until pod-A replies with an interface detection response.

[0042] In step S205 , pod-A enters the ready state.

[0043] When a pod enters the Ready state, it indicates that the pod can work normally, that is, the pod has passed the health check.

[0044] It's important to note that health checks promote decoupling between pods. While they can prevent pod-B from restarting or rebuilding, they still waste time in the round-robin process of sending interface check messages to pod-A. Furthermore, if the dependencies between pods subsequently change, the logical order of health checks must be adjusted accordingly, which also results in inefficient deployment.

[0045] The present application provides a pod deployment method, electronic device and storage medium to solve the above problems.

[0046] Figure 3 shows a schematic flow chart of a pod deployment method provided in an embodiment of the present application. This method can be applied to a pod deployment device, for example, the pod deployment device can be set in a server corresponding to the Kubernetes platform. As shown in Figure 3, the pod deployment method in the embodiment of the present application includes but is not limited to the following steps S301 to S303.

[0047] In step S301, label information of the pod to be processed in the Kubernetes platform is obtained.

[0048] The label information is related to the pod type. Pods are the smallest resource objects in the Kubernetes platform. For example, a pod to be processed can be a group of one application container, or a group of multiple application containers. The pod to be processed includes at least one of shared storage (such as storage volumes), a network address, and operational information corresponding to the pod to be processed (such as container image version information or port information to be used).

[0049] When application containers are tightly coupled and need to share resources such as disks, multiple application containers are configured as a pending pod.

[0050] In step S302 , the scheduling priority of each pod to be processed is determined based on the label information of each pod to be processed.

[0051] In step S303, each pod to be processed is scheduled according to its scheduling priority.

[0052] In this embodiment, label information of the pending pods in the Kubernetes platform is obtained so that the categories of the pending pods can be distinguished based on the label information; based on the obtained label information of each pending pod, the scheduling priority of each pending pod is determined respectively, so that the scheduling priority of the pending pod can reflect the execution order of each pending pod, which is convenient for processing the pending pods in sequence and reducing the proportion of randomness in the order of pod dequeueing, wherein the pending pod is the smallest resource object in the Kubernetes platform; further, according to the scheduling priority of the pending pod, each pending pod is scheduled so that the pod with a high scheduling priority is executed first, reducing the proportion of pod restart or pod reconstruction caused by the randomness of the pod dequeueing order, and improving the deployment efficiency of the pending pod.

[0053] In some exemplary embodiments, the label information of the pod to be processed includes a preset number, wherein the smaller the preset number corresponding to the pod to be processed is, the higher the scheduling priority corresponding to the pod to be processed is.

[0054] It should be noted that based on the preset number, the scheduling priority corresponding to the pod to be processed can be determined quickly and accurately, thereby accelerating the processing speed of the pod to be processed and improving the deployment efficiency of the pod to be processed.

[0055] In some exemplary embodiments, the label information of the pods to be processed is information determined based on custom configuration information. Determining the scheduling priority of each pod to be processed based on the label information of each pod to be processed in step S302 includes determining the scheduling priority of each pod to be processed based on a category of each pod to be processed.

[0056] The label information is related to the pod category, and different categories of pending pods have different scheduling priorities.

[0057] By defining the corresponding relationship between the categories of pending pods and their corresponding labels in the custom configuration information, you can quickly find the scheduling priorities of the pending pods, speed up the determination of the scheduling priorities of the pending pods, and prioritize the processing of pending pods with higher scheduling priorities.

[0058] In some exemplary embodiments, the categories of pods to be processed include: basic class, business class, and application class; wherein the scheduling priority of pods of the basic class is higher than the scheduling priority of pods of the business class, and the scheduling priority of pods of the business class is higher than the scheduling priority of pods of the application class.

[0059] Basic pods are used to provide basic framework capabilities. For example, basic pods include at least one of those that specifically provide file service capabilities, those that provide network communication support capabilities, and those that provide persistent storage capabilities.

[0060] Service pods are used to implement basic services on network element devices based on the capabilities of the basic framework. Service pods correspond to the network element services they support, and different service pods support different network element services.

[0061] Application pods directly serve users. They perform secondary processing (e.g., data classification, data extraction, and data re-aggregation) on service data from network elements to obtain the data required by users and present it to the user end. Furthermore, application pods evolve as user needs change.

[0062] It's important to note that there are dependencies between infrastructure pods, business pods, and application pods. For example, almost all pods rely on infrastructure pods to provide the underlying framework needed to support business processes for other pods. Application pods often rely on business pods to provide them with business data.

[0063] The above examples of pod categories to be processed are merely illustrative. Different network element devices may also have different pod categories. For example, pods may be classified based on the resource size they occupy, or based on their application scenarios. Other pod categories not described are also within the scope of this application and are not further discussed here.

[0064] In some exemplary embodiments, before determining the scheduling priority of each pod to be processed based on the category of each pod to be processed, the method further includes: obtaining custom configuration information; and if it is determined that the category of the pod to be processed is not included in the custom configuration information, setting the category of the pod to be processed as the base class.

[0065] It should be noted that if the category of the pod to be processed cannot be found in the custom configuration information, the category of the pod to be processed will be set to the basic class (that is, the category with the highest scheduling priority) so that the pod to be processed will be processed first.

[0066] In some exemplary embodiments, before determining the scheduling priority of each pod to be processed based on the label information of each pod to be processed in step S302, the method further includes: obtaining deployment requirement information in the deployment request instruction in response to the deployment request instruction; screening and obtaining multiple pods to be processed from the Kubernetes platform based on the deployment requirement information, and obtaining label information of the pods to be processed.

[0067] The deployment requirement information may include information related to the Cloud-native Network Functions (CNFs) requested for deployment by the user terminal. Different network element devices may have different deployment requirement information. For example, the deployment requirement information corresponding to a base station's scheduling requirements for a terminal is service scheduling information for each terminal, and the deployment requirement information corresponding to a core network device's configuration requirements for each network element is configuration information for each network element.

[0068] Based on different deployment requirement information, it is determined that multiple pending pods related to the deployment requirement information in the Kubernetes platform need to be obtained. Furthermore, the multiple pending pods in the Kubernetes platform are screened to obtain multiple pending pods, and label information of the pending pods is obtained, so that the obtained pending pods can meet different deployment requirement information and improve the accuracy of deployment.

[0069] In some exemplary embodiments, scheduling each pending pod based on its scheduling priority in step S303 can be implemented as follows: inserting each pending pod at the end of a queue based on its scheduling priority; and cyclically retrieving the pending pod from the head of the queue and deploying the pending pod on the target deployment node until no pending pod exists in the queue.

[0070] The higher the scheduling priority of a pending pod, the closer it is to the head of the queue. The queue is a first-in, first-out queue.

[0071] For example, Figure 4 shows a schematic diagram of pod scheduling provided by an embodiment of the present application. As shown in Figure 4, after sorting multiple pods based on their scheduling priorities, the multiple pods are sequentially placed into a scheduling queue. Then, a pod is dequeued from the scheduling queue and processed sequentially through the predicate algorithm, post-filter algorithm, and priority algorithm to obtain a target deployment node. Finally, the pod is deployed on the target deployment node.

[0072] Among them, the Predicates algorithm stage is the node pre-selection process. In this stage, nodes that do not meet the conditions can be filtered out. Therefore, this stage can also be called the node filtering stage. For example, in the process of resource invitation, the pod is required to not only meet business needs, but also be deployed using nodes with sufficient resources. Therefore, nodes with insufficient resources need to be filtered out. The Post-filter algorithm stage is used to preempt nodes that occupy a lot of resources in order to obtain nodes with strong resource capabilities to the greatest extent possible. The Priorities algorithm stage is the node optimization stage. In this stage, multiple nodes are sorted based on the priority of each node, and the node with the highest priority is selected as the target deployment node.

[0073] By inserting pending pods with high scheduling priorities to the tail of the scheduling queue, these pending pods can be taken out from the head of the scheduling queue first, so that the pending pods with high scheduling priorities can be processed first, reducing the randomness of the order in which the pending pods are dequeued, thereby reducing the proportion of pod restarts or pod reconstructions caused by the randomness of the pod dequeue order; further, the pending pods are deployed on the target deployment node until there are no pending pods in the queue, thereby improving the deployment efficiency of the pending pods.

[0074] In some exemplary embodiments, before deploying the pod to be processed on the target deployment node, the method further includes: if it is determined that the target deployment node cannot be obtained, stopping processing of the pod to be processed.

[0075] In this case, because the target deployment node cannot be obtained, the pending pod cannot be deployed to the corresponding node in time, and the task that the pending pod is expected to complete cannot be completed. Therefore, it is necessary to stop processing the pending pod to reduce the deployment error rate of the pending pod.

[0076] Furthermore, the target deployment node can be determined through various screening methods to ensure that pending pods can continue to be processed. For example, the target deployment node can be obtained by: performing a preliminary screening of multiple candidate deployment nodes based on their resource capability information to obtain a preliminary screening result; and then re-screening the multiple candidate deployment nodes in the preliminary screening result based on their business capability information to obtain the target deployment node.

[0077] Among them, the resource capability information represents the capability information of the processing resources possessed by the alternative deployment nodes. The multiple alternative deployment nodes in the preliminary screening results are nodes whose resource capabilities meet a first preset capability threshold (for example, the number of resources possessed by the alternative deployment node is greater than a preset resource quantity threshold, etc.); the process of preliminary screening of multiple alternative deployment nodes based on resource capability information can correspond to the Predicates algorithm stage shown in Figure 4.

[0078] The business capability information represents the ability of the candidate deployment node to execute the business requirements of the pending pod. The process of re-screening the multiple candidate deployment nodes in the initial screening results based on the business capability information can correspond to the Priorities algorithm stage shown in Figure 4.

[0079] Based on the business capability information of each candidate deployment node, multiple candidate deployment nodes in the preliminary screening results are screened again. For example, based on the business capability information, multiple candidate deployment nodes are sorted so that the candidate deployment nodes with higher priorities are ranked first, and the candidate deployment node with the highest priority is selected as the target deployment node. The pod to be processed is deployed on the target deployment node so that the pod to be processed can obtain the resource capability information and business capability information of the target deployment node, better realize the corresponding business function, and improve the processing efficiency of business processing.

[0080] In some exemplary embodiments, multiple alternative deployment nodes in the preliminary screening results are re-screened based on the business capability information of each alternative deployment node to obtain a target deployment node, including: determining the business processing capability score corresponding to each alternative deployment node in the preliminary screening results based on the business capability information of each alternative deployment node; and selecting the alternative deployment node with the highest business processing capability score from the multiple alternative deployment nodes in the preliminary screening results as the target deployment node.

[0081] In some exemplary embodiments, a plurality of candidate deployment nodes are preliminarily screened based on resource capability information of each candidate deployment node. After obtaining the preliminary screening results, the plurality of candidate deployment nodes in the preliminary screening results are screened again based on business capability information of each candidate deployment node. Before obtaining the target deployment node, the method further includes: when it is determined that the resource capability information of the plurality of candidate deployment nodes in the preliminary screening results does not match the processing resources required by the pod to be processed, preempting the candidate deployment node whose resource capability meets a second preset capability threshold from the plurality of candidate deployment nodes to obtain the preliminary screening results.

[0082] The second preset capacity threshold is greater than the first preset capacity threshold. The process of obtaining a preliminary screening result by seizing a candidate deployment node whose resource capacity meets the second preset capacity threshold from multiple candidate deployment nodes may correspond to the post-filter algorithm stage shown in FIG4 .

[0083] Figure 5 shows a schematic diagram of a configuration file provided by an embodiment of the present application. As shown in Figure 5, the configuration file is displayed in the form of a common custom file.

[0084] The label information corresponding to the foundation class pod is set to class:foundation, the label information corresponding to the business class pod is set to class:business, and the label information corresponding to the application class pod is set to class:super. The label information can be information determined based on the classifier.

[0085] In this configuration file, FounClass represents a foundation pod, and its corresponding label type is Foundation (i.e., foundation class); BizClass represents a business pod, and its corresponding label type is Business (i.e., business class); FounClass represents an application pod (or upper-level pod), and its corresponding label type is Super (i.e., super class or application class); NoLabel represents an unlabeled pod, and its corresponding label type is also Foundation (i.e., foundation class).

[0086] It should be noted that when deploying each pod, parallel deployment can be used.

[0087] In some exemplary embodiments, multiple pending pods can be deployed in batches to different nodes, which can minimize the occurrence of pod restarts or pod rebuilds caused by the failure to satisfy dependencies between the pending pods during the deployment process, thereby improving the deployment efficiency of the pending pods.

[0088] If the dependencies between the pending pods change in the future, you only need to adjust the label information of each pending pod to adjust the scheduling order of different pending pods, thereby improving the scheduling efficiency of the pending pods.

[0089] Figure 6 shows a schematic flow chart of a pod deployment method according to an embodiment of the present application. As shown in Figure 6, the pod deployment method according to an embodiment of the present application includes but is not limited to the following steps S601 to S610.

[0090] In step S601, a classifier configuration file is imported.

[0091] Among them, the classifier configuration file can be a configuration file as shown in Figure 5, which pre-sets the label information corresponding to each different category of pod, so that when the deployment requirement information is subsequently obtained, it can be compared with the configuration file to determine the label information corresponding to each pod to be processed.

[0092] In some optional embodiments, the classifier configuration file may be a user-defined configuration file, which includes customized label information, category information corresponding to the label information, and the like.

[0093] It should be noted that the configuration file can be a file displayed in the form of a normal file, or a binary file, a file displayed in the form of a code script, etc., as long as it is a file format that can be recognized by the Kubernetes platform. This application does not impose any restrictions on this.

[0094] In step S602, in response to the deployment request instruction, the deployment requirement information in the deployment request instruction is obtained.

[0095] The deployment request instruction includes deployment requirement information related to the CNF that the user terminal requests to be deployed. CNF is not only a containerized network and virtual machine, but its CNF can also split network functions into multiple different service modules, so that different service functions can be implemented using different service modules.

[0096] In step S603, multiple pods to be processed are screened from the Kubernetes platform according to the deployment requirement information, and label information of the pods to be processed is obtained.

[0097] The pod to be processed can be a group of one application container or a group of multiple application containers. The pod to be processed includes shared storage (such as storage volumes), network addresses, and operational information corresponding to the pod to be processed (such as container image version information or port information to be used).

[0098] When application containers are tightly coupled and need to share resources such as disks, multiple application containers are configured as a pending pod.

[0099] In some exemplary embodiments, step S601 can be omitted, and the classifier configuration file does not need to be imported. Instead, each pod to be processed can be classified using a fixed logic. For example, classification can be performed based on Arabic numerals, with 1 being the highest priority, 2 being the second highest, and so on; or classification can be performed based on English letters, with a being the highest priority, b being the second highest, and so on; thereby determining the label information for each pod to be processed.

[0100] The label information of the pod to be processed includes Arabic numerals or English letters representing category information, so as to facilitate the subsequent confirmation of the scheduling priority of the pod to be processed based on the label information of each pod to be processed.

[0101] In step S604, all pods to be processed and their corresponding label information are added to the scheduling queue.

[0102] In step S605 , the label information of the pod to be processed is extracted to determine the category corresponding to the pod to be processed.

[0103] When extracting the label information of the pending pod from the scheduling queue, it is necessary to first check the queue head, and then loop through the queue to extract the pending pod from the queue head to obtain the label information of the pending pod. Furthermore, based on the label information of the pending pod, the category corresponding to the pending pod is determined.

[0104] In some exemplary embodiments, a classifier may be used to identify label information of the pod to be processed and determine a category corresponding to the pod to be processed.

[0105] It should be noted that the core of the classifier is the ability to identify pre-set label information, classify the pods to be processed based on the label information, and determine the category of the pods to be processed. Different categories of pods to be processed have different scheduling priorities.

[0106] In step S606 , it is determined whether the category of the pod to be processed is extracted.

[0107] If it is determined that the category of the pod to be processed is extracted, step S608 is executed; if it is determined that the category of the pod to be processed is not extracted, step S607 is executed.

[0108] In step S607, the scheduling priority corresponding to the pod to be processed is determined based on the default category.

[0109] The default category may be the basic category, and the scheduling priority corresponding to the pod to be processed may be processed with the scheduling priority corresponding to the basic category, so that the pod to be processed can be processed preferentially.

[0110] In step S608, it is determined whether all pending pods in the scheduling queue are scheduled.

[0111] If it is determined that all pending pods in the scheduling queue are scheduled, step S609 is executed; if it is determined that there are still unscheduled pending pods in the scheduling queue, step S606 is returned to be executed.

[0112] In step S609, each pod to be processed is processed in sequence based on the scheduling priority of the pod to be processed.

[0113] In step S610, each pod to be processed is sequentially deployed to its corresponding target deployment node.

[0114] The target deployment node can be obtained in the following manner: preliminarily screening multiple candidate deployment nodes based on the resource capability information of each candidate deployment node to obtain a preliminary screening result; re-screening multiple candidate deployment nodes in the preliminary screening result based on the business capability information of each candidate deployment node to obtain the target deployment node; and deploying the pod to be processed on the target deployment node.

[0115] Among them, the resource capability information represents the capability information of the processing resources possessed by the alternative deployment nodes. The multiple alternative deployment nodes in the preliminary screening results are nodes whose resource capabilities meet a first preset capability threshold (for example, the number of resources possessed by the alternative deployment node is greater than a preset resource quantity threshold, etc.); the process of preliminary screening of multiple alternative deployment nodes based on resource capability information can correspond to the Predicates algorithm stage shown in Figure 4.

[0116] The business capability information represents the ability of the candidate deployment node to execute the business requirements of the pending pod. The process of re-screening the multiple candidate deployment nodes in the initial screening results based on the business capability information can correspond to the Priorities algorithm stage shown in Figure 4.

[0117] In some exemplary embodiments, when it is determined that the target deployment node cannot be obtained, processing of the pending pod is stopped; then, scheduling of other pending pods in the scheduling queue is stopped, and deployment corresponding to the pending pod is terminated.

[0118] In some exemplary embodiments, if all the pods to be processed have obtained their corresponding target deployment nodes and each pod to be processed has been successfully deployed to its corresponding target deployment node, it is determined that the deployment is completed.

[0119] In this embodiment, by receiving a deployment request instruction, obtaining deployment requirement information in the deployment request instruction, and screening multiple pods to be processed from the Kubernetes platform based on the deployment requirement information, and obtaining label information of the pods to be processed, so as to distinguish the category of each pod to be processed based on the label information; based on the obtained label information of each pod to be processed, determining the scheduling priority of each pod to be processed, so that the scheduling priority of the pod to be processed can reflect the execution order of each pod to be processed, facilitating the sequential processing of the pods to be processed, and reducing the randomness of the pod dequeue order; further, scheduling each pod to be processed based on the scheduling priority of the pod to be processed, so that the pods with high scheduling priority are executed first, reducing the occurrence rate of pod restart or pod reconstruction caused by the randomness of the pod dequeue order, and then deploying each pod to be processed to the target deployment node, thereby improving the deployment efficiency of the pod to be processed.

[0120] Figure 7 shows a block diagram of a pod deployment apparatus provided in an embodiment of the present application. As shown in Figure 7 , the pod deployment apparatus 700 includes, but is not limited to: an acquisition module 701 configured to acquire label information of pending pods in the Kubernetes platform; a determination module 702 configured to determine the scheduling priority of each pending pod based on the label information of each pending pod; and a scheduling module 703 configured to schedule each pending pod based on the scheduling priority of the pending pod.

[0121] It should be noted that the pod deployment device 700 in this embodiment can implement any pod deployment method in the embodiments of this application.

[0122] According to the pod deployment device of the embodiment of the present application, the label information of the pods to be processed in the Kubernetes platform is obtained through the acquisition module, so as to distinguish the categories of each pod to be processed based on the label information; the determination module is used to determine the scheduling priority of each pod to be processed based on the acquired label information of each pod to be processed, so that the scheduling priority of the pod to be processed can reflect the execution order of each pod to be processed, which is convenient for processing the pods to be processed in sequence and reducing the proportion of randomness in the order of pod dequeueing, wherein the pod to be processed is the smallest resource object in the Kubernetes platform; further, the determination module is used to schedule each pod to be processed according to the scheduling priority of the pod to be processed, so that pods with high scheduling priority are executed first, reducing the proportion of pod restarts or pod reconstructions caused by the randomness of the pod dequeueing order, and improving the deployment efficiency of the pods to be processed.

[0123] It should be understood that the present invention is not limited to the specific configurations and processes described in the above embodiments and illustrated in the figures. For the sake of convenience and brevity, detailed descriptions of known methods are omitted here. The specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0124] FIG8 shows a structural diagram of an exemplary hardware architecture of a computing device capable of implementing the pod deployment method and apparatus according to an embodiment of the present application.

[0125] As shown in Figure 8, computing device 800 includes an input device 801, an input interface 802, a central processing unit 803, a memory 804, an output interface 805, and an output device 806. The input interface 802, the central processing unit 803, the memory 804, and the output interface 805 are interconnected via a bus 807. The input device 801 and the output device 806 are connected to the bus 807 via the input interface 802 and the output interface 805, respectively, and are further connected to other components of the computing device 800.

[0126] The input device 801 receives input information from the outside and transmits the input information to the central processing unit 803 through the input interface 802; the central processing unit 803 processes the input information based on the computer-executable instructions stored in the memory 804 to generate output information, temporarily or permanently stores the output information in the memory 804, and then transmits the output information to the output device 806 through the output interface 805; the output device 806 outputs the output information to the outside of the computing device 800 for user use.

[0127] In one embodiment, the computing device shown in Figure 8 can be implemented as an electronic device, which may include: a memory configured to store a program; and a processor configured to run the program stored in the memory to execute the pod deployment method described in the above embodiment.

[0128] In one embodiment, the computing device shown in Figure 8 can be implemented as a pod deployment system, which may include: a memory configured to store a program; and a processor configured to run the program stored in the memory to execute the pod deployment method described in the above embodiment.

[0129] An embodiment of the present application further provides a readable storage medium, which stores a computer program. When the computer program is executed by a processor, any one of the pod deployment methods in the embodiments of the present application is implemented.

[0130] The foregoing is merely an exemplary embodiment of the present application and is not intended to limit the scope of protection of the present application. Generally speaking, various embodiments of the present application can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although the present application is not limited thereto.

[0131] Embodiments of the present application may be implemented by a processor executing computer program instructions, for example, in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

[0132] The block diagram of any logical flow in the accompanying drawings of the present application can represent program steps, or can represent interconnected logical circuits, modules and functions, or can represent a combination of program steps and logical circuits, modules and functions. The computer program can be stored on a memory. The memory can have any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as but not limited to read-only memory (ROM), random access memory (RAM), optical storage device and system (digital versatile disc DVD or CD optical disc) etc. The computer readable medium may include non-transient storage media. The processor can be any type suitable for the local technical environment, such as but not limited to a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (FPGA) and a processor based on a multi-core processor architecture.

[0133] The above description of exemplary embodiments of the present application has been provided by way of exemplary and non-limiting examples. However, various modifications and adaptations to the above embodiments will be apparent to those skilled in the art, when considered in conjunction with the accompanying drawings and claims, without departing from the scope of the present invention. Therefore, the proper scope of the present invention will be determined by reference to the claims.

Claims

1. A pod deployment method, comprising: Get the label information of the pod to be processed in the Kubernetes platform; Based on the label information of each of the pods to be processed, respectively determine the scheduling priority of each of the pods to be processed; Each of the pods to be processed is scheduled according to the scheduling priority of the pods to be processed.

2. The method according to claim 1, wherein: The label information of the pod to be processed includes a preset number, wherein the smaller the preset number corresponding to the pod to be processed is, the higher the scheduling priority corresponding to the pod to be processed is.

3. The method according to claim 1, wherein: The label information of the pod to be processed is information determined based on the custom configuration information, and the label information is related to the category of the pod. Different categories of the pods to be processed have different corresponding scheduling priorities; The step of determining the scheduling priority of each of the pods to be processed based on the label information of each of the pods to be processed includes: Based on the category of each of the pods to be processed, the scheduling priority of each of the pods to be processed is determined respectively.

4. The method according to claim 3, wherein: The categories of the pods to be processed include: basic category, business category and application category; The scheduling priority of the pod of the basic class is higher than the scheduling priority of the pod of the business class, and the scheduling priority of the pod of the business class is higher than the scheduling priority of the pod of the application class.

5. The method according to claim 4, wherein: Before determining the scheduling priority of each of the pods to be processed based on the category of each of the pods to be processed, the method further includes: Obtaining the custom configuration information; When it is determined that the custom configuration information does not contain the category of the pod to be processed, the category of the pod to be processed is set to the basic category.

6. The method according to any one of claims 1 to 5, wherein: Before determining the scheduling priority of each of the pods to be processed based on the label information of each of the pods to be processed, the method further includes: In response to a deployment request instruction, obtaining deployment requirement information in the deployment request instruction; According to the deployment requirement information, a plurality of pods to be processed are screened from the Kubernetes platform, and label information of the pods to be processed is obtained.

7. The method according to any one of claims 1 to 5, wherein: Scheduling each of the pods to be processed according to the scheduling priority of the pods to be processed includes: According to the scheduling priority of each of the pods to be processed, each of the pods to be processed is inserted into the tail of the queue; Circularly taking out the pod to be processed from the head of the queue, and deploying the pod to be processed on the target deployment node until the pod to be processed does not exist in the queue; The higher the scheduling priority of the to-be-processed pod is, the closer the position of the to-be-processed pod in the queue is to the head of the queue.

8. The method according to claim 7, wherein: Before deploying the pod to be processed on the target deployment node, the method further includes: When it is determined that the target deployment node cannot be obtained, the processing of the pod to be processed is stopped.

9. An electronic device, comprising: one or more processors; A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the following steps: The pod deployment method described in any one of to 8.

10. A readable storage medium, wherein: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the pod deployment method described in any one of 1 to 8 is implemented.

Images