mv zh/docs/concepts/configurations/scheduling-framework.md to concepts/scheduling-eviction
This commit is contained in:
Dominic Yin
parent
1cccd3f0f5
commit
32fa93df55
|
|
@ -145,7 +145,7 @@ of the scheduler:
|
|||
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
|
||||
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 运行不同的配置文件。
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ reviewers:
|
|||
- ahg-g
|
||||
title: 调度框架
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
|
|
@ -12,7 +12,7 @@ reviewers:
|
|||
- ahg-g
|
||||
title: Scheduling Framework
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ weight: 70
|
|||
{{< 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
|
||||
the existing scheduler. Plugins are compiled into the scheduler. The APIs
|
||||
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.
|
||||
-->
|
||||
|
||||
调度框架是 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
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Each attempt to schedule one Pod is split into two phases, the **scheduling
|
|||
cycle** and the **binding cycle**.
|
||||
-->
|
||||
|
||||
每次调度一个 pod 的尝试都分为两个阶段，即**调度周期**和**绑定周期**。
|
||||
每次调度一个 Pod 的尝试都分为两个阶段，即 **调度周期** 和 **绑定周期**。
|
||||
|
||||
<!--
|
||||
## 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".
|
||||
-->
|
||||
|
||||
调度周期为 pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。
|
||||
调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
如果确定 pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。
|
||||
如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。
|
||||
|
||||
<!--
|
||||
## 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".
|
||||
-->
|
||||
|
||||
下图显示了一个 pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
|
||||
下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
|
||||
|
||||
<!--
|
||||
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="调度框架扩展点" >}}
|
||||
|
||||
<!--
|
||||
### Queue sort
|
||||
-->
|
||||
|
||||
### 队列排序
|
||||
<!--
|
||||
### QueueSort {#queue-sort}
|
||||
-->
|
||||
### 队列排序 {#queue-sort}
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
队列排序插件用于对调度队列中的 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
|
||||
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.
|
||||
-->
|
||||
|
||||
前置过滤插件用于预处理 pod 的相关信息，或者检查集群或 pod 必须满足的某些条件。如果前置过滤插件返回错误，则调度周期将终止。
|
||||
前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。如果 PreFilter 插件返回错误，则调度周期将终止。
|
||||
|
||||
<!--
|
||||
### 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.
|
||||
-->
|
||||
|
||||
过滤插件用于过滤出不能运行该 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
|
||||
nodes that passed the filtering phase. A plugin may use this data to update
|
||||
internal state or to generate logs/metrics.
|
||||
-->
|
||||
|
||||
后置过滤是一个信息性的扩展点。通过过滤阶段的节点列表将调用这些后置过滤。插件将使用这些数据来更新内部的状态或者生成日志/指标。
|
||||
|
||||
<!--
|
||||
**Note:** Plugins wishing to perform "pre-scoring" work should use the
|
||||
post-filter extension point.
|
||||
-->
|
||||
|
||||
**注意：**希望执行“预评分”工作的插件应该使用后置过滤扩展点。
|
||||
|
||||
<!--
|
||||
### Scoring
|
||||
-->
|
||||
|
||||
### 评分
|
||||
<!--
|
||||
### Score {#scoring}
|
||||
-->
|
||||
### 评分 {#scoring}
|
||||
|
||||
<!--
|
||||
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
|
||||
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.
|
||||
-->
|
||||
|
||||
评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#标准化评分)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。
|
||||
评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。
|
||||
|
||||
<!--
|
||||
### Normalize scoring
|
||||
### NormalizeScore {#normalize-scoring}
|
||||
-->
|
||||
|
||||
### 标准化评分
|
||||
### 标准化评分 {#normalize-scoring}
|
||||
|
||||
<!--
|
||||
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
|
||||
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.
|
||||
-->
|
||||
|
||||
标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#评分)结果被调用。每个插件在每个调度周期调用一次。
|
||||
标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。每个插件在每个调度周期调用一次。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
如果任何标准化评分插件返回错误，则调度阶段将终止。
|
||||
如果任何 NormalizeScore 插件返回错误，则调度阶段将终止。
|
||||
|
||||
<!--
|
||||
**Note:** Plugins wishing to perform "pre-reserve" work should use the
|
||||
normalize-scoring extension point.
|
||||
Plugins wishing to perform "pre-reserve" work should use the
|
||||
NormalizeScore extension point.
|
||||
-->
|
||||
|
||||
**注意：**希望执行“预保留”工作的插件应该使用标准化评分扩展点。
|
||||
{{< note >}}
|
||||
希望执行“预保留”工作的插件应该使用 NormalizeScore 扩展点。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### 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.
|
||||
-->
|
||||
|
||||
保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 pod 预留了资源时能够通知该插件。这是在调度器真正将 pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
|
||||
保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 Pod 预留了资源时能够通知该插件。这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
|
||||
|
||||
<!--
|
||||
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
|
||||
[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 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留)插件（失败时）或
|
||||
[绑定后](#绑定后)插件（成功时）。
|
||||
|
||||
<!--
|
||||
*Note: This concept used to be referred to as "assume".*
|
||||
-->
|
||||
|
||||
*注意：此概念曾被称为“假设”。*
|
||||
这个是调度周期的最后一步。一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留) 插件（失败时）或
|
||||
[绑定后](#post-bind) 插件（成功时）。
|
||||
|
||||
<!--
|
||||
### 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
|
||||
can do one of three things.
|
||||
_Permit_ plugins are invoked at the end of the scheduling cycle for each Pod, to
|
||||
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** \
|
||||
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. **批准** \
|
||||
一旦所有允许插件批准 pod 后，该 pod 将被发送以进行绑定。
|
||||
一旦所有 Permit 插件批准 Pod 后，该 Pod 将被发送以进行绑定。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
1. **拒绝** \
|
||||
如果任何允许插件拒绝 pod，则该 pod 将被返回到调度队列。这将触发[不保留](#不保留)插件。
|
||||
如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。这将触发[不保留](#不保留) 插件。
|
||||
|
||||
<!--
|
||||
1. **wait** (with a timeout) \
|
||||
If a permit plugin returns "wait", then the Pod is kept in the permit phase
|
||||
until a [plugin approves it](#frameworkhandle). If a timeout occurs, **wait**
|
||||
becomes **deny** and the Pod is returned to the scheduling queue, triggering
|
||||
[Unreserve](#unreserve) plugins.
|
||||
If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
|
||||
Pods list, and the binding cycle of this Pod starts but directly blocks until it
|
||||
gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
|
||||
and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
|
||||
plugins.
|
||||
-->
|
||||
|
||||
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 绑定**
|
||||
|
||||
<!--
|
||||
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
|
||||
-->
|
||||
|
||||
### 预绑定
|
||||
### 预绑定 {#pre-bind}
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
预绑定插件用于执行 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.
|
||||
-->
|
||||
|
||||
如果任何预绑定插件返回错误，则 pod 将被[拒绝](#不保留)并且返回到调度队列中。
|
||||
如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#不保留) 并且返回到调度队列中。
|
||||
|
||||
<!--
|
||||
### 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
|
||||
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
|
||||
Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are
|
||||
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
|
||||
|
|
@ -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.
|
||||
-->
|
||||
|
||||
这是个信息性的扩展点。绑定后插件在 pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
|
||||
这是个信息性的扩展点。绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
|
||||
|
||||
<!--
|
||||
### 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.
|
||||
-->
|
||||
|
||||
这是个信息性的扩展点。如果 pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 pod 的相关状态。
|
||||
这是个信息性的扩展点。如果 Pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 Pod 的相关状态。
|
||||
|
||||
<!--
|
||||
Plugins that use this extension point usually should also use
|
||||
|
|
@ -441,7 +423,7 @@ type QueueSortPlugin interface {
|
|||
|
||||
type PreFilterPlugin interface {
|
||||
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
|
||||
be disabled in the configuration. In 1.15, there are no default plugins for the
|
||||
scheduling framework.
|
||||
-->
|
||||
<!--
|
||||
You can enable or disable plugins in the scheduler configuration. If you are using
|
||||
Kubernetes v1.18 or later, most scheduling
|
||||
[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
|
||||
configurations are passed to the plugins at the time the scheduler initializes
|
||||
them. The configuration is an arbitrary value. The receiving plugin should
|
||||
decode and process the configuration.
|
||||
-->
|
||||
|
||||
调度器配置也可以包含插件的配置。这些配置在调度器初始化插件时传给插件。配置是一个任意值。接收插件应该解码并处理配置信息。
|
||||
|
||||
<!--
|
||||
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
|
||||
```
|
||||
<!--
|
||||
If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
|
||||
a scheduler profile and then define multiple profiles to fit various kinds of workload.
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
|
||||
-->
|
||||
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
|
||||
了解更多关于 [多配置文件](/docs/reference/scheduling/profiles/#multiple-profiles)。
|
||||
|
||||
{{% /capture %}}
|
||||
Loading…
Reference in New Issue