cluster/gce/gci: Support passing kube-scheduler policy config #57425
Conversation
k8s-ci-robot
added
release-note-none
|
@yguo0905: GitHub didn't allow me to request PR reviews from the following users: bobbypage. Note that only kubernetes members can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cc @bsalamat |
| @@ -1880,6 +1888,11 @@ function start-kube-scheduler { | |||
| if [[ -n "${SCHEDULING_ALGORITHM_PROVIDER:-}" ]]; then | |||
| params+=" --algorithm-provider=${SCHEDULING_ALGORITHM_PROVIDER}" | |||
| fi | |||
| if [[ -n "${SCHEDULER_POLICY_CONFIG:-}" ]]; then | |||
| create-kubescheduler-policy-config | |||
| params+=" --use-legacy-policy-config" | |||
There was a problem hiding this comment.
Why don't we create a ConfigMap object instead?
There was a problem hiding this comment.
I mentioned this in the reviewer note. kube-scheduler requires the ConfigMap to be set before it starts but it's not easy to so in GKE.
There was a problem hiding this comment.
Oh, sorry that I missed that in the reviewer note.
The reason that I think using a ConfigMap is better is that we are thinking about deprecating the config file. If you set the flag (--policy-configmap) when starting the scheduler and the ConfigMap is not found, scheduler will refuse to start. I assume our cluster bring up (or kubelet) will retry to run the scheduler again and this will be repeated until the ConfigMap is there.
There was a problem hiding this comment.
Per discussion offline, requiring a ConfigMap to be present before the scheduler starts introduces a dependency on etcd/apiserver and whichever component that should post the ConfigMap. There is currently no guarantee on the creation ordering of various components during cluster creation, and it's not deal to let the scheduler keep restarting before the config is available in this case, so we decided to use the file for now.
|
This is fine for now, but please be aware that we may deprecate the flag in the future. /lgtm |
k8s-ci-robot
added
the
lgtm
|
/test pull-kubernetes-e2e-kops-aws |
|
/approve no-issue |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bowei, bsalamat, yguo0905 Associated issue requirement bypassed by: bowei The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
k8s-ci-robot
added
the
approved
|
Automatic merge from submit-queue (batch tested with PRs 57906, 57425, 56939, 57317, 57762). If you want to cherry-pick this change to another branch, please follow the instructions here. |
k8s-ci-robot
added
release-note
…25-upstream-release-1.9 Automatic merge from submit-queue. Automated cherry pick of #57425: Support passing kube-scheduler policy config Cherry pick of #57425 on release-1.9. #57425: Support passing kube-scheduler policy config ```release-note GCE: support passing kube-scheduler policy config via SCHEDULER_POLICY_CONFIG ```
What this PR does / why we need it:
This allows us to specify a customized scheduler policy configuration.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
I'm aware of the ConfigMap but passing a file is much simpler in our case.
This PR is low risk, we will want to cherry pick this into 1.9.
Release note: