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

mv zh/docs/concepts/configurations/scheduling-framework.md to concepts/scheduling-eviction

This commit is contained in:
Dominic Yin 2020-04-29 14:19:16 +08:00
parent 1cccd3f0f5
commit 32fa93df55
No known key found for this signature in database
GPG Key ID: DDEC5F1F35BEB6EF
2 changed files with 109 additions and 190 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -145,7 +145,7 @@ of the scheduler:
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
can also configure the kube-scheduler to run different profiles. can also configure the kube-scheduler to run different profiles.
--> -->
1. [调度策略](/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_。 1. [调度策略](/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
2. [调度配置](/docs/reference/scheduling/profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。 2. [调度配置](/docs/reference/scheduling/profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。
{{% /capture %}} {{% /capture %}}

297
content/zh/docs/concepts/configuration/scheduling-framework.md → content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
View File

@ -3,7 +3,7 @@ reviewers:
- ahg-g - ahg-g
title: 调度框架 title: 调度框架
content_template: templates/concept content_template: templates/concept
weight: 70 weight: 60
--- ---
<!-- <!--
@ -12,7 +12,7 @@ reviewers:
- ahg-g - ahg-g
title: Scheduling Framework title: Scheduling Framework
content_template: templates/concept content_template: templates/concept
weight: 70 weight: 60
--- ---
--> -->
@ -21,7 +21,7 @@ weight: 70
{{< feature-state for_k8s_version="1.15" state="alpha" >}} {{< feature-state for_k8s_version="1.15" state="alpha" >}}
<!-- <!--
The scheduling framework is a new plugable architecture for Kubernetes Scheduler The scheduling framework is a plugable architecture for Kubernetes Scheduler
that makes scheduler customizations easy. It adds a new set of "plugin" APIs to that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
the existing scheduler. Plugins are compiled into the scheduler. The APIs the existing scheduler. Plugins are compiled into the scheduler. The APIs
allow most scheduling features to be implemented as plugins, while keeping the allow most scheduling features to be implemented as plugins, while keeping the
@ -30,7 +30,7 @@ scheduling framework][kep] for more technical information on the design of the
framework. framework.
--> -->
调度框架是 Kubernetes Scheduler 的一种新的可插入架构，可以简化调度器的自定义。它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考[调度框架的设计提案][kep]获取框架设计的更多技术信息。 调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考[调度框架的设计提案][kep]获取框架设计的更多技术信息。
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md [kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
@ -57,7 +57,7 @@ Each attempt to schedule one Pod is split into two phases, the **scheduling
cycle** and the **binding cycle**. cycle** and the **binding cycle**.
--> -->
每次调度一个 pod 的尝试都分为两个阶段，即**调度周期**和**绑定周期**。 每次调度一个 Pod 的尝试都分为两个阶段，即 **调度周期** 和 **绑定周期**。
<!-- <!--
## Scheduling Cycle & Binding Cycle ## Scheduling Cycle & Binding Cycle
@ -71,7 +71,7 @@ that decision to the cluster. Together, a scheduling cycle and binding cycle are
referred to as a "scheduling context". referred to as a "scheduling context".
--> -->
调度周期为 pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。 调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。
<!-- <!--
Scheduling cycles are run serially, while binding cycles may run concurrently. Scheduling cycles are run serially, while binding cycles may run concurrently.
@ -85,7 +85,7 @@ be unschedulable or if there is an internal error. The Pod will be returned to
the queue and retried. the queue and retried.
--> -->
如果确定 pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。 如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。
<!-- <!--
## Extension points ## Extension points
@ -99,7 +99,7 @@ points that the scheduling framework exposes. In this picture "Filter" is
equivalent to "Predicate" and "Scoring" is equivalent to "Priority function". equivalent to "Predicate" and "Scoring" is equivalent to "Priority function".
--> -->
下图显示了一个 pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。 下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
<!-- <!--
One plugin may register at multiple extension points to perform more complex or One plugin may register at multiple extension points to perform more complex or
@ -108,39 +108,38 @@ stateful tasks.
一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。 一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。
<!-- <!--
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}} {{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}}
--> -->
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}} {{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}}
<!--
### Queue sort
-->
###　队列排序 <!--
### QueueSort {#queue-sort}
-->
### 队列排序 {#queue-sort}
<!-- <!--
These plugins are used to sort Pods in the scheduling queue. A queue sort plugin These plugins are used to sort Pods in the scheduling queue. A queue sort plugin
essentially will provide a "less(Pod1, Pod2)" function. Only one queue sort essentially provides a `less(Pod1, Pod2)` function. Only one queue sort
plugin may be enabled at a time. plugin may be enabled at a time.
--> -->
队列排序插件用于对调度队列中的 pod 进行排序。队列排序插件本质上将提供 "less(Pod1, Pod2)" 函数。一次只能启动一个队列插件。 队列排序插件用于对调度队列中的 Pod 进行排序。队列排序插件本质上提供 "less(Pod1, Pod2)" 函数。一次只能启动一个队列插件。
<!-- <!--
### Pre-filter ### PreFilter {#pre-filter}
--> -->
### 前置过滤 ### 前置过滤 {#pre-filter}
<!-- <!--
These plugins are used to pre-process info about the Pod, or to check certain These plugins are used to pre-process info about the Pod, or to check certain
conditions that the cluster or the Pod must meet. If a pre-filter plugin returns conditions that the cluster or the Pod must meet. If a PreFilter plugin returns
an error, the scheduling cycle is aborted. an error, the scheduling cycle is aborted.
--> -->
前置过滤插件用于预处理 pod 的相关信息，或者检查集群或 pod 必须满足的某些条件。如果前置过滤插件返回错误，则调度周期将终止。 前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。如果 PreFilter 插件返回错误，则调度周期将终止。
<!-- <!--
### Filter ### Filter
@ -155,59 +154,49 @@ filter plugin marks the node as infeasible, the remaining plugins will not be
called for that node. Nodes may be evaluated concurrently. called for that node. Nodes may be evaluated concurrently.
--> -->
过滤插件用于过滤出不能运行该 pod 的节点。对于每个节点，调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。 过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
<!-- <!--
### Post-filter ### PreScore {#pre-score}
--> -->
### 前置评分 {#pre-score}
### 后置过滤 <!--
These plugins are used to perform "pre-scoring" work, which generates a sharable
state for Score plugins to use. If a PreScore plugin returns an error, the
scheduling cycle is aborted.
-->
前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。如果 PreScore 插件返回错误，则调度周期将终止。
<!-- <!--
This is an informational extension point. Plugins will be called with a list of ### Score {#scoring}
nodes that passed the filtering phase. A plugin may use this data to update -->
internal state or to generate logs/metrics. ### 评分 {#scoring}
-->
后置过滤是一个信息性的扩展点。通过过滤阶段的节点列表将调用这些后置过滤。插件将使用这些数据来更新内部的状态或者生成日志/指标。
<!--
**Note:** Plugins wishing to perform "pre-scoring" work should use the
post-filter extension point.
-->
**注意：**希望执行“预评分”工作的插件应该使用后置过滤扩展点。
<!--
### Scoring
-->
### 评分
<!-- <!--
These plugins are used to rank nodes that have passed the filtering phase. The These plugins are used to rank nodes that have passed the filtering phase. The
scheduler will call each scoring plugin for each node. There will be a well scheduler will call each scoring plugin for each node. There will be a well
defined range of integers representing the minimum and maximum scores. After the defined range of integers representing the minimum and maximum scores. After the
[normalize scoring](#normalize-scoring) phase, the scheduler will combine node [NormalizeScore](#normalize-scoring) phase, the scheduler will combine node
scores from all plugins according to the configured plugin weights. scores from all plugins according to the configured plugin weights.
--> -->
评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#标准化评分)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。 评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。
<!-- <!--
### Normalize scoring ### NormalizeScore {#normalize-scoring}
--> -->
### 标准化评分 ### 标准化评分 {#normalize-scoring}
<!-- <!--
These plugins are used to modify scores before the scheduler computes a final These plugins are used to modify scores before the scheduler computes a final
ranking of Nodes. A plugin that registers for this extension point will be ranking of Nodes. A plugin that registers for this extension point will be
called with the [scoring](#scoring) results from the same plugin. This is called called with the [Score](#scoring) results from the same plugin. This is called
once per plugin per scheduling cycle. once per plugin per scheduling cycle.
--> -->
标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#评分)结果被调用。每个插件在每个调度周期调用一次。 标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。每个插件在每个调度周期调用一次。
<!-- <!--
For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how
@ -243,18 +232,19 @@ func NormalizeScores(scores map[string]int) {
``` ```
<!-- <!--
If any normalize-scoring plugin returns an error, the scheduling cycle is If any NormalizeScore plugin returns an error, the scheduling cycle is
aborted. aborted.
--> -->
如果任何标准化评分插件返回错误，则调度阶段将终止。 如果任何 NormalizeScore 插件返回错误，则调度阶段将终止。
<!-- <!--
**Note:** Plugins wishing to perform "pre-reserve" work should use the Plugins wishing to perform "pre-reserve" work should use the
normalize-scoring extension point. NormalizeScore extension point.
--> -->
{{< note >}}
**注意：**希望执行“预保留”工作的插件应该使用标准化评分扩展点。 希望执行“预保留”工作的插件应该使用 NormalizeScore 扩展点。
{{< /note >}}
<!-- <!--
### Reserve ### Reserve
@ -270,22 +260,16 @@ happens before the scheduler actually binds the Pod to the Node, and it exists
to prevent race conditions while the scheduler waits for the bind to succeed. to prevent race conditions while the scheduler waits for the bind to succeed.
--> -->
保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 pod 预留了资源时能够通知该插件。这是在调度器真正将 pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。 保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 Pod 预留了资源时能够通知该插件。这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
<!-- <!--
This is the last step in a scheduling cycle. Once a Pod is in the reserved This is the last step in a scheduling cycle. Once a Pod is in the reserved
state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
[Post-bind](#post-bind) plugins (on success) at the end of the binding cycle. [PostBind](#post-bind) plugins (on success) at the end of the binding cycle.
--> -->
这个是调度周期的最后一步。一旦 pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留)插件（失败时）或 这个是调度周期的最后一步。一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留) 插件（失败时）或
[绑定后](#绑定后)插件（成功时）。 [绑定后](#post-bind) 插件（成功时）。
<!--
*Note: This concept used to be referred to as "assume".*
-->
*注意：此概念曾被称为“假设”。*
<!-- <!--
### Permit ### Permit
@ -294,60 +278,58 @@ state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
### 允许 ### 允许
<!-- <!--
These plugins are used to prevent or delay the binding of a Pod. A permit plugin _Permit_ plugins are invoked at the end of the scheduling cycle for each Pod, to
can do one of three things. prevent or delay the binding to the candidate node. A permit plugin can do one of
the three things:
--> -->
允许插件用于防止或延迟 pod 的绑定。一个允许插件可以做以下三件事之一。 _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。一个允许插件可以做以下三件事之一：
<!-- <!--
1. **approve** \ 1. **approve** \
Once all permit plugins approve a Pod, it is sent for binding. Once all Permit plugins approve a Pod, it is sent for binding.
--> -->
1. **批准** \ 1. **批准** \
一旦所有允许插件批准 pod 后，该 pod 将被发送以进行绑定。 一旦所有 Permit 插件批准 Pod 后，该 Pod 将被发送以进行绑定。
<!-- <!--
1. **deny** \ 1. **deny** \
If any permit plugin denies a Pod, it is returned to the scheduling queue. If any Permit plugin denies a Pod, it is returned to the scheduling queue.
This will trigger [Unreserve](#unreserve) plugins. This will trigger [Unreserve](#unreserve) plugins.
--> -->
1. **拒绝** \ 1. **拒绝** \
如果任何允许插件拒绝 pod，则该 pod 将被返回到调度队列。这将触发[不保留](#不保留)插件。 如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。这将触发[不保留](#不保留) 插件。
<!-- <!--
1. **wait** (with a timeout) \ 1. **wait** (with a timeout) \
If a permit plugin returns "wait", then the Pod is kept in the permit phase If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
until a [plugin approves it](#frameworkhandle). If a timeout occurs, **wait** Pods list, and the binding cycle of this Pod starts but directly blocks until it
becomes **deny** and the Pod is returned to the scheduling queue, triggering gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
[Unreserve](#unreserve) plugins. and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
plugins.
--> -->
1. **等待**（带有超时） \ 1. **等待**（带有超时） \
如果一个允许插件返回“等待”结果，则 pod 将保持在允许阶段，直到插件批准它。如果超时发生，**等待**变成**拒绝**，并且 pod 将返回调度队列，从而触发[不保留](#不保留)插件。 如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中” 的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到[批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod 将返回调度队列，从而触发[不保留](#不保留) 插件。
<!--
While any plugin can access the list of "waiting" Pods and approve them
(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
is approved, it is sent to the [PreBind](#pre-bind) phase.
-->
{{< note >}}
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](#frameworkhandle))。我们希望只有允许插件可以批准处于 “等待中” 状态的 预留 Pod 的绑定。一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
{{< /note >}}
<!-- <!--
**Approving a Pod binding** ### Pre-bind {#pre-bind}
--> -->
**批准 pod 绑定** ### 预绑定 {#pre-bind}
<!--
While any plugin can access the list of "waiting" Pods from the cache and
approve them (see [`FrameworkHandle`](#frameworkhandle)) we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a
Pod is approved, it is sent to the pre-bind phase.
-->
尽管任何插件可以从缓存中访问“等待”状态的 pod 列表并批准它们。我们希望只有允许插件可以批准处于“等待”状态的 预留 pod 的绑定。一旦 pod 被批准了，它将发送到预绑定阶段。
<!--
### Pre-bind
-->
### 预绑定
<!-- <!--
These plugins are used to perform any work required before a Pod is bound. For These plugins are used to perform any work required before a Pod is bound. For
@ -355,14 +337,14 @@ example, a pre-bind plugin may provision a network volume and mount it on the
target node before allowing the Pod to run there. target node before allowing the Pod to run there.
--> -->
预绑定插件用于执行 pod 绑定前所需的任何工作。例如，一个预绑定插件可能需要提供网络卷并且在允许 pod 运行在该节点之前将其挂载到目标节点上。 预绑定插件用于执行 Pod 绑定前所需的任何工作。例如，一个预绑定插件可能需要提供网络卷并且在允许 Pod 运行在该节点之前将其挂载到目标节点上。
<!-- <!--
If any pre-bind plugin returns an error, the Pod is [rejected](#unreserve) and If any PreBind plugin returns an error, the Pod is [rejected](#unreserve) and
returned to the scheduling queue. returned to the scheduling queue.
--> -->
如果任何预绑定插件返回错误，则 pod 将被[拒绝](#不保留)并且返回到调度队列中。 如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#不保留) 并且返回到调度队列中。
<!-- <!--
### Bind ### Bind
@ -372,19 +354,19 @@ returned to the scheduling queue.
<!-- <!--
These plugins are used to bind a Pod to a Node. Bind plugins will not be called These plugins are used to bind a Pod to a Node. Bind plugins will not be called
until all pre-bind plugins have completed. Each bind plugin is called in the until all PreBind plugins have completed. Each bind plugin is called in the
configured order. A bind plugin may choose whether or not to handle the given configured order. A bind plugin may choose whether or not to handle the given
Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are
skipped**. skipped**.
--> -->
绑定插件用于将 pod 绑定到节点上。直到所有的预绑定插件都完成，绑定插件才会被调用。每个绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 pod。如果绑定插件选择处理 pod，**剩余的绑定插件将被跳过**。 绑定插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，绑定插件才会被调用。每个绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
<!-- <!--
### Post-bind ### PostBind {#post-bind}
--> -->
### 绑定后 ### 绑定后 {#post-bind}
<!-- <!--
This is an informational extension point. Post-bind plugins are called after a This is an informational extension point. Post-bind plugins are called after a
@ -392,7 +374,7 @@ Pod is successfully bound. This is the end of a binding cycle, and can be used
to clean up associated resources. to clean up associated resources.
--> -->
这是个信息性的扩展点。绑定后插件在 pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。 这是个信息性的扩展点。绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
<!-- <!--
### Unreserve ### Unreserve
@ -406,7 +388,7 @@ rejected in a later phase, then unreserve plugins will be notified. Unreserve
plugins should clean up state associated with the reserved Pod. plugins should clean up state associated with the reserved Pod.
--> -->
这是个信息性的扩展点。如果 pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 pod 的相关状态。 这是个信息性的扩展点。如果 Pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 Pod 的相关状态。
<!-- <!--
Plugins that use this extension point usually should also use Plugins that use this extension point usually should also use
@ -441,7 +423,7 @@ type QueueSortPlugin interface {
type PreFilterPlugin interface { type PreFilterPlugin interface {
Plugin Plugin
PreFilter(PluginContext, *v1.pod) error PreFilter(context.Context, *framework.CycleState, *v1.pod) error
} }
// ... // ...
@ -453,90 +435,27 @@ type PreFilterPlugin interface {
# 插件配置 # 插件配置
<!-- <!--
Plugins can be enabled in the scheduler configuration. Also, default plugins can You can enable or disable plugins in the scheduler configuration. If you are using
be disabled in the configuration. In 1.15, there are no default plugins for the Kubernetes v1.18 or later, most scheduling
scheduling framework. [plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
--> enabled by default.
-->
你可以在调度器配置中启用或禁用插件。如果你在使用 Kubernetes v1.18 或更高版本，大部分调度[插件](/docs/reference/scheduling/profiles/#scheduling-plugins) 都在使用中且默认启用。
可以在调度器配置中启用插件。另外，默认的插件可以在配置中禁用。在 1.15 版本，调度框架没有默认的插件。 <!--
In addition to default plugins, you can also implement your own scheduling
plugins and get them configured along with default plugins. You can visit
[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) for more details.
-->
除了默认的插件，你同样可以实现自己的调度插件并且将他们与默认插件一起配置。你可以访问 [调度插件](https://github.com/kubernetes-sigs/scheduler-plugins) 了解更多详情。
<!-- <!--
The scheduler configuration can include configuration for plugins as well. Such If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
configurations are passed to the plugins at the time the scheduler initializes a scheduler profile and then define multiple profiles to fit various kinds of workload.
them. The configuration is an arbitrary value. The receiving plugin should Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
decode and process the configuration. -->
--> 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
了解更多关于 [多配置文件](/docs/reference/scheduling/profiles/#multiple-profiles)。
调度器配置也可以包含插件的配置。这些配置在调度器初始化插件时传给插件。配置是一个任意值。接收插件应该解码并处理配置信息。
<!--
The following example shows a scheduler configuration that enables some
plugins at `reserve` and `preBind` extension points and disables a plugin. It
also provides a configuration to plugin `foo`.
-->
下面的例子显示一个调度器配置，该配置在 `reserve` 和 `preBind` 扩展点启用了一些插件并且禁用了一个插件。它还提供了 `foo` 插件的配置。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
...
plugins:
reserve:
enabled:
- name: foo
- name: bar
disabled:
- name: baz
preBind:
enabled:
- name: foo
disabled:
- name: baz
pluginConfig:
- name: foo
args: >
Arbitrary set of args to plugin foo
```
<!--
When an extension point is omitted from the configuration default plugins for
that extension points are used. When an extension point exists and `enabled` is
provided, the `enabled` plugins are called in addition to default plugins.
Default plugins are called first and then the additional enabled plugins are
called in the same order specified in the configuration. If a different order of
calling default plugins is desired, default plugins must be `disabled` and
`enabled` in the desired order.
-->
当配置省略扩展点时，将使用该扩展点的默认插件。当存在扩展掉并且配置为 `enabled`，则 `enabled` 的插件将和默认插件一同调用。首先调用默认插件，然后以配置中指定的顺序来调用其他已启用的插件。如果希望以不同的顺序来调用默认插件，默认插件必须 `disabled`，然后以期望的顺序 `enabled`。
<!--
Assuming there is a default plugin called `foo` at `reserve` and we are adding
plugin `bar` that we want to be invoked before `foo`, we should disable `foo`
and enable `bar` and `foo` in order. The following example shows the
configuration that achieves this:
-->
假设在 `reserve` 扩展点有一个默认的 `foo` 插件，且添加 `bar` 插件并且希望在 `foo` 插件之前执行，我们应该禁用 `foo` 并且按顺序启用 `bar` 和 `foo`。下面的例子显示了实现此目的的配置：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
...
plugins:
reserve:
enabled:
- name: bar
- name: foo
disabled:
- name: foo
```
{{% /capture %}} {{% /capture %}}