A method and system for rescheduling oriented to kubernetes platform

Abstract

The application discloses a kind of kubernetes platform-oriented rescheduling method and system, method includes the following steps: listen and obtain abnormal pod in kubernetes cluster;Abnormal pod current node is recorded to corresponding scheduled node list;Delete abnormal pod, and submit new pod, and the scheduled node list information corresponding to abnormal pod is updated to the metadata information of corresponding new pod;In the scheduling period PreFilter stage, the computing node recorded in the metadata information of new pod is screened out, then the scheduling step after scheduling period PreFilter stage is executed, and new pod is scheduled to new computing node.The application realizes the automatic rescheduling mechanism of error pod, excludes the computing node that makes pod error before rescheduling, and improves the automatic fault tolerance capability of kubernetes platform.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a rescheduling method and system for the Kubernetes platform. Background Technology

[0002] Kubernetes, or k8s for short, is an open-source container orchestration and management tool. Figure 1 This is the architecture diagram of kube-scheduler, the default scheduler in Kubernetes. When a user submits a pod to the Kubernetes cluster, kube-scheduler selects a pod to begin scheduling. Each pod scheduling operation by kube-scheduler consists of two phases: the scheduling cycle and the binding cycle. The scheduling cycle selects a compute node for the pod, while the binding cycle binds the pod to a specific server compute node, meaning it begins running on that node. The scheduling cycle includes two filtering phases: PreFilter and Filter, which select a set of compute nodes suitable for the pod. It also includes three scoring phases: PreScore, Score, and Normalize Score, as well as Reserve and Permit phases. Ultimately, the compute node with the highest score is selected for the pod to use.

[0003] With the rapid development of cloud-native technologies represented by Kubernetes, more and more applications are running on the Kubernetes platform. As the scale of the Kubernetes platform gradually increases, the probability of application anomalies also rises, undoubtedly increasing the operational complexity of the Kubernetes platform. Changes in the external environment of the nodes mentioned above may cause pods scheduled to that node to malfunction. Currently, if kube-scheduler schedules a pod to a certain compute node and then causes it to exit due to insufficient node resources or hardware failure, resulting in a pod running incorrectly or abnormally, the pod will simply keep restarting on that compute node, and the anomaly will persist. It cannot be rescheduled by kube-scheduler to another compute node that might be suitable for the pod's normal operation. Manual operational intervention is required to reschedule the pod to another node.

[0004] In the prior art, patent application CN20221073734.1 discloses a rescheduling method when all pods are abnormal due to the abnormality of a node. The method of marking the target abnormal node with a taint mark will prevent pods from being rescheduled to that node. However, in reality, for a certain node, only a few pods may be abnormal after being scheduled to that node, while the rest of the pods can work normally after being scheduled to that node. However, marking the node with a taint mark will prevent other newly added pods from running on that node. Summary of the Invention

[0005] The technical problem to be solved by this invention is: addressing the technical problems existing in the prior art, this invention provides a rescheduling method and system for the Kubernetes platform, which implements an automatic rescheduling mechanism for faulty pods, avoiding scheduling faulty pods to the computing nodes where errors previously occurred as much as possible, thereby improving the automatic fault tolerance capability of the Kubernetes platform.

[0006] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows:

[0007] A rescheduling method for the Kubernetes platform includes the following steps:

[0008] Listen for and retrieve abnormal pods in the Kubernetes cluster;

[0009] Record the node where the abnormal pod is currently located in the corresponding list of scheduled nodes;

[0010] Delete the abnormal pod and submit a new pod. The new pod corresponds one-to-one with the abnormal pod. Update the scheduled node list information corresponding to the abnormal pod to the metadata information of the corresponding new pod.

[0011] In the pre-filtering phase of the scheduling cycle, compute nodes recorded in the metadata information of new pods are filtered out. Then, the scheduling steps after the pre-filtering phase are executed to select the compute node with the highest score from the remaining compute nodes and schedule the newly submitted pods to that compute node.

[0012] Furthermore, before listening for and acquiring abnormal pods in the Kubernetes cluster, it also includes setting the maximum number of rescheduling attempts;

[0013] After listening for and retrieving abnormal pods in the Kubernetes cluster, the following steps are also included:

[0014] Get the current scheduling count of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one, and then record the node where the abnormal pod is currently located in the corresponding scheduled node list.

[0015] If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared, and rescheduling of the abnormal pod will be stopped.

[0016] Furthermore, after listening for and obtaining abnormal pods in the Kubernetes cluster, the process also includes: obtaining the reason for the abnormality from the target field of the abnormal pod; if the reason for the abnormality is scheduling failure, then clearing the list of scheduled nodes corresponding to the abnormal pod, deleting the abnormal pod, and submitting a new pod.

[0017] Furthermore, after deleting the problematic pod and committing a new pod, the process also includes:

[0018] If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod.

[0019] If the list of scheduled nodes corresponding to an abnormal pod is empty, then keep the metadata information of the corresponding new pod empty.

[0020] Furthermore, before filtering out compute nodes recorded in the metadata information of new pods, the following steps are taken:

[0021] If the metadata information of the new pod is empty, execute the scheduling steps after the pre-filtering phase of the scheduling cycle;

[0022] If the metadata information of the new pod is not empty, perform a filter to exclude the compute nodes recorded in the metadata information of the new pod.

[0023] This invention also proposes a rescheduling system for the Kubernetes platform, comprising:

[0024] The rescheduling system controller module is used to monitor and obtain abnormal pods in the Kubernetes cluster; record the node where the abnormal pod is currently located in the corresponding scheduled node list; delete the abnormal pod and update the metadata information of the corresponding new pod with the scheduled node list information of the abnormal pod; and after the scheduling plugin module filters and excludes the compute nodes recorded in the metadata information of the new pod, it performs the scheduling steps after the scheduling cycle pre-filtering stage, selects the compute node with the highest score from the remaining compute nodes, and schedules the newly submitted pod to that compute node.

[0025] The pod controller is used to commit a new pod after the corresponding abnormal pod is deleted, with each new pod corresponding to an abnormal pod in a one-to-one manner.

[0026] The scheduling plugin module is used to filter and exclude compute nodes recorded in the metadata information of new pods during the pre-filtering phase of the scheduling cycle.

[0027] Furthermore, the metadata.annotations field in the pod's controller configuration file is configured with a maximum rescheduling count parameter, scheduling-retires.

[0028] The rescheduling system controller module, after listening for and identifying abnormal pods in the Kubernetes cluster, is also configured to execute:

[0029] Use the ListFunc plugin to get the current scheduling count recorded in the metadata of the controller of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one, and then record the node where the abnormal pod is currently located in the scheduled node list of the metadata in the corresponding controller.

[0030] If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared, and rescheduling of the abnormal pod will be stopped.

[0031] Furthermore, after the rescheduling system controller module listens for and obtains abnormal pods in the Kubernetes cluster, it is also configured to perform the following: obtain the reason for the abnormality from the target field of the abnormal pod; if the reason for the abnormality is scheduling failure, then clear the list of scheduled nodes corresponding to the abnormal pod and delete the abnormal pod.

[0032] Furthermore, after deleting the abnormal pod, the rescheduling system controller module is also configured to perform:

[0033] Use the MutateWebHook plugin to intercept all newly submitted pods in the cluster;

[0034] If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod.

[0035] If the list of scheduled nodes corresponding to an abnormal pod is empty, then keep the metadata information of the corresponding new pod empty.

[0036] Furthermore, before the scheduling plugin module filters and excludes the compute nodes recorded in the metadata information of new pods, the rescheduling system controller module is also configured to execute:

[0037] If the metadata information of the new pod is empty, execute the scheduling steps after the pre-filtering phase of the scheduling cycle;

[0038] If the metadata information of the new pod is not empty, wait for the scheduling plugin module to filter and exclude the compute nodes recorded in the metadata information of the new pod.

[0039] Compared with the prior art, the advantages of the present invention are as follows:

[0040] 1. By monitoring abnormal pods in the cluster, a pod rescheduling mechanism is implemented to avoid scheduling pods to compute nodes where previous pods encountered errors, thereby improving the system's automatic fault tolerance and service availability.

[0041] 2. Set a maximum number of rescheduling attempts. If the number of rescheduling attempts for an abnormal pod exceeds the maximum number of rescheduling attempts, no further rescheduling attempts will be made to prevent continuous rescheduling from consuming cluster resources. Attached Figure Description

[0042] Figure 1 This is an architecture diagram of kube-scheduler, the default scheduler for Kubernetes.

[0043] Figure 2 This is an overall design diagram of an embodiment of the present invention.

[0044] Figure 3 This is a flowchart of a method according to an embodiment of the present invention.

[0045] Figure 4 This is a schematic diagram illustrating an example of the execution of an embodiment of the present invention. Detailed Implementation

[0046] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0047] Before introducing specific embodiments of the present invention, relevant concepts will be explained.

[0048] K8s: Also known as Kubernetes, or simply k8s, is an open-source container orchestration and management tool.

[0049] Pod: The smallest control unit in Kubernetes, used to host and run actual applications. It is also the smallest scheduling unit in Kubernetes. A Pod can also start and run independently without being controlled by a controller in Kubernetes.

[0050] Deployment: A controller in Kubernetes used to control the number of replicas of a pod and the specific configuration information of the pod.

[0051] ReplicaSet: A controller in Kubernetes, similar in function to Deployment.

[0052] StatefulSet: A controller in Kubernetes, similar in function to Deployment.

[0053] CronJob: A controller in Kubernetes, similar in function to Deployment.

[0054] Job: A controller in Kubernetes, similar in function to Deployment.

[0055] Kube-scheduler: The default scheduler in Kubernetes, a component in Kubernetes used to schedule pods to a specific server node.

[0056] PreFilter: A scheduling phase in the kube-scheduler scheduler used to filter and select server nodes.

[0057] Kylin-rescheduler: The rescheduling system controller module.

[0058] ListFunc: A plugin for the kylin-rescheduler rescheduling system controller module, used to monitor abnormal pods in Kubernetes and automatically perform related operations on abnormal pods.

[0059] MutateWebHook: A plugin for the kylin-rescheduler rescheduling system controller module, used to intercept pod creation requests submitted in a Kubernetes cluster and modify the metadata information of these submitted pods.

[0060] Podrescheduling: A scheduling control plugin developed based on the PreFilter phase in the kube-scheduler scheduler, used to filter and select server nodes.

[0061] Example 1

[0062] like Figure 2 As shown, to implement an automatic rescheduling mechanism for faulty pods and avoid scheduling faulty pods to the compute nodes where errors previously occurred, thereby improving the automatic fault tolerance capability of the Kubernetes platform, this embodiment develops a Podrescheduling plugin in the PreFilter stage of kube-scheduler. This plugin pre-filters and selects compute nodes for use in subsequent steps. This embodiment proposes a rescheduling method for the Kubernetes platform, the overall idea of ​​which is as follows:

[0063] S1. Configure the maximum number of rescheduling attempts parameter in the pod or the pod controller;

[0064] S2. Use the ListFunc plugin to monitor abnormal pods in the cluster and perform related operations on them;

[0065] S3. Use the MutateWebHook plugin to modify the metadata information of the pod;

[0066] S4 and kube-scheduler schedule pods;

[0067] S5 and pods start up and run normally.

[0068] In this embodiment, step S1 is implemented using the following method:

[0069] S11. Write configuration files for pods or pod controllers (such as Deployment, Replicaset, Statefulset, CronJob, Job);

[0070] S12. Configure the scheduling-retires parameter, which is the maximum number of rescheduling attempts, in the metadata.annotations field of the pod or pod controller (such as Deployment, Replicaset, Statefulset, CronJob, Job) configuration file.

[0071] In this embodiment, step S2 is implemented using the following method:

[0072] S21. Monitor pods in the cluster that are in an abnormal state and obtain these abnormal pods;

[0073] S22. For each abnormal pod, check the current scheduling count recorded in the metadata of the controller corresponding to that pod using the ListFunc plugin. The specific method is as follows:

[0074] S221. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count recorded in the metadata of the controller corresponding to the pod by 1, record the node where the pod is currently located in the scheduled node list in the metadata of the controller corresponding to the pod, and delete the pod.

[0075] S222. If the current scheduling count is greater than the maximum rescheduling count, no more rescheduling attempts will be made to prevent continuous rescheduling from consuming cluster resources. In this case, the current scheduling count recorded in the metadata of the controller corresponding to the pod will remain unchanged, and the list of scheduled nodes recorded in the metadata of the controller corresponding to the pod will be cleared.

[0076] S23. Obtain the record fields of the abnormal pod to analyze the cause of the abnormality. If the reason for the current pod's abnormality is scheduling failure, clear the list of scheduled nodes in the metadata record of the pod's corresponding controller and delete the pod. In the default design of the Kubernetes platform, pods have rich fields to record whether the pod is abnormal. By obtaining the information in these fields, the specific cause of the abnormality can be obtained.

[0077] S24. After a pod is deleted, the controller corresponding to the pod will automatically resubmit a new pod. Deleting a pod will immediately trigger its rescheduling. Using our developed scheduling plugin module, podrescheduling, nodes that previously caused the pod to malfunction are filtered out. Then, the default scheduler performs the scheduling operation, scheduling the pod to a suitable node. This process is fully automated.

[0078] In this embodiment, step S3 is implemented using the following method:

[0079] S31. Use the MutateWebHook plugin to intercept all newly submitted pods in the cluster;

[0080] S32. Determine if the list of scheduled nodes in the metadata record of the controller corresponding to the pod is empty. If it is not empty, proceed to the next step; otherwise, do not perform any processing.

[0081] S33. Update the scheduled node list information in the metadata record of the controller corresponding to the pod to the metadata information of the pod.

[0082] In this embodiment, step S4 is implemented using the following method:

[0083] S41. Determine if the pod metadata information is empty. If it is not empty, proceed to the next step; otherwise, proceed to step S43.

[0084] S42. Filter out the compute nodes that have been scheduled as recorded in the pod metadata information;

[0085] S43. The pod enters the subsequent steps of kube-scheduler scheduling. The subsequent steps specifically refer to the scheduling steps after the PreFilter stage of the scheduling cycle mentioned above: that is, through the Filter stage, the three scoring stages of PreScore, Score and Normalize Score, and the Reserve and Permit stages, the highest-scoring compute node is finally selected for the pod to use.

[0086] S44: The pod obtains information about which compute node it needs to be scheduled to.

[0087] S45, the pod is scheduled to this compute node;

[0088] S46, pod completes scheduling.

[0089] In cases where changes in the external environment of a node cause pods originally scheduled to that node to malfunction, we can use the above approach to delete the abnormal pods on that node to trigger their rescheduling. During the PreFilter phase, we count the nodes that have been scheduled for that pod and have experienced anomalies. In the PreFilter phase, these nodes that have experienced anomalies are filtered out, thus preventing the rescheduling of nodes that have experienced anomalies.

[0090] Based on the above ideas, such as Figure 3 As shown, the rescheduling method for the Kubernetes platform in this embodiment includes the following steps:

[0091] S101) Set the maximum number of rescheduling attempts;

[0092] S201) Listen for and retrieve abnormal pods in the Kubernetes cluster;

[0093] Get the current scheduling count of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one and execute step S301.

[0094] If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared and rescheduling of the abnormal pod will be stopped.

[0095] Obtain the reason for the exception from the target field of the exception pod. If the reason for the exception is scheduling failure, clear the list of scheduled nodes corresponding to the exception pod and execute step S401.

[0096] S301) Record the node where the abnormal pod is currently located in the corresponding list of scheduled nodes;

[0097] S401) Delete the abnormal pod and commit a new pod, with each new pod corresponding to the abnormal pod;

[0098] If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod.

[0099] If the list of scheduled nodes corresponding to the abnormal pod is empty, then keep the metadata information of the corresponding new pod empty;

[0100] S501) If the metadata information of the new pod is empty, execute the scheduling steps after the PreFilter stage of the scheduling cycle, select the compute node with the highest score from all compute nodes, and schedule the newly submitted pod to that compute node.

[0101] If the metadata information of the new pod is not empty, the compute nodes recorded in the metadata information of the new pod are filtered out during the PreFilter phase of the scheduling cycle. The scheduling steps after the PreFilter phase of the scheduling cycle are executed, the compute node with the highest score is selected from the remaining compute nodes, and the newly submitted pod is scheduled to that compute node.

[0102] (S601) The newly submitted pod starts running normally on the new compute node that is scheduled.

[0103] The method of this embodiment will be further explained below with specific examples, such as Figure 4 As shown, in a specific instance, the Kubernetes platform's deployment controller is used to control pods. The maximum number of rescheduled pods is configured in the deployment. The steps for rescheduling pods in this specific instance are as follows:

[0104] Step 1: According to the aforementioned step S101, configure the maximum number of scheduling retries parameter scheduling-retries in the metadata.annotations field of the deployment, for example, with a value of 3 times;

[0105] Step 2: According to the aforementioned step S201, if an error occurs during the operation of the pod controlled by the deployment, resulting in an exception, it will be detected by the ListFunc plugin;

[0106] Step 3: According to step S201 above, the ListFunc plugin determines whether the currentReschedulingTimes (current scheduling count) in the deployment controller corresponding to the abnormal pod is less than scheduling-retries. If it is less, according to step S301 above, the metadata information of the deployment controller is updated, namely the currentReschedulingTimes (current scheduling count plus 1) and deploymentScheduledHosts (a list of nodes where the abnormal pod is currently located) in the kylincloud.com / deploy field.

[0107] Step 4: According to the aforementioned step S401, ListFunc deletes the abnormal pod and triggers the deployment controller to resubmit a new pod to the cluster;

[0108] Step 5: According to the aforementioned step S401, the MutateWebHook plugin modifies the metadata information of the newly submitted pod to the cluster, namely the value of the kylincloud.com / scheduled-hosts field, which is the same as the deployScheduledHosts value of the deployment controller.

[0109] Step 6: Based on the aforementioned step S501, the Podrescheduling plugin filters out compute node information recorded in the kylincloud.com / scheduled-hosts field of the pod to prevent the pod from being scheduled to these compute nodes that could cause pod malfunctions.

[0110] Step 7: Following the aforementioned step S601, the pod begins attempting to start running on a new compute node.

[0111] Example 2

[0112] This embodiment proposes a rescheduling system for the Kubernetes platform, including:

[0113] The rescheduling system controller module, namely kylin-rescheduler, is used to monitor abnormal pods in the cluster, delete abnormal pods, and modify the metadata information of pods.

[0114] Specifically, the rescheduling system controller module in this embodiment is used to monitor and obtain abnormal pods in the Kubernetes cluster; record the node where the abnormal pod is currently located in the corresponding scheduled node list; delete the abnormal pod and update the scheduled node list information corresponding to the abnormal pod to the metadata information of the corresponding new pod; and after the scheduling plugin module filters and excludes the compute nodes recorded in the metadata information of the new pod, it executes the scheduling steps after the PreFilter stage of the scheduling cycle, selects the compute node with the highest score from the remaining compute nodes, and schedules the newly submitted pod to that compute node.

[0115] The pod controller can be the deployment controller of the Kubernetes platform, which is used to control pods. After the corresponding abnormal pod is deleted, a new pod is committed, and the new pod corresponds one-to-one with the abnormal pod.

[0116] The scheduling plugin module, namely podrescheduling, is a scheduling control plugin developed based on the PreFilter phase of the kube-scheduler scheduler. It is used to filter and exclude compute nodes recorded in the metadata information of new pods during the PreFilter phase of the scheduling cycle.

[0117] In this embodiment, the metadata.annotations field in the pod's controller configuration file is configured with the maximum number of rescheduling attempts parameter scheduling-retires;

[0118] Corresponding to step S201 in Embodiment 1, in this embodiment, after the rescheduling system controller module listens for and obtains abnormal pods in the Kubernetes cluster, it is further configured to execute:

[0119] Use the ListFunc plugin to get the current scheduling count recorded in the metadata of the controller of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one, and then record the node where the abnormal pod is currently located in the scheduled node list of the metadata in the corresponding controller.

[0120] If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared and rescheduling of the abnormal pod will be stopped.

[0121] Get the reason for the exception from the target field of the malfunctioning pod. If the reason for the exception is scheduling failure, clear the list of scheduled nodes corresponding to the malfunctioning pod and delete the malfunctioning pod.

[0122] Corresponding to step S401 in Embodiment 1, in this embodiment, after deleting the abnormal pod, the rescheduling system controller module is also configured to execute:

[0123] Use the MutateWebHook plugin to intercept all newly submitted pods in the cluster;

[0124] If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod.

[0125] If the list of scheduled nodes corresponding to an abnormal pod is empty, then keep the metadata information of the corresponding new pod empty.

[0126] Corresponding to step S501 in Embodiment 1, in this embodiment, the rescheduling system controller module is further configured to execute the following before the scheduling plug-in module filters and excludes the compute nodes recorded in the metadata information of the new pod:

[0127] If the new pod's metadata is empty, execute the scheduling steps after the PreFilter phase of the scheduling cycle;

[0128] If the metadata information of the new pod is not empty, wait for the scheduling plugin module to filter and exclude the compute nodes recorded in the metadata information of the new pod.

[0129] In summary, this invention implements a rescheduling method and system for the Kubernetes platform. It monitors abnormal pods within the Kubernetes platform and automatically reschedules them, allowing pods to restart and run normally in remote locations. During the pod rescheduling process, the podrescheduling plugin of kube-scheduler (in the PreFilter phase) excludes compute nodes that previously caused the pod to fail, thus minimizing the chance of scheduling to the compute nodes that caused the pod's failure. This improves the platform's automatic fault tolerance, enhances service high availability, and reduces manual maintenance operations.

[0130] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

Claims

1. A rescheduling method for the Kubernetes platform, characterized in that, Includes the following steps: Listen for and retrieve abnormal pods in the Kubernetes cluster; Record the node where the abnormal pod is currently located in the corresponding list of scheduled nodes; Delete the abnormal pod and submit a new pod. The new pod corresponds one-to-one with the abnormal pod. Update the scheduled node list information corresponding to the abnormal pod to the metadata information of the corresponding new pod. In the pre-filtering stage of the scheduling cycle, compute nodes recorded in the metadata information of new pods are filtered out, so that the excluded compute nodes do not participate in the scoring of the scheduling steps after the pre-filtering stage. Then, the scheduling steps after the pre-filtering stage are executed, and the compute node with the highest score is selected from the remaining compute nodes, and the newly submitted pod is scheduled to that compute node.

2. The rescheduling method for the Kubernetes platform according to claim 1, characterized in that, Before listening for and acquiring abnormal pods in the Kubernetes cluster, the following steps are also included: setting the maximum number of rescheduling attempts; After listening for and retrieving abnormal pods in the Kubernetes cluster, the following steps are also included: Get the current scheduling count of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one, and then record the node where the abnormal pod is currently located in the corresponding scheduled node list. If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared, and rescheduling of the abnormal pod will be stopped.

3. The rescheduling method for the Kubernetes platform according to claim 1, characterized in that, After listening for and obtaining abnormal pods in the Kubernetes cluster, the process also includes: obtaining the reason for the abnormality from the target field of the abnormal pod; if the reason for the abnormality is scheduling failure, clearing the list of scheduled nodes corresponding to the abnormal pod, deleting the abnormal pod, and submitting a new pod.

4. The rescheduling method for the Kubernetes platform according to claim 3, characterized in that, After deleting the problematic pod and committing a new pod, the following steps are also included: If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod. If the list of scheduled nodes corresponding to an abnormal pod is empty, then keep the metadata information of the corresponding new pod empty.

5. The rescheduling method for the Kubernetes platform according to claim 4, characterized in that, Before filtering out compute nodes recorded in the metadata information of new pods, the following steps are taken: If the metadata information of the new pod is empty, execute the scheduling steps after the pre-filtering phase of the scheduling cycle; If the metadata information of the new pod is not empty, perform a filter to exclude the compute nodes recorded in the metadata information of the new pod.

6. A rescheduling system for the Kubernetes platform, characterized in that, include: The rescheduling system controller module is used to monitor and obtain abnormal pods in the Kubernetes cluster; record the node where the abnormal pod is currently located in the corresponding scheduled node list; delete the abnormal pod and update the metadata information of the corresponding new pod in the scheduled node list information of the abnormal pod. It is also used to perform the scheduling steps after the scheduling cycle pre-filtering stage after the scheduling plugin module filters out the compute nodes recorded in the metadata information of new pods, select the compute node with the highest score from the remaining compute nodes, and schedule the newly submitted pod to that compute node. The pod controller is used to commit a new pod after the corresponding abnormal pod is deleted, with each new pod corresponding to an abnormal pod in a one-to-one manner. The scheduling plugin module is used to filter and exclude compute nodes recorded in the metadata information of new pods during the pre-filtering phase of the scheduling cycle.

7. The rescheduling system for the Kubernetes platform according to claim 6, characterized in that, The pod's controller configuration file contains a `metadata.annotations` field with a maximum rescheduling count parameter `scheduling-retires`. The rescheduling system controller module, after listening for and identifying abnormal pods in the Kubernetes cluster, is also configured to execute: Use the ListFunc plugin to get the current scheduling count recorded in the metadata of the controller of the abnormal pod. If the current scheduling count is less than the maximum rescheduling count, increment the current scheduling count by one, and then record the node where the abnormal pod is currently located in the scheduled node list of the metadata in the corresponding controller. If the current number of rescheduling attempts is greater than or equal to the maximum number of rescheduling attempts, the list of scheduled nodes corresponding to the abnormal pod will be cleared, and rescheduling of the abnormal pod will be stopped.

8. The rescheduling system for the Kubernetes platform according to claim 6, characterized in that, After the rescheduling system controller module listens for and obtains abnormal pods in the Kubernetes cluster, it is also configured to perform the following: obtain the reason for the abnormality from the target field of the abnormal pod; if the reason for the abnormality is scheduling failure, clear the list of scheduled nodes corresponding to the abnormal pod and delete the abnormal pod.

9. The rescheduling system for the Kubernetes platform according to claim 8, characterized in that, After deleting the abnormal pod, the rescheduling system controller module is also configured to perform: Use the MutateWebHook plugin to intercept all newly submitted pods in the cluster; If the list of scheduled nodes corresponding to the abnormal pod is not empty, then the information of the list of scheduled nodes corresponding to the abnormal pod will be updated to the metadata information of the corresponding new pod. If the list of scheduled nodes corresponding to an abnormal pod is empty, then keep the metadata information of the corresponding new pod empty.

10. The rescheduling system for the Kubernetes platform according to claim 9, characterized in that, Before the scheduling plugin module filters and excludes the compute nodes recorded in the metadata information of new pods, the rescheduling system controller module is also configured to execute: If the metadata information of the new pod is empty, execute the scheduling steps after the pre-filtering phase of the scheduling cycle; If the metadata information of the new pod is not empty, wait for the scheduling plugin module to filter and exclude the compute nodes recorded in the metadata information of the new pod.

Images