diff --git a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
index cd5ad2a083..cc1bbda060 100644
--- a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -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 %}}
diff --git a/content/zh/docs/concepts/configuration/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
similarity index 50%
rename from content/zh/docs/concepts/configuration/scheduling-framework.md
rename to content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
index 40ad637ed4..bebea8d02e 100644
--- a/content/zh/docs/concepts/configuration/scheduling-framework.md
+++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
@@ -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 %}}