kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #35042 from kerthcet/feat/ga-component-config-in-scheduler 

Graduate the kube-scheduler ComponentConfig to GA
pull/36020/head
Kubernetes Prow Robot 2022-08-16 07:13:08 -07:00 committed by GitHub
parent 2d3e848f2a ab283be3f5
commit 623d855c47
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 50 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
content/en/docs/reference/scheduling/config.md
View File

@ -4,7 +4,7 @@ content_type: concept
weight: 20
---
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.25" state="stable" >}}
You can customize the behavior of the `kube-scheduler` by writing a configuration
file and passing its path as a command line argument.
@ -20,19 +20,25 @@ by implementing one or more of these extension points.
You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
using the
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
or [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
KubeSchedulerConfiguration ([v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
or [v1](/docs/reference/config-api/kube-scheduler-config.v1/))
struct.
A minimal configuration looks as follows:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
```
{{< note >}}
KubeSchedulerConfiguration [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
is deprecated in v1.25 and will be removed in v1.26. Please migrate KubeSchedulerConfiguration to
[v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/) or [v1](/docs/reference/config-api/kube-scheduler-config.v1/)
before upgrading Kubernetes to v1.25.
{{< /note >}}
## Profiles
A scheduling Profile allows you to configure the different stages of scheduling
@ -78,14 +84,14 @@ extension points:
least one bind plugin is required.
1. `postBind`: This is an informational extension point that is called after
a Pod has been bound.
1. `multiPoint`: This is a config-only field that allows plugins to be enabled
1. `multiPoint`: This is a config-only field that allows plugins to be enabled
or disabled for all of their applicable extension points simultaneously.
For each extension point, you could disable specific [default plugins](#scheduling-plugins)
or enable your own. For example:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- plugins:
@ -172,11 +178,6 @@ extension points:
You can also enable the following plugins, through the component config APIs,
that are not enabled by default:
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
{{< glossary_tooltip text="Services" term_id="service" >}},
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
Extension points: `preScore`, `score`.
- `CinderLimits`: Checks that [OpenStack Cinder](https://docs.openstack.org/cinder/)
volume limits can be satisfied for the node.
Extension points: `filter`.
@ -192,7 +193,7 @@ profiles: one with the default plugins and one with all scoring plugins
disabled.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
@ -231,17 +232,17 @@ only has one pending pods queue.
### Plugins that apply to multiple extension points {#multipoint}
Starting from `kubescheduler.config.k8s.io/v1beta3`, there is an additional field in the
profile config, `multiPoint`, which allows for easily enabling or disabling a plugin
across several extension points. The intent of `multiPoint` config is to simplify the
Starting from `kubescheduler.config.k8s.io/v1beta3`, there is an additional field in the
profile config, `multiPoint`, which allows for easily enabling or disabling a plugin
across several extension points. The intent of `multiPoint` config is to simplify the
configuration needed for users and administrators when using custom profiles.
Consider a plugin, `MyPlugin`, which implements the `preScore`, `score`, `preFilter`,
and `filter` extension points. To enable `MyPlugin` for all its available extension
Consider a plugin, `MyPlugin`, which implements the `preScore`, `score`, `preFilter`,
and `filter` extension points. To enable `MyPlugin` for all its available extension
points, the profile config looks like:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
@ -251,11 +252,11 @@ profiles:
- name: MyPlugin
```
This would equate to manually enabling `MyPlugin` for all of its extension
This would equate to manually enabling `MyPlugin` for all of its extension
points, like so:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
@ -274,17 +275,17 @@ profiles:
- name: MyPlugin
```
One benefit of using `multiPoint` here is that if `MyPlugin` implements another
extension point in the future, the `multiPoint` config will automatically enable it
One benefit of using `multiPoint` here is that if `MyPlugin` implements another
extension point in the future, the `multiPoint` config will automatically enable it
for the new extension.
Specific extension points can be excluded from `MultiPoint` expansion using
the `disabled` field for that extension point. This works with disabling default
plugins, non-default plugins, or with the wildcard (`'*'`) to disable all plugins.
Specific extension points can be excluded from `MultiPoint` expansion using
the `disabled` field for that extension point. This works with disabling default
plugins, non-default plugins, or with the wildcard (`'*'`) to disable all plugins.
An example of this, disabling `Score` and `PreScore`, would be:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
@ -300,14 +301,15 @@ profiles:
- name: '*'
```
In `v1beta3`, all [default plugins](#scheduling-plugins) are enabled internally through `MultiPoint`.
However, individual extension points are still available to allow flexible
reconfiguration of the default values (such as ordering and Score weights). For
example, consider two Score plugins `DefaultScore1` and `DefaultScore2`, each with
Starting from `kubescheduler.config.k8s.io/v1beta3`, all [default plugins](#scheduling-plugins)
are enabled internally through `MultiPoint`.
However, individual extension points are still available to allow flexible
reconfiguration of the default values (such as ordering and Score weights). For
example, consider two Score plugins `DefaultScore1` and `DefaultScore2`, each with
a weight of `1`. They can be reordered with different weights like so:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
@ -318,10 +320,10 @@ profiles:
weight: 5
```
In this example, it's unnecessary to specify the plugins in `MultiPoint` explicitly
In this example, it's unnecessary to specify the plugins in `MultiPoint` explicitly
because they are default plugins. And the only plugin specified in `Score` is `DefaultScore2`.
This is because plugins set through specific extension points will always take precedence
over `MultiPoint` plugins. So, this snippet essentially re-orders the two plugins
This is because plugins set through specific extension points will always take precedence
over `MultiPoint` plugins. So, this snippet essentially re-orders the two plugins
without needing to specify both of them.
The general hierarchy for precedence when configuring `MultiPoint` plugins is as follows:
@ -342,7 +344,7 @@ To demonstrate the above hierarchy, the following example is based on these plug
A valid sample configuration for these plugins would be:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
@ -363,8 +365,8 @@ profiles:
- name: 'DefaultPlugin2'
```
Note that there is no error for re-declaring a `MultiPoint` plugin in a specific
extension point. The re-declaration is ignored (and logged), as specific extension points
Note that there is no error for re-declaring a `MultiPoint` plugin in a specific
extension point. The re-declaration is ignored (and logged), as specific extension points
take precedence.
Besides keeping most of the config in one spot, this sample does a few things:
@ -380,14 +382,14 @@ kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
# Disable the default QueueSort plugin
queueSort:
enabled:
- name: 'CustomQueueSort'
disabled:
- name: 'DefaultQueueSort'
# Enable custom Filter plugins
filter:
enabled:
@ -396,7 +398,7 @@ profiles:
- name: 'DefaultPlugin2'
disabled:
- name: 'DefaultPlugin1'
# Enable and reorder custom score plugins
score:
enabled:
@ -406,7 +408,7 @@ profiles:
weight: 3
```
While this is a complicated example, it demonstrates the flexibility of `MultiPoint` config
While this is a complicated example, it demonstrates the flexibility of `MultiPoint` config
as well as its seamless integration with the existing methods for configuring extension points.
## Scheduler configuration migrations
@ -451,6 +453,11 @@ as well as its seamless integration with the existing methods for configuring ex
* `NodeAffinity` from 1 to 2
* `TaintToleration` from 1 to 3
{{% /tab %}}
{{% tab name="v1beta3 → v1" %}}
* The scheduler plugin `SelectorSpread` is removed, instead, use the `PodTopologySpread` plugin (enabled by default)
to achieve similar behavior.
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
@ -459,3 +466,4 @@ as well as its seamless integration with the existing methods for configuring ex
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Read the [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
* Read the [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
* Read the [kube-scheduler configuration (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) reference

3
content/en/docs/reference/scheduling/policies.md
View File

@ -16,5 +16,4 @@ This scheduling policy is not supported since Kubernetes v1.23. Associated flags
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Learn about [kube-scheduler Configuration](/docs/reference/scheduling/config/)
* Read the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* Read the [kube-scheduler configuration reference (v1)](/docs/reference/config-api/kube-scheduler-config.v1/)