-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
scheduler: move percentagesOfNodesToScore to the scheduler profile #97263
scheduler: move percentagesOfNodesToScore to the scheduler profile #97263
Conversation
@SataQiu: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: SataQiu The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
0d253ac
to
6cc9bf8
Compare
/assign |
pkg/scheduler/apis/config/types.go
Outdated
// Example: if the cluster size is 500 nodes and the value of this flag is 30, | ||
// then scheduler stops finding further feasible nodes once it finds 150 feasible ones. | ||
// When the value is 0, the PercentageOfNodesToScore in the top-level KubeSchedulerConfiguration | ||
// will be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth re-stating here too that this will override the top-level configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
if numAllNodes < minFeasibleNodesToFind || g.percentageOfNodesToScore >= 100 { | ||
func (g *genericScheduler) numFeasibleNodesToFind(fwk framework.Framework, numAllNodes int32) (numNodes int32) { | ||
adaptivePercentage := g.percentageOfNodesToScore | ||
if p := fwk.PercentageOfNodesToScore(); p != 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this defaulting should probably happen in the v1beta1/defaults.go file; then we can just use the value as-is without the p != 0
check. also helps to have all the defaulting in the same place and also in the future when we decide to remove the top-level field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, defaulting needs to happen in v1beta1/defaults.go. Basically when not set we default the value to the higher level field.
6cc9bf8
to
1740bda
Compare
/test pull-kubernetes-e2e-gce-ubuntu-containerd |
/cc @Huang-Wei |
// DEPRECATED: Please use the profile-level PercentageOfNodesToScore to configure this instead. | ||
// TODO(#95446): Remove PercentageOfNodesToScore from KubeSchedulerConfiguration once v1beta1 is removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will still be valid in v1beta1, so I don't think we should say "deprecated" here.
@@ -72,6 +72,9 @@ type KubeSchedulerConfiguration struct { | |||
// then scheduler stops finding further feasible nodes once it finds 150 feasible ones. | |||
// When the value is 0, default percentage (5%--50% based on the size of the cluster) of the | |||
// nodes will be scored. | |||
// Note: This field will be overridden by the profile-level PercentageOfNodesToScore when that is not zero. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Note: This field will be overridden by the profile-level PercentageOfNodesToScore when that is not zero. | |
// Note: This field will be overridden by the profile-level PercentageOfNodesToScore when set. |
// When the field is unset or the value is 0, the PercentageOfNodesToScore in the top-level | ||
// KubeSchedulerConfiguration will be used. | ||
// Note: This field will override the top-level PercentageOfNodesToScore when it is not zero. | ||
PercentageOfNodesToScore *int32 `json:"percentageOfNodesToScore,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt do we have precedence on defaulting a field based on another? in this case, this is a per-profile field that when not set should be defaulted to the component configuration level field above (which we are planning to remove in v1beta2).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt do we have precedence on defaulting a field based on another? in this case, this is a per-profile field that when not set should be defaulted to the component configuration level field above (which we are planning to remove in v1beta2).
When we've done it in the past for REST APIs, it hasn't worked well, because of the following:
- user created object with field A set and field B unset
- server defaults field B based on field A
- user updates object changing field A's value to something else
- the previously defaulted value for field B is not valid with the new value of field A, so the user gets an error about an invalid value for a field they never set.
However, for a config file which is read only (and never has to handle update scenarios), this is probably fine.
@@ -88,6 +88,9 @@ type KubeSchedulerConfiguration struct { | |||
// then scheduler stops finding further feasible nodes once it finds 150 feasible ones. | |||
// When the value is 0, default percentage (5%--50% based on the size of the cluster) of the | |||
// nodes will be scored. | |||
// Note: This field will be overridden by the profile-level PercentageOfNodesToScore when that is not zero. | |||
// DEPRECATED: Please use the profile-level PercentageOfNodesToScore to configure this instead. | |||
// TODO(#95446): Remove PercentageOfNodesToScore from KubeSchedulerConfiguration once v1beta1 is removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can delete this field now, we don't need it in the internal representation since we will directly default the per-profile field based on this one in defaults.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to keep profile-pertentage only, particularly as Liggitt commented that obtaining value from another field doesn't work well.
@@ -274,7 +278,7 @@ func (g *genericScheduler) findNodesThatPassFilters(ctx context.Context, fwk fra | |||
return nil, err | |||
} | |||
|
|||
numNodesToFind := g.numFeasibleNodesToFind(int32(len(allNodes))) | |||
numNodesToFind := g.numFeasibleNodesToFind(fwk, int32(len(allNodes))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we followed @ahg-g's comment at https://github.com/kubernetes/kubernetes/pull/97263/files#r552730847 to remove the global percentage, percentageOfNodesToScore
would be a profile-level field only, semantically its logic shouldn't be tightened to g
(generic scheduler). I'd suggest to
- either expose
NodesNumToScore()
in framework/inteface.go, and hence here we just callfwk.NodesNumToScore(int32(len(allNodes)))
. - or (preferrable IMO), make the function stateless, i.e.,
NodesNumToScore()
to accept two parameters: percentage and num of all nodes.
@@ -88,6 +88,9 @@ type KubeSchedulerConfiguration struct { | |||
// then scheduler stops finding further feasible nodes once it finds 150 feasible ones. | |||
// When the value is 0, default percentage (5%--50% based on the size of the cluster) of the | |||
// nodes will be scored. | |||
// Note: This field will be overridden by the profile-level PercentageOfNodesToScore when that is not zero. | |||
// DEPRECATED: Please use the profile-level PercentageOfNodesToScore to configure this instead. | |||
// TODO(#95446): Remove PercentageOfNodesToScore from KubeSchedulerConfiguration once v1beta1 is removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to keep profile-pertentage only, particularly as Liggitt commented that obtaining value from another field doesn't work well.
3e8766f
to
4559909
Compare
4559909
to
d3ff601
Compare
d3ff601
to
4b00fdf
Compare
@SataQiu: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/close |
@SataQiu: PR needs rebase. 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. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
scheduler: move percentagesOfNodesToScore to the scheduler profile
Which issue(s) this PR fixes:
Fixes #93270
Ref #95709 #95823
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: