Pod scheduling method and device based on Kubernetes cluster, equipment and storage medium

Abstract

The application provides a Kubernetes cluster-based pod scheduling method and device, equipment and a storage medium; wherein the method comprises: in the scheduling process of a target pod, the scheduling data of the target pod is listened to, the scheduling result of the target pod is obtained; based on the scheduling result of the target pod, the first target scheduling data of the target pod is determined from the scheduling data record table; the first target scheduling data represents the scheduling information of at least one candidate node of the target pod in the Kubernetes cluster in the scheduling process; the first target scheduling data is stored in the scheduling data information base to query the scheduling situation of at least one candidate node of the target pod in the scheduling process. Through the embodiment of the application, the diversity of the scheduling data of the pod scheduling process can be realized, thereby improving the accuracy of the analysis result of the pod scheduling process.

Description

Technical Field

[0001] This application relates to the field of communication technology, and to, but is not limited to, pod scheduling methods, devices, equipment, and storage media based on Kubernetes clusters. Background Technology

[0002] Kubernetes cluster technology, based on container technology, has seen significant development. Kubernetes cluster technology is an open-source container cluster management and orchestration service system. A pod, which is a group of containers, is the smallest deployable computing unit that can be created and managed in a Kubernetes cluster. Scheduling a pod enables the rapid deployment and migration of the applications contained within it.

[0003] The pod scheduling process primarily involves assigning pods without assigned physical nodes to a deployment node within the cluster. During pod scheduling, the scheduling results are typically queried via command line. However, the scheduling data displayed through the command line is relatively limited, thus reducing the accuracy of the analysis results regarding the pod scheduling process. Summary of the Invention

[0004] The pod scheduling method, apparatus, device, and storage medium based on Kubernetes clusters provided in this application can realize the diversity of scheduling data to display the pod scheduling process, thereby improving the accuracy of the analysis results of the pod scheduling process.

[0005] The technical solution of this application is implemented as follows:

[0006] This application provides a pod scheduling method based on a Kubernetes cluster, the method comprising:

[0007] During the scheduling process of the target pod, the scheduling result of the target pod is obtained by listening to the scheduling data of the target pod;

[0008] Based on the scheduling result of the target pod, the first target scheduling data of the target pod is determined from the scheduling data record table; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod.

[0009] The first target scheduling data is stored in the scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

[0010] This application provides a pod scheduling device based on a Kubernetes cluster, including a listening unit, an acquisition unit, and a query unit; wherein,

[0011] The monitoring unit is used to obtain the scheduling result of the target pod by monitoring the scheduling data of the target pod during the scheduling process.

[0012] The acquisition unit is used to determine the first target scheduling data of the target pod from the scheduling data record table based on the scheduling result of the target pod; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod.

[0013] The query unit is used to store the first target scheduling data of the target pod into the scheduling data information database in order to query the scheduling status of the at least one candidate node of the target pod during the scheduling process.

[0014] This application provides an electronic device, including:

[0015] A processor, and a memory storing processor-executable instructions;

[0016] When the executable instructions are executed by the processor, the pod scheduling method based on the Kubernetes cluster described above is executed.

[0017] This application provides a computer-readable storage medium, characterized in that it stores executable instructions, which, when executed by one or more processors, implement the pod scheduling method based on a Kubernetes cluster as described above.

[0018] This application provides a pod scheduling method based on a Kubernetes cluster. During the scheduling of a target pod, the scheduling result is first obtained by monitoring the target pod's scheduling data. Then, based on the target pod's scheduling result, the first target scheduling data for the target pod is determined from the scheduling data record table. Finally, the first target scheduling data is stored in a scheduling data information database to query the scheduling status of at least one candidate node for the target pod during the scheduling process.

[0019] On the one hand, since the first target scheduling data includes the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod, it is possible to perceive the execution status of each node in the Kubernetes cluster during the pod scheduling process, thereby realizing the diversity of scheduling data to display the pod scheduling process. In this way, it provides a basic data source for optimizing cluster scheduling analysis, thereby improving the accuracy of the analysis results of the pod scheduling process.

[0020] On the other hand, by querying the scheduling status of at least one candidate node of the target pod during the scheduling process, it is possible to perceive and analyze the execution status of each node of each pod during the scheduling process, thereby obtaining the overall scheduling effect of the pod and improving the accuracy of the analysis results of the pod scheduling process.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0024] Figure 1 A flowchart illustrating an optional pod scheduling method based on a Kubernetes cluster provided in this application embodiment. Figure 1 ;

[0025] Figure 2 A flowchart illustrating an optional pod scheduling method based on a Kubernetes cluster provided in this application embodiment. Figure 2 ;

[0026] Figure 3 A flowchart illustrating an optional pod scheduling method based on a Kubernetes cluster provided in this application embodiment. Figure 3 ;

[0027] Figure 4 A schematic diagram of an optional scheduling data display interface provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram illustrating an optional pod scheduling process provided in an embodiment of this application;

[0029] Figure 6 A schematic diagram of the structure of a cloud host in an optional Kubernetes cluster provided in this application embodiment;

[0030] Figure 7 A flowchart illustrating an optional pod scheduling method based on a Kubernetes cluster provided in this application embodiment. Figure 3 ;

[0031] Figure 8 A schematic diagram of an optional pod scheduling device based on a Kubernetes cluster provided in an embodiment of this application;

[0032] Figure 9 This is a schematic diagram of an optional electronic device provided in an embodiment of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0035] In the following description, references to "some embodiments," "this embodiment," "this application embodiment," and examples, etc., describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0036] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] This application provides a pod scheduling method based on a Kubernetes cluster, which enables the kube-scheduler in the Kubernetes cluster to achieve diversity in scheduling data during the pod scheduling process, thereby improving the accuracy of the analysis results of the pod scheduling process.

[0038] Kubernetes (K8s) is an open-source containerized application management system for managing multiple hosts on a cloud platform. It's a container cluster management and orchestration service system whose goal is to make deploying containerized applications simple and efficient. Kubernetes provides functionality in four areas: application deployment, application planning, application updates, and application maintenance. The emergence of Kubernetes has made traditional application installation methods and virtual machine installation methods riddled with vulnerabilities. Traditional methods, such as installing applications via plugins or scripts, bind the application's lifecycle to the current operating system, which is not conducive to application upgrades, updates, and rollbacks. Creating virtual machines to implement application functionality is limited by the virtual machines themselves, hindering future migrations. Kubernetes, on the other hand, deploys containers (Pods). Each container is isolated from others, with processes not affecting each other. Furthermore, the Pod is decoupled from the underlying device and file system of the host where it is deployed, facilitating migration between different clouds and different operating system versions.

[0039] A Kubernetes cluster consists of a scheduler (Kube-scheduler), a monitor (Kube-apiserver), and pods. A pod, a group of containers within a Kubernetes cluster, is the smallest deployable computing unit that can be created and managed in Kubernetes. A pod can support multiple containers, and a pod itself is a group of containers (i.e., it includes one or more application containers that are tightly coupled together). These containers share storage resources, network resources, etc. In a Kubernetes cluster that includes different versions of operating systems, scheduling pods can enable the rapid deployment and migration of the applications contained within the pod.

[0040] Kube-scheduler is the scheduler in a Kubernetes cluster. Its role is to schedule pods to specified compute nodes based on specific scheduling algorithms and policies. Kube-scheduler allocates defined pods to nodes in the Kubernetes cluster. Factors considered when making scheduling decisions include: individual and overall resource requests, hardware / software / policy limitations, affinity and anti-affinity requirements, data locality, interference between loads, and maximizing the utilization of all cluster resources. To this end, Kube-scheduler provides a large number of policies, as well as user-defined and extended policies to meet specific needs. Kube-apiserver is a component in the Kubernetes cluster that directly interacts with ETCD (an important foundational component in cloud-native architectures), controlling changes to core resources within the Kubernetes cluster.

[0041] Currently, Kubernetes pod scheduling is primarily achieved through the core component kube-scheduler. The pod scheduling process is essentially a random selection, and after selection, the pod is deployed on the chosen physical host. During kube-scheduler's pod scheduling process, the scheduling results are often queried via command line. Therefore, the scheduling data obtained through command line is relatively limited, thus reducing the accuracy of the analysis results regarding the pod scheduling process.

[0042] This application provides a pod scheduling method based on a Kubernetes cluster, which enables diversity of scheduling data during the pod scheduling process, thereby improving the accuracy of the analysis results of the pod scheduling process. The technical solutions in this application will be clearly and completely described below with reference to the accompanying drawings.

[0043] Figure 1 A flowchart illustrating an optional pod scheduling method based on a Kubernetes cluster, as provided in this application embodiment, is shown below. Figure 1 As shown, this includes S110 to S130:

[0044] S110. During the scheduling process of the target pod, the scheduling result of the target pod is obtained by listening to the scheduling data of the target pod.

[0045] In this embodiment of the application, the cloud host in the Kubernetes cluster obtains the scheduling result of the target pod by listening to the scheduling data of the target pod during the scheduling process.

[0046] In this embodiment of the application, the Kubernetes cluster includes multiple physical hosts, each of which is deployed with Kubernetes, and one of the physical hosts serves as a cloud host to form the cluster.

[0047] In this embodiment, the cloud host of the Kubernetes cluster includes a scheduler (Kube-scheduler) and a monitor (Kube-apiserver). The Kube-scheduler is used to schedule target pods in the Kubernetes cluster, and the Kube-apiserver is used to monitor the scheduling data of the target pod scheduling process.

[0048] In this embodiment of the application, during the scheduling process of the target pod by Kube-scheduler, the scheduling data of the target pod is monitored by Kube-apiserver to obtain the scheduling result of the target pod.

[0049] In this embodiment of the application, the scheduling data (also known as resource data) of the target pod represents the scheduling result of the target pod, such as whether the scheduling was successful or failed.

[0050] S120. Based on the scheduling result of the target pod, determine the first target scheduling data of the target pod from the scheduling data record table; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod.

[0051] In this embodiment of the application, during the scheduling process of the target pod, the cloud host in the Kubernetes cluster obtains the scheduling result of the target pod by listening to the scheduling data of the target pod. Then, based on the scheduling result of the target pod, the cloud host in the Kubernetes cluster determines the first target scheduling data of the target pod from the scheduling data record table.

[0052] In this embodiment of the application, when the Kube-apiserver detects that the scheduling result of the target pod is either successful or unsuccessful, it determines the first target scheduling data of the target pod from the locally stored scheduling data record table.

[0053] In this embodiment of the application, the cloud host in the Kubernetes cluster determines the first target scheduling data of the target pod from the scheduling data record table based on the identity information of the target pod.

[0054] In this embodiment, the identity information of the target pod can be the name of the target pod, such as node1. The identity information of the target pod can also be the information related to the application deployed on the target pod, or the information related to the service deployed on the target pod. This embodiment does not impose any restrictions on the identity information of the target pod, and the specific information can be selected according to the actual application scenario.

[0055] In this embodiment of the application, the scheduling data record table stores the scheduling information of pods that have been scheduled, including the scheduling information of pods that were successfully scheduled and those that failed to be scheduled.

[0056] In this embodiment, the scheduling data record table can be stored in the local database of the cloud host, or it can be stored in an external database connected to the cloud host via hardware. Alternatively, it can be stored in the cloud connected to the cloud host via network. This embodiment does not impose any restrictions on the storage method of the scheduling data record table, and the specific method can be selected according to the actual application scenario.

[0057] In this embodiment of the application, the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod.

[0058] In this embodiment of the application, the first target scheduling data may be scheduling algorithm information related to the scheduling algorithm during the scheduling process of the target pod, execution result information related to the algorithm execution result, and node relationship information related to each node in the Kubernetes cluster.

[0059] For example, during the target pod scheduling process, the first target scheduling data may include at least one of the following: the name of the target pod, the names of each candidate node in the Kubernetes cluster (e.g., node1), information of each preset scheduling stage corresponding to each candidate node (e.g., node selection stage), information of the preset algorithms executed by each candidate node in each preset scheduling stage, information of the execution results of each preset algorithm executed by each candidate node (e.g., True or False), status information of each candidate node in the Kubernetes cluster (e.g., occupied status or idle status), hardware information of each candidate node in the Kubernetes cluster (e.g., node IP address, etc.), information related to the application deployed on the target pod, etc. This application embodiment does not impose any limitations on this, and the specific selection can be made according to the actual application scenario.

[0060] S130. Store the first target scheduling data in the scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

[0061] In this embodiment of the application, after the cloud host in the Kubernetes cluster determines the first target scheduling data of the target pod from the scheduling data record table based on the scheduling result of the target pod, the cloud host in the Kubernetes cluster stores the first target scheduling data in the scheduling data information database in order to query the scheduling status of at least one candidate node of the target pod in the scheduling process.

[0062] In this embodiment of the application, the scheduling data information library stores the scheduling data of pods that have been scheduled, including scheduling information of pods that were successfully scheduled and those that failed to be scheduled. The scheduling information of a pod represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process.

[0063] In this embodiment, the scheduling data information database can be stored locally on the cloud host, or it can be stored on an external hard drive connected to the cloud host via hardware. The scheduling data record table can also be stored in the cloud connected to the cloud host via network. This embodiment does not impose any restrictions on the storage method of the scheduling data information database, and the specific method can be selected according to the actual application scenario.

[0064] In this embodiment of the application, the scheduling data information database can be stored in the form of a database, an Excel spreadsheet, or a CSV file (Comma-Separated Values). This embodiment of the application does not impose any restrictions on this, and the specific choice can be made according to the actual application scenario.

[0065] In this embodiment of the application, the scheduling status of at least one candidate node of the target pod during the scheduling process can be determined by the first target scheduling data.

[0066] For example, by using the names of each candidate node in the Kubernetes cluster, the information of each candidate node's corresponding preset scheduling stage, the information of the preset algorithms executed by each candidate node in each preset scheduling stage, and the information of the execution results of each candidate node executing each preset algorithm in the first target scheduling data, the execution status and results of the preset algorithms executed by the candidate nodes in the Kubernetes cluster can be determined. This allows for the perception and analysis of the scheduling execution strategy of each pod, providing a basic data source for optimizing cluster scheduling analysis.

[0067] In this application embodiment, the pod scheduling method based on a Kubernetes cluster can be applied to the 4th generation mobile communication system (4G), the 5th generation wireless communication technology (5G), New Radio (NR) systems, or future communication systems. It can also be used with various other wireless communication systems, such as: Narrow Band-Internet of Things (NB-IoT) systems, Global System for Mobile Communication (GSM), Enhanced Data Rate for GSM Evolution (EDGE) systems, Wideband Code Division Multiple Access (WCDMA) systems, Code Division Multiple Access 2000 (CDMA2000) systems, Time Division-Synchronization Code Division Multiple Access (TD-SCDMA) systems, General Packet Radio Service (GPRS), Long Term Evolution (LTE) systems, and LTE Frequency Division Duplex (FDM) systems. The embodiments of this application do not impose any restrictions on systems such as FDD (Time Division Duplex), LTE (Time Division Duplex), and Universal Mobile Telecommunication System (UMTS), and can be selected according to the actual application scenario.

[0068] In this embodiment, during the scheduling of a target pod, the scheduling result of the target pod is first obtained by monitoring its scheduling data. Then, based on the scheduling result of the target pod, the first target scheduling data of the target pod is determined from the scheduling data record table. Finally, the first target scheduling data is stored in the scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

[0069] On the one hand, since the first target scheduling data includes the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod, it is possible to perceive the execution status of each node in the Kubernetes cluster during the pod scheduling process, thus realizing the diversity of scheduling data during the pod scheduling process. In this way, it provides a basic data source for optimizing cluster scheduling analysis, thereby improving the accuracy of the analysis results of the pod scheduling process.

[0070] On the other hand, by querying the scheduling status of at least one candidate node of the target pod during the scheduling process, it is possible to perceive and analyze the execution status of each node of each pod during the scheduling process, thereby obtaining the overall scheduling effect of the pod and improving the accuracy of the analysis results of the pod scheduling process.

[0071] On the other hand, by storing the first target scheduling data in the scheduling data information repository, the scheduling data during the pod scheduling process is persisted, allowing users to trace back historical data and conveniently query pod scheduling data.

[0072] In some embodiments of this application, such as Figure 2 As shown, based on Figure 1 Prior to S110, including S140 to S150:

[0073] S140. During the scheduling process of the target pod, obtain the scheduling data of at least one candidate node in the Kubernetes cluster.

[0074] In this embodiment of the application, during the scheduling process of the target pod, the cloud host in the Kubernetes cluster obtains the scheduling data of at least one candidate node in the Kubernetes cluster.

[0075] In this embodiment of the application, during the scheduling process of the target pod by Kube-scheduler, the cloud host in the Kubernetes cluster tracks the scheduling data of at least one candidate node in the Kubernetes cluster in real time.

[0076] In this embodiment of the application, the candidate node is a physical host in the Kubernetes cluster that has not been assigned a pod; that is, the candidate node is a physical host in the Kubernetes cluster that is running and in an idle state.

[0077] In this embodiment, the scheduling data of the candidate node may include at least one of the following: the name of the pod to be assigned, the name of the candidate node (e.g., node1), information of each preset scheduling stage corresponding to the candidate node (e.g., node screening stage), information of the preset algorithm executed by the candidate node in each preset scheduling stage, information of the execution result of each preset algorithm executed by each candidate node (e.g., True or False), status information of the candidate node (e.g., occupied status or idle status), hardware information of the candidate node (e.g., node IP address, etc.), information of the application deployed on the pod to be assigned, etc. This embodiment does not impose any restrictions on these, and the specific selection can be made according to the actual application scenario.

[0078] In some embodiments of this application, S140 includes S141 to S142:

[0079] S141. During the scheduling process of the target pod, obtain the first information of the target pod, the second information of at least one candidate node, the third information of at least one preset scheduling stage corresponding to at least one candidate node, the fourth information of at least one preset algorithm executed by at least one candidate node in at least one preset scheduling stage, and the fifth information of the execution result of at least one candidate node executing at least one preset algorithm.

[0080] In the embodiments of this application, during the scheduling process of the target pod by the Kube-scheduler, the cloud host in the Kubernetes cluster tracks in real time the first information of the target pod, the second information of at least one candidate node, the third information of at least one preset scheduling stage corresponding to at least one candidate node, the fourth information of at least one preset algorithm executed by at least one candidate node in at least one preset scheduling stage, and the fifth information of the execution result of at least one candidate node executing at least one preset algorithm.

[0081] In this embodiment, the first information can be the identification information of the target pod, used to identify the target pod. For example, the first information can be the name information of the target pod, such as pod1. The first information can also be the information related to the application deployed on the target pod, or the information related to the service deployed. This embodiment does not impose any restrictions on this, and the specific information can be selected according to the actual application scenario.

[0082] In this embodiment, the second information can be the identification information of the candidate node, used to identify the candidate node. For example, the second information can be the name information of the candidate node, such as node1. The second information can also be the hardware information of the candidate node, such as the IP address of the candidate node. This embodiment does not impose any restrictions on this, and the specific information can be selected according to the actual application scenario.

[0083] In this embodiment of the application, the third information may be the identification information of the preset scheduling stage in which the candidate node is located, used to identify the preset scheduling stage. For example, the third information may be the name information of the preset scheduling stage in which the candidate node is located, such as the node screening stage, the node scoring stage, and the node totaling stage.

[0084] In this embodiment of the application, the fourth information may be the identification information of the preset algorithm executed by the candidate node in the preset scheduling phase, which is used to identify the preset algorithm executed in the preset scheduling phase. For example, the fourth information may be the name information of the preset algorithm executed by the candidate node in the preset scheduling phase.

[0085] In this embodiment of the application, the fifth piece of information is the execution result information of the candidate node executing the preset algorithm in the preset scheduling phase, such as True or False.

[0086] In some embodiments of this application, the preset scheduling phase includes at least one of the following: a node screening phase, a node scoring phase, and a node totaling phase.

[0087] In this embodiment, the node filtering phase includes at least one preset algorithm (policy). Cloud hosts in the Kubernetes cluster execute the preset algorithm on currently running, idle candidate nodes. After a candidate node executes a preset algorithm, the result is either True or False. If the result is True, the candidate node passes the corresponding preset algorithm; if the result is False, the candidate node fails the corresponding preset algorithm.

[0088] In this embodiment of the application, the node scoring stage includes at least one preset algorithm (strategy). The cloud host in the Kubernetes cluster executes the preset algorithm in the node scoring stage on the candidate nodes whose execution results are all True in the node screening stage. When a candidate node executes a preset algorithm in the node scoring stage, the execution result obtained is a score.

[0089] In this embodiment of the application, the cloud host in the Kubernetes cluster selects the candidate node with the highest score from the execution results of each candidate node during the node scoring phase, and binds the target pod to the target node with the highest cumulative score.

[0090] S142. Based on the first information, the second information, the third information, the fourth information, and the fifth information, determine the scheduling data of at least one candidate node in the Kubernetes cluster.

[0091] In this embodiment of the application, the cloud host in the Kubernetes cluster uses the first information, the second information, the third information, the fourth information, and the fifth information to determine the scheduling data of at least one candidate node in the Kubernetes cluster.

[0092] S150. Based on the scheduling data of at least one candidate node, update the initial scheduling data record table to obtain the scheduling data record table.

[0093] In this embodiment of the application, during the scheduling process of the target pod, after the cloud host in the Kubernetes cluster obtains the scheduling data of at least one candidate node in the Kubernetes cluster, the cloud host in the Kubernetes cluster updates the initial scheduling data record table based on the scheduling data of at least one candidate node to obtain the scheduling data record table.

[0094] In this embodiment of the application, the cloud host in the Kubernetes cluster stores the scheduling data of at least one candidate node obtained into the initial scheduling data record table to obtain the scheduling data record table.

[0095] In this embodiment of the application, the scheduling data record table stores the scheduling information of pods that have been scheduled, including the scheduling information of pods that were successfully scheduled and those that failed to be scheduled. The scheduling data record can store the scheduling information of pods in the form of Table 1. As shown in Table 1, the scheduling information of a pod includes the pod name (P1), the scheduling stage of the node (node ​​selection stage, node scoring stage, or node totaling stage), the node name (node1), the algorithm name (algorithm 1, algorithm 2), and the algorithm execution result ("whether it passed", "score", or "total score").

[0096] Table 1

[0097] Pod name Scheduling phase Node Name Algorithm Name Algorithm execution result P1 Node selection phase node1 Algorithm 1 "Pass or fail?" P1 Node scoring phase node1 Algorithm 2 "Score" P1 Node total phase node1 none Total Score

[0098] In this embodiment of the application, the scheduling data record table can be stored in the local database of the cloud host, or it can be stored in an external database that is connected to the cloud host via hardware, or it can be stored in the cloud that is connected to the cloud host via network.

[0099] As a preferred implementation, the scheduling data record table can be stored in the local database of the cloud host.

[0100] In this embodiment, during the scheduling process of the target pod, scheduling data of at least one candidate node in the Kubernetes cluster is obtained, and the initial scheduling data record table is updated based on the scheduling data of at least one candidate node to obtain the scheduling data record table. By tracking and recording the pod scheduling process data during the scheduling process of the target pod, a data source is provided for external services, providing a prerequisite for users to perceive and analyze the scheduling process of each pod, and facilitating the querying of pod scheduling data.

[0101] In some embodiments of this application, such as Figure 3 As shown, S130 includes S131 to S133:

[0102] S131. Aggregate and process the first target scheduling data to obtain the second target scheduling data, and store the second target scheduling data in the scheduling data information database.

[0103] In this embodiment of the application, after the cloud host in the Kubernetes cluster determines the first target scheduling data of the target pod from the scheduling data record table based on the scheduling result of the target pod, the cloud host in the Kubernetes cluster aggregates and processes the first target scheduling data to obtain the second target scheduling data, and stores the second target scheduling data in the scheduling data information database.

[0104] In this embodiment of the application, the aggregation and processing of the first target scheduling data by the cloud host in the Kubernetes cluster can be understood as data integration of the first target scheduling data. Typically, the aggregation and processing process is the last step in the data processing stage. The aggregation and processing of the first target scheduling data yields concise, standardized, and clear second target scheduling data.

[0105] In this embodiment of the application, the scheduling data information database can be stored locally on the cloud host, or it can be stored on an external hard drive that is connected to the cloud host via hardware. The scheduling data record table can also be stored in the cloud that is connected to the cloud host via network.

[0106] As a preferred implementation, the scheduling data information database is a database stored locally on the cloud host.

[0107] In this embodiment, the second target scheduling data can be stored in a scheduling data information repository in the form of a database, such as a MySQL database. The second target scheduling data can also be stored in the scheduling data information repository in the form of a CSV file (Comma-Separated Values) or an Excel spreadsheet.

[0108] S132. Determine the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database.

[0109] In this embodiment of the application, the cloud host in the Kubernetes cluster aggregates and processes the first target scheduling data to obtain the second target scheduling data, and stores the second target scheduling data in the scheduling data information database. Then, the cloud host in the Kubernetes cluster determines the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database.

[0110] In this embodiment of the application, the cloud host in the Kubernetes cluster stores the scheduling data of at least one candidate node into the scheduling data information database.

[0111] In this embodiment of the application, the scheduling data information database can be understood as a database stored locally on the cloud host.

[0112] In this embodiment of the application, the second target scheduling data is the scheduling data after the first target scheduling data has been aggregated and processed. Here, the aggregation and processing can be understood as data integration of the first target scheduling data, such as data grouping or classification.

[0113] S133. Visualize the second target scheduling data to query the scheduling status of at least one candidate node in the target pod during the scheduling process.

[0114] In this embodiment of the application, after the cloud host in the Kubernetes cluster determines the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database, in order to query the scheduling status of at least one candidate node of the target pod during the scheduling process, the cloud host in the Kubernetes cluster visualizes the second target scheduling data.

[0115] In this embodiment of the application, the cloud host in the Kubernetes cluster displays the second target scheduling data of the queried target pod on the display interface of the target physical host in the Kubernetes cluster. The target physical host can be a cloud host or another physical host in the Kubernetes cluster besides a cloud host.

[0116] In this embodiment, the cloud hosts in the Kubernetes cluster can visualize the second target scheduling data in a list format. The cloud hosts in the Kubernetes cluster can also visualize the second target scheduling data graphically, such as scatter plots, two-dimensional density plots, bar charts, heatmaps, etc. The cloud hosts in the Kubernetes cluster can also visualize the second target scheduling data using color visualization. This application does not impose any limitations on this; the specific method can be chosen according to the actual application scenario.

[0117] In some embodiments of this application, S133 includes S201 to S202:

[0118] S201. Based on the second target scheduling data, determine the first information of the target pod, the second information of at least one candidate node, the third information of at least one preset scheduling stage corresponding to at least one candidate node, the fourth information of at least one preset algorithm executed by at least one candidate node in at least one preset scheduling stage, and the fifth information of the execution result of at least one candidate node executing at least one preset algorithm.

[0119] In this embodiment of the application, after the cloud host in the Kubernetes cluster obtains the second target scheduling data of the target pod from the scheduling data information database stored locally, the cloud host in the Kubernetes cluster determines the first information of the target pod, the second information of at least one candidate node, the third information of at least one preset scheduling stage corresponding to at least one candidate node, the fourth information of at least one preset algorithm executed by at least one candidate node in at least one preset scheduling stage, and the fifth information of the execution result of at least one candidate node executing at least one preset algorithm based on the second target scheduling data.

[0120] In this embodiment, the first information may be the name of the target pod, such as pod1; the second information may be the name of the candidate node, such as node1; the third information may be the name of the preset scheduling stage in which the candidate node is located, such as the node screening stage, the node scoring stage, and the node totaling stage; the fourth information may be the name of the preset algorithm executed by the candidate node in the preset scheduling stage; and the fifth information may be the execution result of the preset algorithm executed by the candidate node in the preset scheduling stage, such as True or False.

[0121] S202. Visualize the first, second, third, fourth, and fifth pieces of information in a list format to query the scheduling status of at least one candidate node in the target pod during the scheduling process.

[0122] In this embodiment of the application, after the cloud host in the Kubernetes cluster determines the first information of the target pod, the second information of at least one candidate node, the third information of at least one preset scheduling stage corresponding to at least one candidate node, the fourth information of at least one preset algorithm executed by at least one candidate node in at least one preset scheduling stage, and the fifth information of the execution result of at least one candidate node executing at least one preset algorithm based on the second target scheduling data, the cloud host in the Kubernetes cluster visualizes the first, second, third, fourth and fifth information in the form of a list on the display interface to obtain the scheduling status of at least one candidate node of the target pod during the scheduling process.

[0123] In the embodiments of this application, when cloud hosts in a Kubernetes cluster visualize the scheduling data of the second target, they may use methods including but not limited to the following: list visualization, image visualization, and color visualization.

[0124] For example, Figure 4 A schematic diagram of an optional scheduling data display interface provided in an embodiment of this application, as shown below. Figure 4 As shown, the scheduling data display interface includes the name information of candidate nodes. Figure 4 (shown as node1, node2) and the name information of the preset scheduling stage in which the candidate node is located. Figure 4 The table shows the node selection phase, node scoring phase, and node totaling phase, along with the name information of the preset algorithm executed by the candidate nodes in the preset scheduling phase. Figure 4 The algorithm is illustrated using algorithms 7, 8, 9, 10, 11, and 12. The execution results of the candidate nodes executing the preset algorithms during the preset scheduling phase are shown below. Figure 4 (As shown in Passed, 76, and 73).

[0125] like Figure 4 As shown, during the node selection phase, the candidate nodes (node1, node2) in the Kubernetes cluster execute the algorithm in the node selection phase with either Passed (True) or False. When the algorithm execution result is Passed (True), it means that the candidate node has passed (successfully) the corresponding algorithm. When the algorithm execution result is False, it means that the candidate node has failed to execute the corresponding algorithm.

[0126] like Figure 4 As shown, during the node scoring phase, the candidate nodes (node1, node2) in the Kubernetes cluster execute the algorithm in the node selection phase and receive scores (76, 73). The higher the score of the candidate node's execution algorithm, the more suitable the candidate node is for deploying the target pod to be assigned. The lower the score of the candidate node's execution algorithm, the less suitable the candidate node is for deploying the target pod to be assigned.

[0127] like Figure 4 As shown, in the node quantification phase, the execution results of the algorithm in the node selection phase are used as scores for the candidate nodes (node1, node2) in the Kubernetes cluster to obtain a comprehensive score for the candidate nodes (node1, node2). This data processing can involve the sum, median, or mean of scores, etc., and this application does not impose any limitations on this. Candidate nodes with higher comprehensive scores are more suitable for deploying the target pod to be assigned. Therefore, the physical host with the highest candidate node score is determined as the target host.

[0128] In some embodiments of this application, the scheduling process for the target pod may include S310 to S320:

[0129] S310. Select the target pod from the pod queue in a random manner; the pod queue includes at least one pod to be scheduled in the Kubernetes cluster.

[0130] In this embodiment of the application, during the scheduling process of the target pod, the cloud host in the Kubernetes cluster randomly selects the target pod from the pod queue.

[0131] In this embodiment of the application, during the scheduling of the target pod, the cloud host in the Kubernetes cluster can also specify the target pod from the pod queue and schedule it using the target pod.

[0132] In the embodiments of this application, during the scheduling of the target pod, the cloud host in the Kubernetes cluster can also specify the target pod from the pod queue according to the priority order of each pod, and schedule it using the target pod.

[0133] In this embodiment of the application, the pod queue includes at least one pod to be scheduled in the Kubernetes cluster, that is, the pod queue includes multiple pods to be scheduled.

[0134] In this embodiment of the application, when the cloud host of the Kubernetes cluster detects the arrival of the pod queue, the Kubernetes cluster randomly selects a pod (target pod) from the pod queue and sends a deployment instruction to the cloud host in the Kubernetes cluster to deploy the target pod in order to schedule the target pod.

[0135] In this embodiment, when a Kubernetes cluster has an instruction to deploy a target pod, the cloud host in the Kubernetes cluster receives the instruction and then creates the new pod according to the instruction content. The Kubernetes cluster on the cloud host deploys a Kube-scheduler, which can be understood as a core component of Kubernetes, capable of scheduling and allocating pods to be assigned physical hosts. When the Kube-scheduler in Kubernetes detects an instruction to deploy a target pod, it schedules each newly created pod that has not yet been assigned a target physical host.

[0136] S320: Based on at least one candidate node running in the Kubernetes cluster, schedule the target pod to the target node according to a preset scheduling process; the target node is one of the at least one candidate node.

[0137] In this embodiment of the application, during the scheduling process of the target pod, after the cloud host in the Kubernetes cluster determines the target pod from the pod queue, the cloud host in the Kubernetes cluster schedules the target pod to the target node based on at least one candidate node that is running in the Kubernetes cluster, according to a preset scheduling process.

[0138] In this embodiment of the application, the target node is one of at least one candidate node; in other words, the target node is one of a plurality of candidate nodes running in the Kubernetes cluster.

[0139] In this embodiment of the application, the candidate node is a physical host in the Kubernetes cluster that has not been assigned a pod; in other words, the candidate node is a physical host in the Kubernetes cluster that is running but in an idle state.

[0140] In some embodiments of this application, the preset scheduling process includes a node screening stage, a node scoring stage, and a node totaling stage.

[0141] In some embodiments of this application, S320 includes S321 to S324:

[0142] S321. Execute at least one first preset algorithm in the node selection phase sequentially on at least one candidate node that is currently running in the Kubernetes cluster.

[0143] In this embodiment of the application, during the scheduling process of the target pod, after the cloud host in the Kubernetes cluster randomly determines the target pod from the pod queue, the cloud host in the Kubernetes cluster will sequentially execute at least one first preset algorithm in the node screening phase on at least one candidate node running in the Kubernetes cluster.

[0144] In the embodiments of this application, the first preset algorithm is a pre-set algorithm or strategy.

[0145] In this embodiment of the application, the node filtering phase includes at least one preset algorithm (policy). The cloud host in the Kubernetes cluster executes the preset algorithm in the node filtering phase on the candidate nodes that are running and in an idle state. After a candidate node executes a preset algorithm in the node filtering phase, the execution result is either True or False.

[0146] S322. For at least one intermediate candidate node, if the execution result of at least one first preset algorithm is true, execute at least one second preset algorithm in the node scoring stage.

[0147] In this embodiment of the application, after the cloud host in the Kubernetes cluster executes the first preset algorithm in the node screening stage on the candidate nodes running in the Kubernetes cluster in turn, the intermediate candidate nodes whose execution results of the first preset algorithm in the node screening stage are all true are then executed on at least one second preset algorithm in the node scoring stage in turn.

[0148] In the embodiments of this application, the second preset algorithm is a pre-set algorithm or strategy.

[0149] In this embodiment of the application, the node scoring stage includes at least one preset algorithm (strategy). The cloud host in the Kubernetes cluster executes the preset algorithm in the node scoring stage on the candidate nodes whose execution results are all True in the node screening stage. When a candidate node executes a preset algorithm in the node scoring stage, the execution result obtained is a score.

[0150] S323. The score of at least one intermediate candidate node is determined by the score of the execution result of at least one second preset algorithm of at least one intermediate candidate node, according to the preset calculation method defined in the node total stage.

[0151] In this embodiment of the application, the cloud host in the Kubernetes cluster will execute at least one of the intermediate candidate nodes whose execution results of the first preset algorithm are all true in the node screening stage. After that, the cloud host in the Kubernetes cluster will execute at least one of the second preset algorithms in the node scoring stage. The scores of the execution results of each intermediate candidate node in the node scoring stage will be used to determine the comprehensive score of each intermediate candidate node in the node scoring stage according to the preset calculation method defined in the node totaling stage.

[0152] In this embodiment of the application, the preset calculation method defined in the node total stage is: to calculate the sum, median, mean, etc. of the execution results of each intermediate candidate node in the node scoring stage.

[0153] S324. From the comprehensive scores of at least one intermediate candidate node, determine the intermediate candidate node with the highest comprehensive score as the target node, and schedule the target pod to the target node.

[0154] In this embodiment of the application, the cloud host in the Kubernetes cluster determines the intermediate candidate node with the highest comprehensive score from the comprehensive scores of each intermediate candidate node in the computing node scoring stage as the target node, and schedules the target pod to the target node.

[0155] In this embodiment of the application, the cloud host in the Kubernetes cluster selects the candidate node with the highest score from the execution results of each candidate node during the node scoring phase as the target node, and binds the target pod to the target node with the highest cumulative score.

[0156] For example, Figure 5 A schematic diagram of an optional pod scheduling process provided for an embodiment of this application, as shown below. Figure 5As shown, during the scheduling process of the target pod, firstly, the cloud host in the Kubernetes cluster randomly selects the target pod from the pod queue. Then, the cloud host in the Kubernetes cluster sequentially executes at least one first preset algorithm from the node selection phase on at least one candidate node currently running in the Kubernetes cluster. For example... Figure 5 As shown, the first preset algorithm includes first preset algorithm 1 (CheckNodeUnschedulable), first preset algorithm 2 (GeneralPredicates), first preset algorithm 3 (MatchInterPodAffinity), first preset algorithm 4 (MatchNodeSelector), first preset algorithm 5 (MaxCSIVolumeCountPred), first preset algorithm 6 (NoDiskConflict), and first preset algorithm 7 (PodToleratesNodeTaints).

[0157] Subsequently, the cloud hosts in the Kubernetes cluster will execute at least one intermediate candidate node whose first preset algorithm result is true, and then execute at least one second preset algorithm in the node scoring phase. For example... Figure 5 As shown, the second preset algorithm includes second preset algorithm 1 (BalancedResourceAllocation), second preset algorithm 2 (ImageLocalityPriority), second preset algorithm 3 (InterPodAffinityPriority), second preset algorithm 4 (LeastRequestedPriority), second preset algorithm 5 (NodePreferAvoidPodsPriority), second preset algorithm 6 (SelectorSpreadPriority), and second preset algorithm 7 (TaintTolerationPriority).

[0158] Finally, the cloud host in the Kubernetes cluster with the highest comprehensive score among the intermediate candidate nodes is determined as the target node, and the target pod is scheduled to the target node.

[0159] The following describes an exemplary application of the embodiments of this application in a real-world application scenario.

[0160] This application proposes a pod scheduling method based on a Kubernetes cluster, which is applied to cloud hosts in a Kubernetes cluster. It can realize the diversity of scheduling data during the pod scheduling process, thereby improving the accuracy of the analysis results of the pod scheduling process.

[0161] Figure 6 This application provides an optional structural diagram of a cloud host in a Kubernetes cluster, as shown in the embodiments. Figure 6 As shown, cloud host 1 in the Kubernetes cluster includes a scheduling module (Kube-scheduler) 10, a listening module (Kube-apiserver) 20, a second query module (Tracker-server service) 30, a scheduling data information database (Database) 40, and a display module (Tracker-ui service) 50. The scheduling module 10 includes a node filtering module (Filtering) 11, a node scoring module (Scoring) 12, a data collection module (Tracker-agent module) 13, and a first query module (tracker-api module) 14.

[0162] In this embodiment of the application, the scheduling module (Kube-scheduler) 10 is used to randomly determine the target pod from the pod queue; based on at least one candidate node running in the Kubernetes cluster, the target pod is scheduled to the target node according to a preset scheduling process.

[0163] In this embodiment of the application, the node filtering module 11 is used to sequentially execute at least one first preset algorithm in the node filtering phase on at least one candidate node running in the Kubernetes cluster.

[0164] In this embodiment of the application, the node scoring module (Scoring) 12 is used to sequentially execute at least one second preset algorithm in the node scoring stage for at least one intermediate candidate node whose execution result of at least one first preset algorithm is true.

[0165] In this embodiment of the application, the acquisition module (Tracker-agent module) 13 is used to track the relationship data between the pod and the scheduling algorithm, algorithm results, and bound nodes in real time, and update the obtained relationship data to the scheduling data record table.

[0166] In this embodiment of the application, the first query module (tracker-api module) 14 is used to query the scheduling data of the recorded pods from the scheduling data record table and provide scheduling data query results for each pod.

[0167] In this embodiment of the application, the monitoring module (Kube-apiserver) 20 is used to monitor the resource data during the scheduling process of the pod and obtain the scheduling result of the pod.

[0168] In this embodiment of the application, the second query module (Tracker-server service) 30 queries the scheduling process data of the pod through the first query module (tracker-api module) 14 based on the scheduling result of the pod being monitored, and aggregates and processes the scheduling process data and persists it to the scheduling data information database 40.

[0169] In this embodiment, the display module (Tracker-ui service) 50 is used to query and display the scheduling process data in the scheduling data information database 40, perform summary statistics, and view the execution status of each algorithm in the pod to observe the actual scheduling effect.

[0170] In the embodiments of this application, combined with Figure 6 The cloud hosts in the Kubernetes cluster shown are, for example... Figure 7 As shown, the pod scheduling methods based on Kubernetes clusters include S401 to S406:

[0171] S401. During the scheduling process of the target pod, the cloud host's acquisition module obtains the scheduling data of at least one candidate node in the Kubernetes cluster.

[0172] In this embodiment of the application, during the scheduling process of the target pod, the cloud host's acquisition module (Tracker-agent module) 13 is used to record the relationship data between the pod and the scheduling algorithm, the algorithm results, and the bound nodes.

[0173] S402. Based on the scheduling data of at least one candidate node, the cloud host's acquisition module updates the initial scheduling data record table to obtain the scheduling data record table.

[0174] S403. During the scheduling of the target pod, the cloud host's listening module monitors the scheduling data of the target pod, and the cloud host's second query module obtains the scheduling result of the target pod.

[0175] In this embodiment of the application, the second query module (Tracker-server service) 30 of the cloud host listens to the resource data of the target pod through the listening module (Kube-apiserver) 20, and listens to the scheduling result of the target pod being scheduled successfully or unsuccessfully.

[0176] S404. Based on the scheduling result of the target pod, the second query module of the cloud host determines the first target scheduling data of the target pod from the scheduling data record table through the first query module of the cloud host.

[0177] In this embodiment of the application, when the second query module (Tracker-server service) 30 of the cloud host detects that the pod scheduling is successful or unsuccessful, the second query module (Tracker-server service) 30 queries the pod scheduling process data through the first query module (tracker-api module) 14.

[0178] S405, the second query module of the cloud host aggregates and processes the first target scheduling data to obtain the second target scheduling data, and stores the second target scheduling data in the scheduling data information database.

[0179] In this embodiment of the application, the second query module (Tracker-server service) 30 of the cloud host aggregates and processes the first target scheduling data to obtain the second target scheduling data, and stores the second target scheduling data in the scheduling data information database 40.

[0180] S406. The cloud host display module determines the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database.

[0181] In this embodiment of the application, the display module (Tracker-ui service) 50 of the cloud host determines the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database 40.

[0182] S407, the cloud host display module visualizes the second target scheduling data to query the scheduling status of at least one candidate node in the target pod during the scheduling process.

[0183] In this embodiment of the application, the cloud host's display module (Tracker-ui service) 50 queries the scheduling process data of the scheduling data information database 40 for display and performs summary statistics to view the execution status of each algorithm in the pod, thereby observing the actual scheduling effect.

[0184] In this embodiment of the application, by querying the scheduling status of at least one candidate node of the target pod during the scheduling process, it is possible to perceive and analyze the execution status of each node of each pod during the scheduling process, thereby obtaining the overall scheduling effect of the pod and improving the accuracy of the analysis results of the pod scheduling process.

[0185] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution.

[0186] Based on the foregoing embodiments, this application provides a schematic diagram of the structure of an optional pod scheduling device based on a Kubernetes cluster, as shown below. Figure 8 As shown, the pod scheduling device 500 based on a Kubernetes cluster includes a listening unit 501, an acquisition unit 502, a query unit 503, and a scheduling unit 504; wherein,

[0187] The listening unit 501 is used to obtain the scheduling result of the target pod by listening to the scheduling data of the target pod during the scheduling process of the target pod;

[0188] The acquisition unit 502 is used to determine the first target scheduling data of the target pod from the scheduling data record table based on the scheduling result of the target pod; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod.

[0189] The query unit 503 is used to store the first target scheduling data in the scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

[0190] In some embodiments of this application, the acquisition unit 502 is further configured to acquire the scheduling data of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod; and update the initial scheduling data record table based on the scheduling data of the at least one candidate node to obtain the scheduling data record table.

[0191] In some embodiments of this application, the acquisition unit 502 is further configured to acquire, during the scheduling process of the target pod, first information of the target pod, second information of the at least one candidate node, third information of the at least one preset scheduling stage corresponding to the at least one candidate node, fourth information of the at least one preset algorithm executed by the at least one candidate node in the at least one preset scheduling stage, and fifth information of the execution result of the at least one candidate node executing the at least one preset algorithm; and determine the scheduling data of the at least one candidate node in the Kubernetes cluster based on the first information, the second information, the third information, the fourth information and the fifth information.

[0192] In some embodiments of this application, the preset scheduling stage includes at least one of the following: a node screening stage, a node scoring stage, and a node totaling stage.

[0193] In some embodiments of this application, the acquisition unit 502 is further configured to aggregate and process the first target scheduling data to obtain second target scheduling data, and store the second target scheduling data in the scheduling data information database; determine the second target scheduling data of the target pod from the scheduling data of at least one pod stored in the scheduling data information database; and visualize the second target scheduling data to query the scheduling status of the at least one candidate node of the target pod during the scheduling process.

[0194] In some embodiments of this application, the acquisition unit 502 is further configured to determine, based on the second target scheduling data, the first information of the target pod, the second information of the at least one candidate node, the third information of the at least one preset scheduling stage corresponding to the at least one candidate node, the fourth information of the at least one preset algorithm executed by the at least one candidate node in the at least one preset scheduling stage, and the fifth information of the execution result of the at least one candidate node executing the at least one preset algorithm; and to visualize the first information, the second information, the third information, the fourth information, and the fifth information in a list form to query the scheduling status of the at least one candidate node of the target pod during the scheduling process.

[0195] In some embodiments of this application, the scheduling unit 504 is configured to randomly determine the target pod from the pod queue; the pod queue includes at least one pod to be scheduled in the Kubernetes cluster; based on the at least one candidate node running in the Kubernetes cluster, the target pod is scheduled to the target node according to a preset scheduling process; the target node is one of the at least one candidate node.

[0196] In some embodiments of this application, the scheduling unit 504 is further configured to: sequentially execute at least one first preset algorithm in the node screening phase on the at least one candidate node running in the Kubernetes cluster; sequentially execute at least one second preset algorithm in the node scoring phase on at least one intermediate candidate node whose execution results of the at least one first preset algorithm are all true; determine the comprehensive score of the at least one intermediate candidate node based on the scores of the at least one intermediate candidate node's execution results of the at least one second preset algorithm according to a preset calculation method defined in the node totaling phase; determine the intermediate candidate node with the highest comprehensive score from the comprehensive scores of the at least one intermediate candidate node as the target node, and schedule the target pod to the target node.

[0197] It should be noted that the module division of the Kubernetes cluster-based pod scheduling device in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or have two or more units integrated into one unit. The integrated units can be implemented in hardware, as software functional units, or a combination of software and hardware.

[0198] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0199] Figure 9 The following is a schematic diagram of an optional electronic device provided as an embodiment of this application, such as... Figure 9 As shown, this application provides an electronic device 600, including:

[0200] Processor 601, and memory 602 storing instructions executable by processor 601;

[0201] When the executable instructions are executed by the processor 601, the pod scheduling method based on the Kubernetes cluster described above is executed.

[0202] This application provides a computer storage medium storing executable instructions. When the executable instructions are executed by one or more processors, the processors execute the pod scheduling method based on a Kubernetes cluster as described in one or more of the above embodiments.

[0203] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the steps in the pod scheduling method based on a Kubernetes cluster provided in the above method embodiments.

[0204] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0205] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0206] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0207] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0208] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0209] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or modules can be electrical, mechanical, or other forms.

[0210] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0211] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0212] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0213] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0214] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0215] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0216] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0217] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A Kubernetes cluster-based pod scheduling method, characterized in that, The method includes: During the scheduling process of the target pod, the scheduling result of the target pod is obtained by listening to the scheduling data of the target pod; Based on the scheduling result of the target pod, the first target scheduling data of the target pod is determined from the scheduling data record table; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod. The first target scheduling data is stored in a scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process; Specifically, before obtaining the scheduling result of the target pod by monitoring its scheduling data during the scheduling process, the method further includes: During the scheduling process of the target pod, the following information is obtained: first information of the target pod, second information of the at least one candidate node, third information of the at least one preset scheduling stage corresponding to the at least one candidate node, fourth information of the at least one preset algorithm executed by the at least one candidate node in the at least one preset scheduling stage, and fifth information of the execution result of the at least one candidate node executing the at least one preset algorithm. Based on the first information, the second information, the third information, the fourth information, and the fifth information, the scheduling data of the at least one candidate node in the Kubernetes cluster is determined; Based on the scheduling data of the at least one candidate node, the initial scheduling data record table is updated to obtain the scheduling data record table; the scheduling data record table stores the scheduling information of pods that have been scheduled, including the scheduling information of pods that were successfully scheduled and those that failed to be scheduled.

2. The method of claim 1, wherein, The preset scheduling phase includes at least one of the following: node screening phase, node scoring phase, and node totaling phase.

3. The method of claim 1, wherein, The step of storing the first target scheduling data in a scheduling data information database to query the scheduling status of at least one candidate node of the target pod during the scheduling process includes: The first target scheduling data is aggregated and processed to obtain the second target scheduling data, and the second target scheduling data is stored in the scheduling data information database; The second target scheduling data of the target pod is determined from the scheduling data of at least one pod stored in the scheduling data information database; The second target scheduling data is visualized to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

4. The method according to claim 3, characterized in that, The step of visualizing the second target scheduling data to query the scheduling status of at least one candidate node of the target pod during the scheduling process includes: Based on the second target scheduling data, determine the first information of the target pod, the second information of the at least one candidate node, the third information of the at least one preset scheduling stage corresponding to the at least one candidate node, the fourth information of the at least one preset algorithm executed by the at least one candidate node in the at least one preset scheduling stage, and the fifth information of the execution result of the at least one candidate node executing the at least one preset algorithm. The first information, the second information, the third information, the fourth information, and the fifth information are visualized in a list format to query the scheduling status of at least one candidate node of the target pod during the scheduling process.

5. The method according to any one of claims 1-4, characterized in that, Before obtaining the scheduling result of the target pod by monitoring its scheduling data during the scheduling process, the method further includes: The target pod is determined randomly from the pod queue, which includes at least one pod to be scheduled in the Kubernetes cluster. Based on the at least one candidate node currently running in the Kubernetes cluster, the target pod is scheduled to the target node according to a preset scheduling process; the target node is one of the at least one candidate nodes.

6. The method according to claim 5, characterized in that, The preset scheduling process includes a node selection stage, a node scoring stage, and a node totaling stage. The step of scheduling the target pod to the target node according to a preset scheduling process based on the at least one candidate node currently running in the Kubernetes cluster includes: At least one first preset algorithm in the node selection phase is executed sequentially on the at least one candidate node running in the Kubernetes cluster. For at least one intermediate candidate node whose execution result of at least one first preset algorithm is true, at least one second preset algorithm in the node scoring stage is executed sequentially. The comprehensive score of the at least one intermediate candidate node is determined by the score of the execution result of the at least one second preset algorithm of the at least one intermediate candidate node, according to the preset calculation method defined in the node total stage. From the comprehensive scores of the at least one intermediate candidate node, the intermediate candidate node with the highest comprehensive score is determined as the target node, and the target pod is scheduled to the target node.

7. A pod scheduling device based on a Kubernetes cluster, characterized in that, It includes a listening unit, an acquisition unit, and a query unit; among which, The monitoring unit is used to obtain the scheduling result of the target pod by monitoring the scheduling data of the target pod during the scheduling process. The acquisition unit is used to determine the first target scheduling data of the target pod from the scheduling data record table based on the scheduling result of the target pod; the first target scheduling data represents the scheduling information of at least one candidate node in the Kubernetes cluster during the scheduling process of the target pod. The query unit is used to store the first target scheduling data of the target pod into the scheduling data information database in order to query the scheduling status of the at least one candidate node of the target pod during the scheduling process; The acquisition unit is further configured to, during the scheduling process of the target pod, acquire first information of the target pod, second information of the at least one candidate node, third information of the at least one preset scheduling stage corresponding to the at least one candidate node, fourth information of the at least one preset algorithm executed by the at least one candidate node in the at least one preset scheduling stage, and fifth information of the execution result of the at least one candidate node executing the at least one preset algorithm; determine the scheduling data of the at least one candidate node in the Kubernetes cluster based on the first information, the second information, the third information, the fourth information, and the fifth information; update the initial scheduling data record table based on the scheduling data of the at least one candidate node to obtain the scheduling data record table; the scheduling data record table stores the scheduling information of pods that have been scheduled, including the scheduling information of pods that were successfully scheduled and those that failed to be scheduled.

8. An electronic device, characterized in that, include: A processor, and a memory storing processor-executable instructions; When the executable instructions are executed by the processor, the method described in any one of claims 1 to 6 is performed.

9. A computer-readable storage medium, characterized in that, The device stores executable instructions that, when executed by one or more processors, implement the method as described in any one of claims 1 to 6.

Images