Why Can't a Workload Be Distributed When the Scheduling Policy Is in Lazy Mode?
Symptom
- After a workload is created using kubectl, you have created a scheduling policy (PropagationPolicy or ClusterPropagationPolicy) that will be applied later (in lazy mode), but the workload is not distributed due to the lazy mode.
- After the scheduling policy created in 1 is deleted and a scheduling policy (PropagationPolicy or ClusterPropagationPolicy) that will be applied immediately (not in lazy mode) is created, the workload is still not distributed as expected.
Possible Cause
After a workload is created, it enters Karmada's waiting queue. After a lazy-mode scheduling policy is created, the workload is removed from the waiting queue and bound to the scheduling policy. However, no ResourceBinding is generated. In Karmada, when a scheduling policy is deleted, the ResourceBinding is queried first, and then the workload. As a result, the workload cannot be deleted or enter the waiting queue. This means the lazy-mode scheduling policy cannot be completely deleted. When a non-lazy-mode scheduling policy is created, the workload is not in the waiting queue. In this case, the workload cannot be bound to the new scheduling policy immediately. The workload can be bound to the new scheduling policy and distributed only when it changes.
Solution
Modify the parameters in the YAML file of the workload to change the workload and trigger the scheduling. For example, you can add labels and annotations to the workload and redeploy the workload to trigger scheduling.
Operation Example
- Create a scheduling policy that will be applied effect later.
- Create a workload.
- Verify that the workload has been distributed.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot