-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working with descheduler #90
Comments
The health-demo predates the nodeFit feature of the descheduler. You might want to turn nodeFit off in your descheduler configuration, and see if that helps a bit. Based on a quick look at the nodeFit implementation in the descheduler it looks to me it doesn't care about the configuration of the scheduler, and as a result, it doesn't honor the fact that the resources in question are in fact configured as ignoredByScheduler If my quick analysis above is correct, then the proper place for the issue would be at the descheduler project, which should in my opinion either honor the scheduler config somehow directly, and automatically ignore those resources (this would be nice indeed), or at least allow for configuring the same resources as ignoredByDescheduler. As a workaround, if you need to keep the nodeFit feature enabled, you might resort to what I previously told you not to do: create the extended resource for the telemetry resource by hand (curl) for the nodes. The scheduler should still be configured to ignore the resource, so it won't be consumed. Another issue which you may or may not stumble at with the descheduler node_affinity strategy is the fact that it will not deschedule anything unless there is another node ready where the pod could be scheduled to. Ref descheduler issue nr 640. Turning the nodeFit off won't help for that, unfortunately. |
Filed to the descheduler project, we'll see what the solution will be: kubernetes-sigs/descheduler#863 |
Thanks! I also noticed that the nodeFit flag is not taking effects, but good news is that posting the extended resource to all work nodes would solve the problem for now. Though it would be nice if the flag thing could be fixed later on. |
That flag is particularly confusing, as witnessed by descheduler issue number 845. Feel free to chime in, perhaps more people with the same expectations about the flag would make the maintainers reconsider the point that maybe turning the flag off should make some sort of a difference. |
hazxel, thank you to point out this, and hopefully, this can be solved within the descheduler project. |
Hi togashidm, thanks for the tip. The value can actually be any positive integer but have to be big enough right? Please correct me if I am wrong. |
yes, just big enough to get the effect. |
Hi there,
I'm using the descheduler to rescedule a pod to another node. However, the descheduler complaints that every node has insufficient resource "telemetry/scheduling", which prevent the pod being rescheduled.
(I've checked the source code of the descheduler, and it only evicts pods that don't fit the current node and fit some other nodes, see the code below from node_affinity.go)
I'm using the setting up of health-metric-demo. The logs of the descheduler are like:
In your instructions for the health-demo, the pod simply re-scheduled to another node, so I'm wondering how do you work around this problem?
Many thanks!
The text was updated successfully, but these errors were encountered: