[zh] Sync changes from English site (7)

Author: tengqm

content/zh/docs/concepts/scheduling-eviction/eviction-policy.md

@@ -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/)，
-  进一步了解驱逐信号、阈值以及处理方法。
+  进一步了解驱逐信号和阈值。
 

content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -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},

content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -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，因为可调度节点太少，不足以停止调度器最初的过滤选择。
-
-同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为一个较低的值，则没有或者只有很小的效果。
+当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
+因为可调度节点太少，不足以停止调度器最初的过滤选择。
 
-如果集群只有几百个节点或者更少，请保持这个配置的默认值。改变基本不会对调度器的性能有明显的提升。
+同理，在小规模集群中，如果你将 `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，从头开始。
 
-