[zh] Sync changes from English site (7)

2020-11-16 14:16:15 +08:00
parent edbab98ce4
commit 089040daa7
10 changed files with 494 additions and 347 deletions
@@ -1,11 +1,11 @@
 ---
 title: 驱逐策略
-content_template: templates/concept
+content_type: concept
 weight: 60
 ---
 <!--
 title: Eviction Policy
-content_template: templates/concept
+content_type: concept
 weight: 60
 -->

@@ -20,25 +20,28 @@ This page is an overview of Kubernetes' policy for eviction.
 <!--
 ## Eviction Policy

-The {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} can proactively monitor for and prevent total starvation of a
-compute resource. In those cases, the `kubelet` can reclaim the starved
-resource by proactively failing one or more Pods. When the `kubelet` fails
+The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for
+and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim
+the starved resource by failing one or more Pods. When the `kubelet` fails
 a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
-If the evicted Pod is managed by a Deployment, the Deployment will create another Pod
+If the evicted Pod is managed by a Deployment, the Deployment creates another Pod
 to be scheduled by Kubernetes.
 -->
 ## 驱逐策略  {#eviction-policy}

-{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 能够主动监测和防止计算资源的全面短缺。
-在资源短缺的情况下，`kubelet` 可以主动地结束一个或多个 Pod 以回收短缺的资源。
-当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase` 将变为 `Failed`。
-如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 Kubernetes 来调度。
+{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 主动监测和防止
+计算资源的全面短缺。在资源短缺时，`kubelet` 可以主动地结束一个或多个 Pod
+以回收短缺的资源。
+当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase`
+将变为 `Failed`。
+如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给
+Kubernetes 来调度。

 ## {{% heading "whatsnext" %}}

 <!--
- Read [Configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) to learn more about eviction signals, thresholds, and handling.
+- Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds.
 -->
 - 阅读[配置资源不足的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，
-  进一步了解驱逐信号、阈值以及处理方法。
+  进一步了解驱逐信号和阈值。

@@ -26,23 +26,25 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
 <!--
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation

-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
+Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
 consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
 -->

 ## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱

-在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量
-之比率对节点评分。
+在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）
+的请求数量和可用容量 之比率对节点评分。
 Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
 以便根据请求数量与可用容量之比率为节点评分。
 这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
 `RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
 `requestedToCapacityRatioArguments` 的配置选项进行控制。
 该标志由两个参数 `shape` 和 `resources` 组成。
-shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或
+`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求
+（least requested）或
 最多请求（most requested）计算。
-resources 由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 
+`resources` 包含由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，
+`weight` 指定每种资源的权重。 

 <!--
 Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
@@ -53,29 +55,29 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`

 ```json
 {
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-    ...
-    "priorities" : [
-       ...
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
+  "kind": "Policy",
+  "apiVersion": "v1",
+  ...
+  "priorities": [
+     ...
+    {
+      "name": "RequestedToCapacityRatioPriority",
+      "weight": 2,
+      "argument": {
+        "requestedToCapacityRatioArguments": {
+          "shape": [
+            {"utilization": 0, "score": 0},
+            {"utilization": 100, "score": 10}
+          ],
+          "resources": [
+            {"name": "intel.com/foo", "weight": 3},
+            {"name": "intel.com/bar", "weight": 5}
+          ]
        }
      }
-    ],
-  }
+    }
+  ],
+}
 ```

 <!--
@@ -89,7 +91,6 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`

 `shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
 -->
-
 ### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数

 `shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。
@@ -103,8 +104,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
 The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
 -->

-上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10，
-因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。
+上面的参数在 `utilization` 为 0% 时给节点评分为 0，在 `utilization` 为
+100% 时给节点评分为 10，因此启用了装箱行为。
+要启用最少请求（least requested）模式，必须按如下方式反转得分值。

 ```yaml
 {"utilization": 0, "score": 100},
@@ -54,7 +54,8 @@ You configure this tuning setting via kube-scheduler setting
 `percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
 a threshold for scheduling nodes in your cluster.
 -->
-在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。
+在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）
+和精度（调度器很少做出糟糕的放置决策）。

 你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。
 这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
@@ -71,33 +72,32 @@ should use its compiled-in default.
 If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
 had set a value of 100.
 -->
-`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
-如果你设置 `percentageOfNodesToScore` 的值超过了 100，kube-scheduler 的表现等价于设置值为 100。
+`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。
+0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
+如果你设置 `percentageOfNodesToScore` 的值超过了 100，
+kube-scheduler 的表现等价于设置值为 100。

 <!-- 
 To change the value, edit the kube-scheduler configuration file (this is likely
 to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
 -->
-要修改这个值，编辑 kube-scheduler 的配置文件（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），然后重启调度器。
+要修改这个值，编辑 kube-scheduler 的配置文件
+（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），
+然后重启调度器。

 <!-- 
 After you have made this change, you can run
 -->
 修改完成后，你可以执行
+
 ```bash
-kubectl get componentstatuses
+kubectl get pods -n kube-system | grep kube-scheduler
 ```

 <!-- 
-to verify that the kube-scheduler component is healthy. The output is similar to:
+to verify that the kube-scheduler component is healthy.
 -->
-来检查该 kube-scheduler 组件是否健康。输出类似如下：
-```
-NAME                 STATUS    MESSAGE             ERROR
-controller-manager   Healthy   ok
-scheduler            Healthy   ok
-...
-```
+来检查该 kube-scheduler 组件是否健康。

 <!-- 
 ## Node scoring threshold {#percentage-of-nodes-to-score}
@@ -109,7 +109,8 @@ To improve scheduling performance, the kube-scheduler can stop looking for
 feasible nodes once it has found enough of them. In large clusters, this saves
 time compared to a naive approach that would consider every node.
 -->
-要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
+要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。
+在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。

 <!-- 
 You specify a threshold for how many nodes are enough, as a whole number percentage
@@ -141,8 +142,8 @@ If you don't specify a threshold, Kubernetes calculates a figure using a
 linear formula that yields 50% for a 100-node cluster and yields 10%
 for a 5000-node cluster. The lower bound for the automatic value is 5%.
 -->
-如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-node 集群下取 50%，在 5000-node 的集群下取 10%。
-这个自动设置的参数的最低值是 5%。
+如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-节点集群
+下取 50%，在 5000-节点的集群下取 10%。这个自动设置的参数的最低值是 5%。

 <!-- 
 This means that, the kube-scheduler always scores at least 5% of your cluster no
@@ -205,12 +206,14 @@ scheduler's performance significantly.
 {{< /note >}}
 -->
 {{< note >}}
-当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。
+当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
+因为可调度节点太少，不足以停止调度器最初的过滤选择。

-同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为一个较低的值，则没有或者只有很小的效果。
-
-如果集群只有几百个节点或者更少，请保持这个配置的默认值。改变基本不会对调度器的性能有明显的提升。
+同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为
+一个较低的值，则没有或者只有很小的效果。

+如果集群只有几百个节点或者更少，请保持这个配置的默认值。
+改变基本不会对调度器的性能有明显的提升。
 {{< /note >}}

 <!--
@@ -226,9 +229,15 @@ percentage to anything below 10%, unless the scheduler's throughput is critical
 for your application and the score of nodes is not important. In other words, you
 prefer to run the Pod on any Node as long as it is feasible.
 -->
-值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 node 都没有进入到打分阶段。这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。
+值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，
+很多节点都没有进入到打分阶段。这样就会造成一种后果，
+一个本来可以在打分阶段得分很高的节点甚至都不能进入打分阶段。

-由于这个原因，这个参数不应该被设置成一个很低的值。通常的做法是不会将这个参数的值设置的低于 10。很低的参数值一般在调度器的吞吐量很高且对 node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。
+由于这个原因，这个参数不应该被设置成一个很低的值。
+通常的做法是不会将这个参数的值设置的低于 10。
+很低的参数值一般在调度器的吞吐量很高且对节点的打分不重要的情况下才使用。
+换句话说，只有当你更倾向于在可调度节点中任意选择一个节点来运行这个 Pod 时，
+才使用很低的参数设置。

 <!--
 ### How the scheduler iterates over Nodes
@@ -250,14 +259,20 @@ Nodes as specified by `percentageOfNodesToScore`. For the next Pod, the
 scheduler continues from the point in the Node array that it stopped at when
 checking feasibility of Nodes for the previous Pod.
 -->
-在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。
+在将 Pod 调度到节点上时，为了让集群中所有节点都有公平的机会去运行这些 Pod，
+调度器将会以轮询的方式覆盖全部的 Node。
+你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，
+依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。
+在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，
+将会来作为这次调度筛选 Node 开始的位置。

 <!--
 If Nodes are in multiple zones, the scheduler iterates over Nodes in various
 zones to ensure that Nodes from different zones are considered in the
 feasibility checks. As an example, consider six nodes in two zones:
 -->
-如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
+如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，
+来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：

 ```
 Zone 1: Node 1, Node 2, Node 3, Node 4
@@ -278,4 +293,3 @@ After going over all the Nodes, it goes back to Node 1.
 -->
 在评估完所有 Node 后，将会返回到 Node 1，从头开始。

-
@@ -7,13 +7,11 @@ weight: 70
 ---

 <!--
---
 reviewers:
 - ahg-g
 title: Scheduling Framework
 content_type: concept
 weight: 60
---
 -->

 <!-- overview -->
@@ -29,19 +27,17 @@ scheduling "core" simple and maintainable. Refer to the [design proposal of the
 scheduling framework][kep] for more technical information on the design of the
 framework.
 -->
-
-调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考[调度框架的设计提案][kep]获取框架设计的更多技术信息。
-
-[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
-
-
+调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。
+它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。
+这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。
+请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
+获取框架设计的更多技术信息。

 <!-- body -->

 <!--
 # Framework workflow
 -->
-
 # 框架工作流程

 <!--
@@ -49,20 +45,18 @@ The Scheduling Framework defines a few extension points. Scheduler plugins
 register to be invoked at one or more extension points. Some of these plugins
 can change the scheduling decisions and some are informational only.
 -->
-
-调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。
+调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。
+这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。

 <!--
 Each attempt to schedule one Pod is split into two phases, the **scheduling
 cycle** and the **binding cycle**.
 -->
-
 每次调度一个 Pod 的尝试都分为两个阶段，即 **调度周期** 和 **绑定周期**。

 <!--
 ## Scheduling Cycle & Binding Cycle
 -->
-
 ## 调度周期和绑定周期

 <!--
@@ -70,13 +64,12 @@ The scheduling cycle selects a node for the Pod, and the binding cycle applies
 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.
 -->
-
 调度周期是串行运行的，而绑定周期可能是同时运行的。

 <!--
@@ -84,13 +77,12 @@ A scheduling or binding cycle can be aborted if the Pod is determined to
 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
 -->
-
 ## 扩展点

 <!--
@@ -98,14 +90,13 @@ The following picture shows the scheduling context of a Pod and the extension
 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
 stateful tasks.
 -->
-
 一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。

 <!-- 
@@ -113,7 +104,6 @@ stateful tasks.
 -->
 {{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}}

-
 <!--
 ### QueueSort {#queue-sort}
 -->
@@ -124,13 +114,13 @@ These plugins are used to sort Pods in the scheduling queue. A queue sort plugin
 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)` 函数。
+一次只能启动一个队列插件。

 <!--
 ### PreFilter {#pre-filter}
 -->
-
 ### 前置过滤 {#pre-filter}

 <!--
@@ -138,13 +128,12 @@ 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 PreFilter plugin returns
 an error, the scheduling cycle is aborted.
 -->
-
-前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。如果 PreFilter 插件返回错误，则调度周期将终止。
+前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。
+如果 PreFilter 插件返回错误，则调度周期将终止。

 <!--
 ### Filter
 -->
-
 ### 过滤

 <!--
@@ -153,13 +142,13 @@ node, the scheduler will call filter plugins in their configured order. If any
 filter plugin marks the node as infeasible, the remaining plugins will not be
 called for that node. Nodes may be evaluated concurrently.
 -->
-
-过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
+过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，
+调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，
+则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。

 <!--
 ### PostFilter {#post-filter}
 -->
-
 ### 后置过滤 {#post-filter}

 <!--
@@ -170,7 +159,10 @@ will not be called. A typical PostFilter implementation is preemption, which
 tries to make the pod schedulable by preempting other Pods.
 -->

-这些插件在筛选阶段后调用，但仅在该 pod 没有可行的节点时调用。插件按其配置的顺序调用。如果任何后过滤器插件标记节点为“可调度”， 则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 pod  的资源使该 pod 可以调度。
+这些插件在筛选阶段后调用，但仅在该 Pod 没有可行的节点时调用。
+插件按其配置的顺序调用。如果任何后过滤器插件标记节点为“可调度”，
+则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod
+的资源使该 Pod 可以调度。

 <!-- 
 ### PreScore {#pre-score}
@@ -182,7 +174,8 @@ 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 插件返回错误，则调度周期将终止。
+前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。
+如果 PreScore 插件返回错误，则调度周期将终止。

 <!-- 
 ### Score {#scoring}
@@ -196,13 +189,14 @@ defined range of integers representing the minimum and maximum scores. After the
 [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}

 <!--
@@ -211,14 +205,14 @@ ranking of Nodes. A plugin that registers for this extension point will be
 called with the [Score](#scoring) results from the same plugin. This is called
 once per plugin per scheduling cycle.
 -->
-
-标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。每个插件在每个调度周期调用一次。
+标准化评分插件用于在调度器计算节点的排名之前修改分数。
+在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。
+每个插件在每个调度周期调用一次。

 <!--
 For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how
 many blinking lights they have.
 -->
-
 例如，假设一个 `BlinkingLightScorer` 插件基于具有的闪烁指示灯数量来对节点进行排名。

 ```go
@@ -232,8 +226,8 @@ However, the maximum count of blinking lights may be small compared to
 `NodeScoreMax`. To fix this, `BlinkingLightScorer` should also register for this
 extension point.
 -->
-
-然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，`BlinkingLightScorer` 插件还应该注册该扩展点。
+然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，
+`BlinkingLightScorer` 插件还应该注册该扩展点。

 ```go
 func NormalizeScores(scores map[string]int) {
@@ -251,7 +245,6 @@ func NormalizeScores(scores map[string]int) {
 If any NormalizeScore plugin returns an error, the scheduling cycle is
 aborted.
 -->
-
 如果任何 NormalizeScore 插件返回错误，则调度阶段将终止。

 <!--
@@ -265,8 +258,7 @@ NormalizeScore extension point.
 <!--
 ### Reserve
 -->
-
-### 保留
+### Reserve

 <!--
 This is an informational extension point. Plugins which maintain runtime state
@@ -275,37 +267,38 @@ scheduler when resources on a node are being reserved for a given Pod. This
 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 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
+Reserve 是一个信息性的扩展点。
+管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便
+调度器在节点给指定 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
 [PostBind](#post-bind) plugins (on success) at the end of the binding cycle.
 -->
-
-这个是调度周期的最后一步。一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留) 插件（失败时）或
-[绑定后](#post-bind) 插件（成功时）。
+这个是调度周期的最后一步。
+一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#unreserve) 插件
+（失败时）或 [绑定后](#post-bind) 插件（成功时）。

 <!--
 ### Permit
 -->
-
-### 允许
+### Permit

 <!--
 _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:
 -->
-
-_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。一个允许插件可以做以下三件事之一：
+_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。
+一个允许插件可以做以下三件事之一：

 <!--
 1.  **approve** \
    Once all Permit plugins approve a Pod, it is sent for binding.
 -->
-
 1.  **批准** \
    一旦所有 Permit 插件批准 Pod 后，该 Pod 将被发送以进行绑定。

@@ -314,9 +307,9 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
    If any Permit plugin denies a Pod, it is returned to the scheduling queue.
    This will trigger [Unreserve](#unreserve) plugins.
 -->
-
 1.  **拒绝** \
-    如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。这将触发[不保留](#不保留) 插件。
+    如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。
+    这将触发[Unreserve](#unreserve) 插件。

 <!--
 1.  **wait** (with a timeout) \
@@ -326,9 +319,11 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
    and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
    plugins.
 -->
-
 1.  **等待**（带有超时） \
-    如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中” 的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到[批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod 将返回调度队列，从而触发[不保留](#不保留) 插件。
+    如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中”
+    的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到
+    [批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod
+    将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。


 <!-- 
@@ -338,13 +333,15 @@ plugins to approve binding of reserved Pods that are in "waiting" state. Once a
 is approved, it is sent to the [PreBind](#pre-bind) phase.
 -->
 {{< note >}}
-尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](#frameworkhandle))。我们希望只有允许插件可以批准处于 “等待中” 状态的 预留 Pod 的绑定。一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
+尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 
+(查看 [`FrameworkHandle`](#frameworkhandle))。
+我们希望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
+一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
 {{< /note >}}

 <!--
 ### Pre-bind {#pre-bind}
 -->
-
 ### 预绑定 {#pre-bind}

 <!--
@@ -352,21 +349,21 @@ These plugins are used to perform any work required before a Pod is bound. For
 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 PreBind plugin returns an error, the Pod is [rejected](#unreserve) and
 returned to the scheduling queue.
 -->
-
-如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#不保留) 并且返回到调度队列中。
+如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#unreserve) 并且
+退回到调度队列中。

 <!--
 ### Bind
 -->
-
-### 绑定
+### Bind

 <!--
 These plugins are used to bind a Pod to a Node. Bind plugins will not be called
@@ -375,13 +372,13 @@ 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 绑定到节点上。直到所有的 PreBind 插件都完成，绑定插件才会被调用。每个绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
+Bind 插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，Bind 插件才会被调用。
+各绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。
+如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。

 <!--
 ### PostBind {#post-bind}
 -->
-
 ### 绑定后 {#post-bind}

 <!--
@@ -389,34 +386,32 @@ This is an informational extension point. Post-bind plugins are called after a
 Pod is successfully bound. This is the end of a binding cycle, and can be used
 to clean up associated resources.
 -->
-
-这是个信息性的扩展点。绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
+这是个信息性的扩展点。
+绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。

 <!--
 ### Unreserve
 -->
-
-### 不保留
+### Unreserve

 <!--
 This is an informational extension point. If a Pod was reserved and then
 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 被保留，然后在后面的阶段中被拒绝，则 Unreserve 插件将被通知。
+Unreserve 插件应该清楚保留 Pod 的相关状态。

 <!--
 Plugins that use this extension point usually should also use
 [Reserve](#reserve).
 -->
-
-使用此扩展点的插件通常也使用[保留](#保留)。
+使用此扩展点的插件通常也使用[Reserve](#reserve)。

 <!--
 ## Plugin API
 -->
-
 ## 插件 API

 <!--
@@ -424,8 +419,8 @@ There are two steps to the plugin API. First, plugins must register and get
 configured, then they use the extension point interfaces. Extension point
 interfaces have the following form.
 -->
-
-插件 API 分为两个步骤。首先，插件必须注册并配置，然后才能使用扩展点接口。扩展点接口具有以下形式。
+插件 API 分为两个步骤。首先，插件必须完成注册并配置，然后才能使用扩展点接口。
+扩展点接口具有以下形式。

 ```go
 type Plugin interface {
@@ -448,7 +443,6 @@ type PreFilterPlugin interface {
 <!--
 # Plugin Configuration
 -->
-
 # 插件配置

 <!-- 
@@ -457,21 +451,26 @@ 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) 都在使用中且默认启用。
+你可以在调度器配置中启用或禁用插件。
+如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
+[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins)
+都在使用中且默认启用。

 <!-- 
 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) 了解更多详情。
+除了默认的插件，你还可以实现自己的调度插件并且将它们与默认插件一起配置。
+你可以访问[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins)
+了解更多信息。

 <!-- 
 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)。
-
+如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
+一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
+了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。