Skip to content
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.

Sign up for GitHub

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

Jump to bottom

KEP-2901: remove scheduler policy and cc v1beta1 #2921

Merged
merged 1 commit into from
Sep 2, 2021
Merged

KEP-2901: remove scheduler policy and cc v1beta1 #2921

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 20 additions & 16 deletions keps/sig-scheduling/785-scheduler-component-config-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@
## Summary

The kube-scheduler configuration API `kubescheduler.config.k8s.io` was in alpha
for several releases. We graduated it to beta in 1.19 as `v1beta1`. We introduced
for several releases. We graduated it to beta in 1.19 as `v1beta1`. We introduced
`v1beta2` and `v1beta3` in 1.22 and 1.23 respectively.

## Motivation
Expand All @@ -59,7 +59,7 @@ changes such as:
align with the new scheduler framework.
- The introduction of scheduling profiles, that allow a scheduler to appear
as multiple schedulers under different configurations.

A configuration API allows cluster administrators to build, validate and
version their configurations in a more robust way than using command line flags.

Expand All @@ -86,7 +86,7 @@ For the most part, `kubescheduler.config.k8s.io/v1beta1` will be a copy of
- [ ] `.profiles[*].plugins.unreserve` will be removed.
- [ ] Embedded types of `RequestedToCapacityRatio` will include missing json tags
and will be decoded with a case-sensitive decoder.

The second iteration, `kubescheduler.config.k8s.io/v1beta2`, includes the following changes:
- Plugin removals:
- `NodeLabel` (in favor of `NodeAffinity`)
Expand All @@ -102,10 +102,12 @@ The third iteration, `kubescheduler.config.k8s.io/v1beta3`, includes the followi
- `InterPodAffinity` to 2
- `NodeAffinity` to 2
- `TaintToleration` to 3 as leveraging node tainting to group nodes in the cluster is becoming a widely-adopted practice
- Remove `v1beta1`
- Remove the legacy [policy config API](https://kubernetes.io/docs/reference/scheduling/policies/)

The main reason is that some plugins have "default" behavior without needing user inputs, whereas the above plugins are
about user preferences, so should have more influence while making scheduling decisions.
More information on the discussion can be found [here](https://github.com/kubernetes/kubernetes/issues/88174).
More information on the discussion can be found [here](https://github.com/kubernetes/kubernetes/issues/88174).
### Risks and Mitigations

The major risk is around the removal of the `unreserve` extension point.
Expand All @@ -115,7 +117,7 @@ However, this is mitigated for the following reasons:
effectively requiring plugins to implement both functions.
- There are no in-tree Reserve or Unreserve plugins prior to 1.19.
The `VolumeBinding` plugin is now implementing both interfaces.

The caveat is that out-of-tree plugins that want to work 1.19 need to
updated to comply with the modified `Reserve` interface, otherwise scheduler
startup will fail. Plugins can choose to provide empty implementations.
Expand Down Expand Up @@ -181,7 +183,7 @@ N/A
* **Are there any tests for feature enablement/disablement?**

The e2e framework does not currently support changing configuration files.

There are intensive unit tests for all the API versions.

### Rollout, Upgrade and Rollback Planning
Expand All @@ -205,16 +207,17 @@ N/A

* **Is the rollout accompanied by any deprecations and/or removals of features,
APIs, fields of API types, flags, etc.?**

When `v1beta1` was introduced:
- Configuration API `kubescheduler.config.k8s.io/v1alpha2` is removed.

When `v1beta2` was introduced:
- Some plugins are disabled. They continue to work in `v1beta1`; if used,
kube-scheduler logs a Warning.

When `v1beta3` gets introduced:
- No changes to plugins enabled by default. Only their weights would change.
- No changes to plugins enabled by default. Only their weights would change.
kerthcet marked this conversation as resolved.
Show resolved Hide resolved
- Remove `v1beta1`.

### Monitoring requirements

Expand All @@ -228,7 +231,7 @@ N/A

* **What are the SLIs (Service Level Indicators) an operator can use to
determine the health of the service?**

N/A.

* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**
Expand Down Expand Up @@ -259,22 +262,22 @@ N/A

* **Will enabling / using this feature result in any new calls to cloud
provider?**

No.

* **Will enabling / using this feature result in increasing size or count
of the existing API objects?**

No.

* **Will enabling / using this feature result in increasing time taken by any
operations covered by [existing SLIs/SLOs][]?**

No.

* **Will enabling / using this feature result in non-negligible increase of
resource usage (CPU, RAM, disk, IO, ...) in any components?**

No.

### Troubleshooting
Expand All @@ -296,5 +299,6 @@ N/A
- 2020-05-08: KEP for beta graduation sent for review, including motivation,
proposal, risks, test plan and graduation criteria.
- 2020-05-13: KEP updated to remove v1alpha2 support.
- 2021-07-08: Introducing `v1beta2`
- 2021-08-06: Introducing `v1beta3`
- 2021-07-08: Introducing `v1beta2`.
- 2021-08-06: Introducing `v1beta3`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add one more line:

  • 2021-09-01: remove v1beta1 and the legacy policy config API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct me if not, i thought we only plan to remind users about the v1beta1 deprecated policy, such as adding a warning log, or we want to remove the source code？

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is just a log of updates to this kep

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can safely remove v1beta1 based on when it was introduced (1.19), but v1beta2 has only existed as a replacement for 1 release, is that enough time for deprecation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ahg-g I think the question is in the wording for the log... 2021-09-21: remove v1beta1... vs 2021-09-21: mark v1beta1 deprecated

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

privide some messages, maybe not conformable. as deprecation policy says, Beta feature to EOL: 3 months or 1 release (whichever is longer), we introduced v1beta1 in release 1.19, more than 3 months or one release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to remove it completely. We can do so and it is likely better to reduce clutter and the overhead of maintaining three beta versions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated both places, section under introducing v1beta3 and implementation history.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to remove v1beta1 when v1beta3 gets introduced. It's not that typical/necessary to keep 3+ APIs at the same time.

- 2021-09-01: Remove `v1beta1` and the legacy policy config API.