Reclaim Enhancement: The logic of judging whether a pod can be evicted and judging whether a queue is overused in proportion is inconsistent, which may lead to ping-pong during reclaim action #561
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
/kind feature
enabel
reclaim
actioncreate job1 with 7pods, each pod with 1c1g resource request
expected that six pods of job1 were evicted, actually, all pods of job1 were evicted
in the next loop, the queue of job1 was not overused, and pods of job1 were traversed to dispatch. Eventually, one of the pods was scheduled successfully, however, the pod will be evicted during reclaim action
pods of job1 were evicted
allocate
andreclaim
pending
, and pods of job2 were allRunning
proportion
plugin,LessEqual
function was used to compare the sizes of deserved resource and allocated resources. Since the weight ofdefault
queue is too small that the deserve resource ofdefault
queue is very little, about <cpu: 0.08, memory 159045.22>. When there are one pod left indefault
queue, the allocated resources of queue is <cpu: 1000, memory: 1073741824>, if the pod was evicted, the allocated resources ofdefault
queue will be <cpu: 0, memory: 0>. <cpu: 0.08, memory: 159045>.LessEqual<cpu: 0, memory: 0> will return true, the pod was added to victims to be evicted.allocate
action, when judging whether a queue is overused, the loggic is as belowsince allocated resource of
default
queue is <cpu: 0, memory: 0>, deserved resouces ofdefault
queue is <cpu: 0.08, memory: 159045>, <cpu: 0, memory: 0>.LessEqual( <cpu: 0.08, memory: 159045>) is true, overused wasfalse
, pods under thedefault
queue were traversed to dispatch.The text was updated successfully, but these errors were encountered: