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
Scheduling v1beta3 #104251
Scheduling v1beta3 #104251
Conversation
@ravisantoshgudimetla: 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. |
/sig scheduling |
32ba5a1
to
0213510
Compare
{Name: names.PodTopologySpread, Weight: pointer.Int32Ptr(2)}, | ||
// Weight is tripled because: | ||
// - This is a score coming from user preference. | ||
// - Usage of node tainting to group nodes in the cluster is increasing becoming a use-case |
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 to myself: typo: increasingly becoming
0213510
to
f4fb45c
Compare
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. |
f4fb45c
to
27fdf6a
Compare
/retest |
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.
@ravisantoshgudimetla this needs a release note, but like we talked about offline it's all pretty straightforward to me. The actual changes (increasing the default plugin weights) are fairly small but this sets up v1beta3
nicely for us to get in final changes before promoting to v1
.
/cc @ahg-g @alculquicondor
one question I have is do we want to make this beta3 or just go ahead with starting work on v1, along with Abdullah's suggestion for the simplified config (#102303). what's the anticipated release time for v1, and does adding this new beta version add more work/time for us to eventually deprecate?
Staging changes for scheduler v1beta3 api. xref: kubernetes/enhancements#2850
Changes in pkg/apis/scheduler reflecting the changes from staging. The weights of following priority plugins were increased: - TaintTolerations - NodeAffinity - InterPodAffinity as they're user facing priorities and they should be more influential when compared to default plugins which don't have any user say. xref: kubernetes/enhancements#2850
bb84767
to
d988387
Compare
/test pull-kubernetes-unit |
Please don't include the fix to PreferNominatedNode in this PR. Create a separate one. |
d988387
to
3225d78
Compare
Done - #105509
I don't have a strong preference one way or the other. I included your suggestions here - #105509 |
This is ready for review again. |
badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled = append(badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled, config.Plugin{Name: "ServiceAffinity", Weight: 2}) | ||
|
||
badRemovedPlugins2 := validConfig.DeepCopy() | ||
badRemovedPlugins2.APIVersion = "kubescheduler.config.k8s.io/v1beta3" // hypothetical, v1beta3 doesn't exist | ||
badRemovedPlugins2.APIVersion = "kubescheduler.config.k8s.io/v1beta3" // hypothetical, v1beta3 |
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.
it's not hypothetical anymore.
78f680b
to
079a7eb
Compare
badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled = append(badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled, config.Plugin{Name: "ServiceAffinity", Weight: 2}) | ||
|
||
badRemovedPlugins2 := validConfig.DeepCopy() | ||
badRemovedPlugins2.APIVersion = "kubescheduler.config.k8s.io/v1beta3" // hypothetical, v1beta3 doesn't exist | ||
badRemovedPlugins2.APIVersion = "kubescheduler.config.k8s.io/v1beta3" // v1beta3 |
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.
No point having this test anymore.
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 still need it, considering the validConfig points to v1beta2 here
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.
yes, but you already have a test suite for v1beta3 below.
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.
It's just not about having the same test. It is also about having the apiVersion to validation testing mapping. Say if we forget to copy some logic or files specific to validation, we can surface those errors in appropriate versions.
badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled = append(badRemovedPlugins1.Profiles[0].Plugins.Score.Enabled, config.Plugin{Name: "ServiceAffinity", Weight: 2}) | ||
|
||
badRemovedPlugins2 := validConfig.DeepCopy() | ||
badRemovedPlugins2.APIVersion = "kubescheduler.config.k8s.io/v1beta3" // v1beta3 |
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.
Also no point for this one.
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.
True, it may not add much value, considering v1beta3 is the api we're testing now. It was a copy-paste error. Will remove it.
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.
079a7eb
to
283b176
Compare
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.
/lgtm
/hold cancel based on #104251 (review) /retest |
All the upgrade candidate nodes in a mcp would be applied `UpdateInProgress: PreferNoSchedule` taint. The taint will be removed MCD once the upgrade is complete. Since kubernetes/kubernetes#104251 landed, the nodes not having PreferNoSchedule taint will have higher score. Before the upgrade starts, MCC will taint all the nodes in the cluster that are supposed to be upgraded. Once the upgrade is complete since MCD will remove the taint, none of the nodes will have `UpdateInProgress: PreferNoSchedule` taint. This ensures the score of the nodes will be equal again. Why is this needed? This reduces the pod churn when the cluster upgrade is in progress. When the non-upgraded nodes in the cluster have `UpdateInProgress: PreferNoSchedule` taint, they would get lesser score and the pods would prefer to land onto untainted(upgraded) nodes there by reducing the chances of landing onto an unupgraded node which can cause one more reschedule
What type of PR is this?
/kind api-change
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: