From 0d3c7166519b635e1314a0a349eec6aaf8a4d7c9 Mon Sep 17 00:00:00 2001 From: mqliang Date: Fri, 27 Nov 2015 23:00:31 +0800 Subject: [PATCH] optimize priority functions --- docs/proposals/multiple-schedulers.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/proposals/multiple-schedulers.md b/docs/proposals/multiple-schedulers.md index 51466008a43..4fadd6010a2 100644 --- a/docs/proposals/multiple-schedulers.md +++ b/docs/proposals/multiple-schedulers.md @@ -152,6 +152,12 @@ which the client has set a scheduler annotation that does not correspond to a ru 2. Dynamic launching scheduler(s) and registering to admission controller (as an external call). This also requires some work on authorization and authentication to control what schedulers can write the /binding subresource of which pods. +3. Optimize the behaviors of priority functions in multi-scheduler scenario. In the case where multiple schedulers have +the same predicate and priority functions (for example, when using multiple schedulers for parallelism rather than to +customize the scheduling policies), all schedulers would tend to pick the same node as "best" when scheduling identical +pods and therefore would be likely to conflict on the Kubelet. To solve this problem, we can pass +an optional flag such as `--randomize-node-selection=N` to scheduler, setting this flag would cause the scheduler to pick +randomly among the top N nodes instead of the one with the highest score. ## Other issues/discussions related to scheduler design