node's labels doesn't contain the required topologyKeys in `Constraints`
cannot be resolved by preempting the pods on that pods.
One use case that could easily reproduce the issue is,
- set `alwaysCheckAllPredicates` to true.
- one node contains all the required topologyKeys but is failed in predicates
such as 'taint'.
- another node doesn't hold all the required topologyKeys, and thus return `Unschedulable`
status code.
- scheduler will try to preempt the pods on the above node with lower priorities.
Signed-off-by: Dave Chen <dave.chen@arm.com>
Refactor genericScheduler and signature of preemption funcs
- remove podNominator from genericScheduler
- simplify signature of preemption functions
Make Preempt() private
Previously, separate interfaces were defined for Reserve and Unreserve
plugins. However, in nearly all cases, a plugin that allocates a
resource using Reserve will likely want to register itself for Unreserve
as well in order to free the allocated resource at the end of a failed
scheduling/binding cycle. Having separate plugins for Reserve and
Unreserve also adds unnecessary config toil. To that end, this patch
aims to merge the two plugins into a single interface called a
ReservePlugin that requires implementing both the Reserve and Unreserve
methods.
- Add a defaultpreemption PostFilter plugin
- Make g.Preempt() stateless
- make g.Preempt() stateless
- make g.getLowerPriorityNominatedPods() stateless
- make g.processPreemptionWithExtenders() stateless
`DefaultPodTopologySpread` need't score when the `TopologySpreadConstraints`
is specified.
`PreScore` needn't do this as well, this cut off the cost of `PreScore` if
possible.
Signed-off-by: Dave Chen <dave.chen@arm.com>
This make it easier to catch the issue during the compilation, also,
this also align with other plugins, i.e. plugin of "InterPodAffinity".
Signed-off-by: Dave Chen <dave.chen@arm.com>
This new approach results in better spreading for small number of pods, while still giving meaning to the maxSkew parameter.
Signed-off-by: Aldo Culquicondor <acondor@google.com>
Given the assumption that 90% of images on dockerhub drops into this range (23~1000)MB,
this assumption is based on the container images instead of the pod.
pod might hold multiple container images, it's better to multiply the assumption by the size
of container images.
Signed-off-by: Dave Chen <dave.chen@arm.com>
`BuildArgs` is not used anywhere and the `args` can be directly got from
the instance instead of defining a method to do that.
Signed-off-by: Dave Chen <dave.chen@arm.com>
