Pod deployment method, electronic equipment and storage medium

Abstract

The invention provides a pod deployment method, electronic equipment and a storage medium, and relates to the technical field of cloud computing. The method comprises the steps of obtaining label information of to-be-processed pods in a Kubernetes platform, wherein the label information is used for distinguishing categories of the to-be-processed pods; based on the label information of each to-be-processed pod, determining the scheduling priority of each to-be-processed pod; and scheduling each pod to be processed according to the scheduling priority of the pod to be processed. The occurrence proportion of pod restart or pod reconstruction caused by the randomness of the pod out-of-column sequence is reduced, and the deployment efficiency of the to-be-processed pod is improved.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a pod deployment method, an electronic device, and a storage medium. Background Art

[0002] Kubernetes (K8s for short) is used to manage containerized applications on multiple hosts in a cloud platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient. Among them, pod is the smallest unit created or deployed by Kubernetes. Kubernetes can deploy multiple pods in the Kubernetes platform based on unified scheduling rules.

[0003] However, during the deployment process, since the order in which pods are dequeued is somewhat random, pod restarts or pod reconstructions may occur, reducing the efficiency of deployment. Summary of the invention

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

[0005] 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.

[0006] 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, and 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.

[0007] 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.

[0008] According to the pod deployment method, electronic device and storage medium of the embodiments of the present application, by obtaining the label information of the pods to be processed in the Kubernetes platform, the categories of the pods to be processed are distinguished based on the label information; based on the obtained label information of the pods to be processed, the scheduling priority of each pod to be processed is determined respectively, so that the scheduling priority of the pods 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 of the pod dequeue order, wherein the pod to be processed is the smallest resource object in the Kubernetes platform; further, according to the scheduling priority of the pod to be processed, each pod to be processed is scheduled, so that the pods with high scheduling priority are executed first, reducing the proportion of pod restart or pod reconstruction caused by the randomness of the pod dequeue order, and improving the deployment efficiency of the pods to be processed.

[0009] With regard to the above embodiments and other aspects of the present application and their implementation, further description is provided in the accompanying drawings, detailed description and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A flow chart showing a pod deployment method in a Kubernetes platform provided by a related technical solution.

[0011] Figure 2 A flow chart of a method for checking the health of a Kubernetes platform provided by a related technical solution is shown.

[0012] Figure 3 A schematic diagram of the process of the pod deployment method provided in an embodiment of the present application is shown.

[0013] Figure 4 A schematic diagram of pod scheduling provided in an embodiment of the present application is shown.

[0014] Figure 5 A schematic diagram showing a configuration file provided in an embodiment of the present application.

[0015] Figure 6 A schematic diagram of the process of the pod deployment method provided in an embodiment of the present application is shown.

[0016] Figure 7 A block diagram of a pod deployment device provided in an embodiment of the present application is shown.

[0017] Figure 8 A structural diagram showing 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

[0018] In order to make the purpose, technical solution and advantages of the present application more clear, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other arbitrarily without conflict.

[0019] At present, the application of Kubernetes in the communication 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.

[0020] However, in the process of deploying pods to various network element devices in the Kubernetes platform, the Kubernetes platform usually deploys each pod according to a unified scheduling rule. For example, based on one or more YAML files (i.e., files used to express data serialization format), multiple pods are deployed according to a unified scheduling rule.

[0021] Among them, multiple pods are scheduled to a certain node for deployment in a serial order. Since the deployment order corresponding to each pod has a certain randomness, pod restart or pod reconstruction may occur, which reduces the efficiency of deployment.

[0022] 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 so that pod-B can return to the scheduling queue, which will cause pod-B to waste time in the first scheduling process and has no effect. Furthermore, when the order of dequeuing 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.

[0023] In order to solve the above problems, the relevant technical solution provides Figure 1 and Figure 2 Two treatment methods are shown.

[0024] Figure 1 The following is a flow chart showing a pod deployment method in a Kubernetes platform provided by a related technical solution. Figure 1 As shown, the pod deployment method in the Kubernetes platform includes the following steps.

[0025] Step S101, extracting the priority configuration information of the pod.

[0026] Step S102, determining whether each pod has been deployed.

[0027] 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.

[0028] Step S103, determining whether there is a pod whose priority is lower than a preset priority threshold among the deployed pods.

[0029] 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.

[0030] Step S104: searching for a “victim” pod from a plurality of pods whose priorities are lower than a preset priority threshold.

[0031] Step S105: when it is determined that the “victim” pod is found, the “victim” pod is terminated.

[0032] Step S106, deploy the pod to the deployment node normally.

[0033] In the above process, the "sacrificial" pod whose priority is lower than the preset priority threshold among multiple pods is terminated based on preemption, so as to ensure that the high-priority pod can be normally deployed to the deployment node; however, it still takes a lot of time to find the "sacrificial" pod, which reduces the deployment efficiency of the pod.

[0034] Figure 2 The flowchart of the health check method of the Kubernetes platform provided by the related technical solution is shown. The health check method can be applied to pod-B. Figure 2 As shown in the figure, the health check method of the Kubernetes platform includes the following steps:

[0035] Step S201: pod-A is powered on successfully.

[0036] Step S202: Send an interface detection message to pod-A.

[0037] Step S203: determine whether an interface detection response fed back by pod-A is received.

[0038] 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.

[0039] Step S204: pod-A enters a waiting state.

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

[0041] Step S205: pod-A enters the ready state.

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

[0043] It should be noted that health check is a way to promote decoupling between pods. Although health check can avoid restarting or rebuilding pod-B, it still wastes time in the process of sending interface detection messages to pod-A in a polling manner. In addition, if the dependencies between the subsequent pods change, the logical order of health check must also be adjusted accordingly, which also leads to low deployment efficiency.

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

[0045] Figure 3 The flowchart of the pod deployment method provided by the embodiment of the present application is shown. The 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. Figure 3 As shown, the pod deployment method in the embodiment of the present application includes but is not limited to the following steps.

[0046] Step S301, obtaining label information of the pod to be processed in the Kubernetes platform.

[0047] The label information is related to the category of the pod, which is the smallest resource object in the Kubernetes platform. For example, 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 at least one of shared storage (such as storage volumes, etc.), network addresses, and operation information corresponding to the pod to be processed (such as container image version information or port information to be used, etc.).

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

[0049] Step S302: Determine the scheduling priority of each pod to be processed based on the label information of each pod to be processed.

[0050] Step S303: schedule each pod to be processed according to the scheduling priority of the pod to be processed.

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

[0052] 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.

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

[0054] In some exemplary embodiments, the label information of the pod to be processed is information determined based on the custom configuration information. The step S302 of determining the scheduling priority of each pod to be processed based on the label information of each pod to be processed includes: determining the scheduling priority of each pod to be processed based on the category of each pod to be processed.

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

[0056] Through the correspondence between the category of the pod to be processed configured in the custom configuration information and its corresponding label information, the scheduling priority corresponding to the pod to be processed can be quickly found, the speed of determining the scheduling priority of the pod to be processed can be accelerated, and the pod to be processed with a high scheduling priority can be processed first.

[0057] 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.

[0058] The basic class pod is used to provide the capabilities of the basic framework. For example, the basic class pod includes at least one of a pod that specifically provides file service capabilities, a pod that provides network communication support capabilities, and a pod that provides persistent storage capabilities.

[0059] The service pod is used to implement the basic services of the network element equipment based on the capabilities of the basic framework. The service pod corresponds to the network element services it supports, and different service pods support different network element services.

[0060] Application pods are used to directly serve users. They perform secondary processing (e.g., data classification, data extraction, data re-aggregation, etc.) on the service data of network element devices to obtain the data required by users and present the data required by users to the user end. In addition, application pods will change as user needs change.

[0061] It should be noted that there are certain dependencies between basic class pods, business class pods, and application class pods. For example, almost all pods require basic class pods to provide basic framework capabilities in order to support business processes for other types of pods; and application class pods often rely on business class pods to provide them with business data.

[0062] The above is only an example of the categories of pods to be processed. Different categories of pods may exist in different network element devices. For example, pods may be divided into different categories based on the size of the resources they occupy, or pods may be divided into different categories based on application scenarios. Other unspecified categories of pods are also within the scope of protection of this application and will not be described in detail here.

[0063] 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 when it is determined that there is no category of the pod to be processed in the custom configuration information, setting the category of the pod to be processed as the basic class.

[0064] 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 category (that is, the category with the highest scheduling priority) so that the pod to be processed can be processed first.

[0065] 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 also 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 according to the deployment requirement information, and obtaining label information of the pods to be processed.

[0066] The deployment requirement information may include information related to the cloud-native network functions (CNF) requested to be deployed by the user terminal. The deployment requirement information corresponding to different network element devices is different. For example, the deployment requirement information corresponding to the scheduling requirements of the base station for the terminal is the service scheduling information for each terminal, and the deployment requirement information corresponding to the configuration requirements of the core network device for each network element device is the configuration information of the core network device for each network element device.

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

[0068] In some exemplary embodiments, scheduling each pod to be processed according to the scheduling priority of the pod to be processed in step S303 can be implemented in the following manner: inserting each pod to be processed into the tail of the queue according to the scheduling priority of each pod to be processed; cyclically 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 there are no pods to be processed in the queue.

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

[0070] For example, Figure 4 A schematic diagram of pod scheduling provided by an embodiment of the present application is shown. Figure 4As shown in the figure, after sorting multiple pods based on the scheduling priority of each pod to be processed, the multiple pods to be processed are put into the scheduling queue in turn; then, a pod to be processed is dequeued from the scheduling queue, and then processed by the predicate algorithm, the post-filter algorithm and the priority algorithm in turn to obtain the target deployment node; finally, the pod to be processed is deployed on the target deployment node.

[0071] 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 use nodes with sufficient resources for deployment. Therefore, nodes with insufficient resources need to be filtered out. The Post-filter algorithm stage is used to preempt nodes that occupy more resources in order to obtain nodes with strong resource capabilities to the greatest extent. 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.

[0072] By inserting the pending pod with high scheduling priority into the tail of the scheduling queue first, the pending pod with high scheduling priority can be taken out from the head of the scheduling queue first, so that the pending pod with high scheduling priority can be processed first, reducing the proportion of randomness in the order of dequeuing the pending pods, thereby reducing the proportion of pod restarts or pod reconstructions caused by the randomness of the dequeuing order of the pods; 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.

[0073] 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.

[0074] Among them, since the target deployment node cannot be obtained, the pod to be processed cannot be deployed to the corresponding node in time, and the task expected to be completed by the pod to be processed cannot be completed. Therefore, it is necessary to stop processing the pod to be processed to reduce the deployment error ratio of the pod to be processed.

[0075] Furthermore, the target deployment node can be determined through a variety of different screening methods so that the Pod to be processed can continue to be processed. For example, the target deployment node can be obtained by: preliminarily screening multiple candidate deployment nodes according to the resource capability information of each candidate deployment node to obtain a preliminary screening result; and re-screening multiple candidate deployment nodes in the preliminary screening result according to the business capability information of each candidate deployment node to obtain the target deployment node.

[0076] The resource capability information represents the capability information of the processing resources possessed by the candidate deployment nodes, and the multiple candidate deployment nodes in the preliminary screening result are nodes whose resource capabilities meet the first preset capability threshold (for example, the number of resources possessed by the candidate deployment node is greater than the preset resource quantity threshold, etc.); the process of preliminary screening of the multiple candidate deployment nodes based on the resource capability information may correspond to Figure 4 The Predicates algorithm stages are shown.

[0077] The business capability information represents the capability information of the candidate deployment node to execute the business requirements of the pod to be processed. The process of re-screening multiple candidate deployment nodes in the preliminary screening results based on the business capability information can correspond to Figure 4 The Priorities algorithm stages are shown.

[0078] By rescreening multiple candidate deployment nodes in the preliminary screening results based on the business capability information of each candidate deployment node, for example, based on the business capability information, sorting multiple candidate deployment nodes so that the candidate deployment nodes with high priority are arranged in front, thereby selecting the candidate deployment node with the highest priority as the target deployment node; deploying the pod to be processed 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.

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

[0080] 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 result, the plurality of candidate deployment nodes in the preliminary screening result 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 result does not match the processing resources required by the pod to be processed, seizing the candidate deployment nodes whose resource capabilities meet a second preset capability threshold from the plurality of candidate deployment nodes to obtain the preliminary screening result.

[0081] 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 can correspond to Figure 4 The Post-filter algorithm stages are shown.

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

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

[0084] In this configuration file, FounClass represents the foundation pod, and its corresponding label type is Foundation (i.e., foundation class); BizClass represents the business pod, and its corresponding label type is Business (i.e., business class); FounClass represents the 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).

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

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

[0087] In the case that the dependencies between the pods to be processed change in the future, the scheduling order of the different pods to be processed can be adjusted by simply adjusting the label information of each pod to be processed, thereby improving the scheduling efficiency of the pods to be processed.

[0088] Figure 6 A schematic diagram of the process of the pod deployment method provided in the embodiment of the present application is shown. Figure 6 As shown, the pod deployment method in the embodiment of the present application includes but is not limited to the following steps.

[0089] Step S601, importing a classifier configuration file.

[0090] The classifier configuration file can be as follows: Figure 5 The configuration file shown in the figure pre-sets label information corresponding to pods of different categories, so that when the deployment requirement information is obtained later, it can be compared with the configuration file to determine the label information corresponding to each pod to be processed.

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

[0092] 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, and this application does not impose any restrictions on this.

[0093] Step S602: In response to the deployment request instruction, obtain the deployment requirement information in the deployment request instruction.

[0094] The deployment request instruction includes: deployment requirement information related to the CNF that the user terminal requests to deploy. CNF is not only a containerized network and virtual machine, but its CNF can also divide the network function into a variety of different service modules, so as to use different service modules to realize different service functions.

[0095] Step S603: Filter and obtain multiple pods to be processed from the Kubernetes platform according to the deployment requirement information, and obtain label information of the pods to be processed.

[0096] The pod to be processed may 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, etc.), network addresses, and operation information corresponding to the pod to be processed (such as container image version information or port information to be used, etc.).

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

[0098] In some exemplary embodiments, step S601 may be omitted, and the classifier configuration file does not need to be imported, but each pod to be processed is classified by a fixed logic. For example, the pods may be classified by Arabic numerals, and 1 is fixed to have the highest priority, 2 is the second, and so on; or the pods may be classified by English letters, and a is fixed to have the highest priority, b is the second, and so on; thereby determining the label information of each pod to be processed.

[0099] The label information of the pod to be processed includes: Arabic numerals representing category information, or English letters representing category information, etc., 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.

[0100] Step S604: add all pods to be processed and their corresponding label information to the scheduling queue.

[0101] Step S605: extract label information of the pod to be processed, and determine the category corresponding to the pod to be processed.

[0102] When extracting the label information of the pod to be processed from the scheduling queue, it is necessary to first check the head of the scheduling queue, and cyclically take out the pod to be processed from the head of the scheduling queue, and then obtain the label information of the pod to be processed, and further, based on the label information of the pod to be processed, determine the category corresponding to the pod to be processed.

[0103] In some exemplary embodiments, the label information of the pod to be processed may be identified by a classifier to determine the category of the pod to be processed.

[0104] It should be noted that the core of the classifier is to be able to identify pre-set label information, and classify the pods to be processed according to the label information to determine the categories of the pods to be processed, wherein different categories of pods to be processed have different corresponding scheduling priorities.

[0105] Step S606, determining whether the category of the pod to be processed is extracted.

[0106] 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.

[0107] Step S607: Determine the scheduling priority corresponding to the pod to be processed based on the default category.

[0108] The default category may be a basic category, and the scheduling priority corresponding to the pod to be processed is processed according to the scheduling priority corresponding to the basic category, so that the pod to be processed can be processed preferentially.

[0109] Step S608, determining whether all the pods to be processed in the scheduling queue are scheduled.

[0110] If it is determined that all the 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, the process returns to step S606.

[0111] Step S609: Process each pod to be processed in sequence based on the scheduling priority of the pod to be processed.

[0112] Step S610: deploy each pod to be processed to its corresponding target deployment node in sequence.

[0113] Among them, the target deployment node can be obtained in the following manner: preliminarily screening multiple candidate deployment nodes according to 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 according to 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.

[0114] The resource capability information represents the capability information of the processing resources possessed by the candidate deployment nodes, and the multiple candidate deployment nodes in the preliminary screening result are nodes whose resource capabilities meet the first preset capability threshold (for example, the number of resources possessed by the candidate deployment node is greater than the preset resource quantity threshold, etc.); the process of preliminary screening of the multiple candidate deployment nodes based on the resource capability information may correspond to Figure 4 The Predicates algorithm stages are shown.

[0115] The business capability information represents the capability information of the candidate deployment node to execute the business requirements of the pod to be processed. The process of re-screening multiple candidate deployment nodes in the preliminary screening results based on the business capability information can correspond to Figure 4 The Priorities algorithm stages are shown.

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

[0117] In some exemplary embodiments, if all the pods to be processed obtain the target deployment nodes corresponding to them, and each pod to be processed is successfully deployed to the target deployment nodes corresponding to them, it is determined that the deployment is completed.

[0118] In this embodiment, by receiving a deployment request instruction, the deployment requirement information in the deployment request instruction is obtained, and based on the deployment requirement information, multiple pods to be processed are screened from the Kubernetes platform, and the label information of the pods to be processed is obtained, so as to distinguish the categories of each pod to be processed based on the label information; based on the obtained label information of each pod to be processed, the scheduling priority of each pod to be processed is determined respectively, so that the scheduling priority of the pod to be processed can reflect the execution order of each pod to be processed, so as to facilitate the processing of the pods to be processed in sequence and reduce the randomness of the pod dequeue order; further, according to the scheduling priority of the pod to be processed, each pod to be processed is scheduled, so that the pod with a high scheduling priority is executed first, and the occurrence ratio of pod restart or pod reconstruction caused by the randomness of the pod dequeue order is reduced, and then, each pod to be processed is deployed to the target deployment node, so as to improve the deployment efficiency of the pod to be processed.

[0119] Figure 7 The block diagram of the pod deployment device provided in the embodiment of the present application is shown. Figure 7 As shown, the pod deployment device 700 includes but is not limited to the following modules.

[0120] The acquisition module 701 is configured to acquire label information of the pod to be processed in the Kubernetes platform;

[0121] The determination module 702 is configured to determine the scheduling priority of each pod to be processed based on the label information of each pod to be processed;

[0122] The scheduling module 703 is configured to schedule each pod to be processed according to the scheduling priority of the pod to be processed.

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

[0124] According to the pod deployment device of the embodiment of the present application, the label information of the pod 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 of the pod dequeue order, 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 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 dequeue order, and improving the deployment efficiency of the pod to be processed.

[0125] It should be clear that the present invention is not limited to the specific configurations and processes described in the above embodiments and shown in the figures. For the convenience and brevity of description, a detailed description of the known methods is omitted here, and the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, which will not be repeated here.

[0126] Figure 8 A structural diagram showing 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.

[0127] like Figure 8 As shown, the 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 connected to each other via a bus 807, and 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 then connected to other components of the computing device 800.

[0128] Specifically, 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.

[0129] In one embodiment, Figure 8 The computing device shown 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.

[0130] In one embodiment, Figure 8 The computing device shown 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.

[0131] The above is only an exemplary embodiment of the present application and is not intended to limit the scope of protection of the present application. In general, various embodiments of the present application can be implemented in hardware or special 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, a microprocessor or other computing device, although the present application is not limited thereto.

[0132] Embodiments of the present application may be implemented by a processor executing computer program instructions, such as 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.

[0133] The block diagram of any logic flow in the accompanying drawings of the present application can represent program steps, or can represent interconnected logic circuits, modules and functions, or can represent a combination of program steps and logic 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 memory device and system (digital versatile disc DVD or CD disc), etc. Computer readable media 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 (FGPA) and a processor based on a multi-core processor architecture.

[0134] By way of exemplary and non-limiting examples, a detailed description of exemplary embodiments of the present application has been provided above. However, various modifications and adjustments to the above embodiments will be apparent to those skilled in the art when considered in conjunction with the accompanying drawings and claims, but will not depart from the scope of the present invention. Therefore, the proper scope of the present invention will be determined according to the claims.

Claims

1. A pod deployment method, characterized in that: The method comprises: 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, characterized in that: 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, characterized in that: 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that: include: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the pod deployment method as described in any one of 1 to 8.

10. A readable storage medium, characterized in that: 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