Merge pull request #44857 from my-git9/patch-11555

[zh-cn] sync scheduling-eviction/*

Author: k8s-ci-robot

content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

@@ -184,6 +184,7 @@ spec:
     source:
       resourceClaimTemplateName: large-black-cat-claim-template
 ```
+
 <!-- 
 ## Scheduling
 -->
@@ -252,6 +253,20 @@ set aside for it.
 这避免了 Pod 被调度到一个节点但无法在那里运行的情况，
 这种情况很糟糕，因为被挂起 Pod 也会阻塞为其保留的其他资源，如 RAM 或 CPU。
 
+{{< note >}}
+<!--
+Scheduling of pods which use ResourceClaims is going to be slower because of
+the additional communication that is required. Beware that this may also impact
+pods that don't use ResourceClaims because only one pod at a time gets
+scheduled, blocking API calls are made while handling a pod with
+ResourceClaims, and thus scheduling the next pod gets delayed.
+-->
+由于需要额外的通信，使用 ResourceClaim 的 Pod 的调度将会变慢。
+请注意，这也可能会影响不使用 ResourceClaim 的 Pod，因为一次仅调度一个
+Pod，在使用 ResourceClaim 处理 Pod 时会进行阻塞 API 调用，
+从而推迟调度下一个 Pod。
+{{< /note >}}
+
 <!-- 
 ## Monitoring resources
 -->
@@ -333,7 +348,7 @@ term_id="api-group" >}} are enabled. For details on that, see the
 parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
 kube-scheduler, kube-controller-manager and kubelet also need the feature gate.
 -->
-动态资源分配是一个 **alpha 特性**，只有在启用 `DynamicResourceAllocation`
+动态资源分配是一个 **Alpha 特性**，只有在启用 `DynamicResourceAllocation`
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 和 `resource.k8s.io/v1alpha1`
 {{< glossary_tooltip text="API 组" term_id="api-group" >}} 时才启用。

content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -16,7 +16,7 @@ In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text
 are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
 {{< glossary_tooltip term_id="kubelet" >}} can run them.
 -->
-在 Kubernetes 中，**调度** 是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+在 Kubernetes 中，**调度**是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}}
 放置到合适的{{< glossary_tooltip text="节点" term_id="node" >}}上，以便对应节点上的
 {{< glossary_tooltip term_id="kubelet" >}} 能够运行这些 Pod。
 
@@ -80,7 +80,7 @@ In a cluster, Nodes that meet the scheduling requirements for a Pod
 are called _feasible_ nodes. If none of the nodes are suitable, the pod
 remains unscheduled until the scheduler is able to place it.
 -->
-在一个集群中，满足一个 Pod 调度请求的所有节点称之为 **可调度节点**。
+在一个集群中，满足一个 Pod 调度请求的所有节点称之为**可调度节点**。
 如果没有任何一个节点能满足 Pod 的资源请求，
 那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。
 
@@ -92,7 +92,7 @@ the API server about this decision in a process called _binding_.
 -->
 调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，
 选出其中得分最高的节点来运行 Pod。之后，调度器将这个调度决定通知给
-kube-apiserver，这个过程叫做 **绑定**。
+kube-apiserver，这个过程叫做**绑定**。
 
 <!--
 Factors that need to be taken into account for scheduling decisions include
@@ -173,7 +173,7 @@ of the scheduler:
 * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
-* Read the [kube-scheduler config (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
+* Read the [kube-scheduler config (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) reference
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
 * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
@@ -185,7 +185,7 @@ of the scheduler:
 * 阅读关于[调度器性能调优](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * 阅读关于 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * 阅读关于 kube-scheduler 的[参考文档](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/)
-* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+* 阅读 [kube-scheduler 配置参考（v1）](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/)
 * 了解关于[配置多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
 * 了解关于[拓扑结构管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)
 * 了解关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)

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

@@ -34,10 +34,10 @@ picking a Node with the highest score among the feasible ones to run
 the Pod. The scheduler then notifies the API server about this decision
 in a process called _Binding_.
 -->
-在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。
+在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为**可调度** Node。
 调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分，
 之后选出其中得分最高的 Node 来运行 Pod。
-最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定（Binding）_。
+最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做**绑定（Binding）**。
 
 <!--
 This page explains performance tuning optimizations that are relevant for
@@ -55,7 +55,7 @@ accuracy (the scheduler rarely makes poor placement decisions).
 You configure this tuning setting via kube-scheduler setting
 `percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
 a threshold for scheduling nodes in your cluster.
- -->
+-->
 在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）
 和精度（调度器很少做出糟糕的放置决策）。
 
@@ -64,7 +64,7 @@ a threshold for scheduling nodes in your cluster.
 
 <!--
 ### Setting the threshold
- -->
+-->
 ### 设置阈值
 
 <!--
@@ -73,25 +73,25 @@ and 100. The value 0 is a special number which indicates that the kube-scheduler
 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。
 
 <!--
 To change the value, edit the
-[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1/)
 and then restart the scheduler.
 In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`.
- -->
-要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
-然后重启调度器。
+-->
+要修改这个值，先编辑
+[kube-scheduler 的配置文件](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/)然后重启调度器。
 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。
 
 <!--
 After you have made this change, you can run
- -->
+-->
 修改完成后，你可以执行
 
 ```bash
@@ -100,19 +100,19 @@ kubectl get pods -n kube-system | grep kube-scheduler
 
 <!--
 to verify that the kube-scheduler component is healthy.
- -->
+-->
 来检查该 kube-scheduler 组件是否健康。
 
 <!--
 ## Node scoring threshold {#percentage-of-nodes-to-score}
- -->
+-->
 ## 节点打分阈值 {#percentage-of-nodes-to-score}
 
 <!--
 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 可以在找到足够的可调度节点之后停止查找。
 在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
 
@@ -123,7 +123,7 @@ integer number of nodes. During scheduling, if the kube-scheduler has identified
 enough feasible nodes to exceed the configured percentage, the kube-scheduler
 stops searching for more feasible nodes and moves on to the
 [scoring phase](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation).
- -->
+-->
 你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。
 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果
 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，
@@ -133,38 +133,38 @@ kube-scheduler 将停止继续查找可调度节点并继续进行
 <!--
 [How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
 describes the process in detail.
- -->
-[调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes) 详细介绍了这个过程。
+-->
+[调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes)详细介绍了这个过程。
 
 <!--
 ### Default threshold
- -->
+-->
 ### 默认阈值
 
 <!--
 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-节点集群
 下取 50%，在 5000-节点的集群下取 10%。这个自动设置的参数的最低值是 5%。
 
 <!--
 This means that, the kube-scheduler always scores at least 5% of your cluster no
 matter how large the cluster is, unless you have explicitly set
 `percentageOfNodesToScore` to be smaller than 5.
- -->
+-->
 这意味着，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。
 
 <!--
 If you want the scheduler to score all nodes in your cluster, set
 `percentageOfNodesToScore` to 100.
- -->
+-->
 如果你想让调度器对集群内所有节点进行打分，则将 `percentageOfNodesToScore` 设置为 100。
 
 <!--
 ## Example
- -->
+-->
 ## 示例
 
 <!--
@@ -213,8 +213,8 @@ scheduler's performance significantly.
 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
 因为可调度节点太少，不足以停止调度器最初的过滤选择。
 
-同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为
-一个较低的值，则没有或者只有很小的效果。
+同理，在小规模集群中，如果你将 `percentageOfNodesToScore`
+设置为一个较低的值，则没有或者只有很小的效果。
 
 如果集群只有几百个节点或者更少，请保持这个配置的默认值。
 改变基本不会对调度器的性能有明显的提升。
@@ -300,7 +300,6 @@ After going over all the Nodes, it goes back to Node 1.
 ## {{% heading "whatsnext" %}}
 
 <!--
-* Check the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+* Check the [kube-scheduler configuration reference (v1)](/docs/reference/config-api/kube-scheduler-config.v1/)
 -->
-
-* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+* 参见 [kube-scheduler 配置参考（v1）](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/)

content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -116,12 +116,12 @@ The default value for `operator` is `Equal`.
 A toleration "matches" a taint if the keys are the same and the effects are the same, and:
 
 * the `operator` is `Exists` (in which case no `value` should be specified), or
-* the `operator` is `Equal` and the `value`s are equal.
+* the `operator` is `Equal` and the values should be equal.
 -->
 一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果，并且：
 
 * 如果 `operator` 是 `Exists`（此时容忍度不能指定 `value`），或者
-* 如果 `operator` 是 `Equal`，则它们的 `value` 应该相等。
+* 如果 `operator` 是 `Equal`，则它们的值应该相等。
 
 {{< note >}}
 <!--
@@ -212,7 +212,7 @@ scheduled onto the node (if it is not yet running on the node).
   则 Kubernetes 不会将 Pod 调度到该节点。
 * 如果未被忽略的污点中不存在 effect 值为 `NoSchedule` 的污点，
   但是存在至少一个 effect 值为 `PreferNoSchedule` 的污点，
-  则 Kubernetes 会 **尝试** 不将 Pod 调度到该节点。
+  则 Kubernetes 会**尝试**不将 Pod 调度到该节点。
 * 如果未被忽略的污点中存在至少一个 effect 值为 `NoExecute` 的污点，
   则 Kubernetes 不会将 Pod 调度到该节点（如果 Pod 还未在节点上运行），
   并且会将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。

content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md

@@ -168,8 +168,8 @@ your cluster. Those fields are:
 - **maxSkew** 描述这些 Pod 可能被不均匀分布的程度。你必须指定此字段且该数值必须大于零。
   其语义将随着 `whenUnsatisfiable` 的值发生变化：
 
-  - 如果你选择 `whenUnsatisfiable: DoNotSchedule`，则 `maxSkew` 定义目标拓扑中匹配 Pod 的数量与
-    **全局最小值**（符合条件的域中匹配的最小 Pod 数量，如果符合条件的域数量小于 MinDomains 则为零）
+  - 如果你选择 `whenUnsatisfiable: DoNotSchedule`，则 `maxSkew` 定义目标拓扑中匹配 Pod
+    的数量与**全局最小值**（符合条件的域中匹配的最小 Pod 数量，如果符合条件的域数量小于 MinDomains 则为零）
     之间的最大允许差值。例如，如果你有 3 个可用区，分别有 2、2 和 1 个匹配的 Pod，则 `MaxSkew` 设为 1，
     且全局最小值为 1。
   - 如果你选择 `whenUnsatisfiable: ScheduleAnyway`，则该调度器会更为偏向能够降低偏差值的拓扑域。
@@ -210,7 +210,7 @@ your cluster. Those fields are:
 
   - 指定的 `minDomains` 值必须大于 0。你可以结合 `whenUnsatisfiable: DoNotSchedule` 仅指定 `minDomains`。
   - 当符合条件的、拓扑键匹配的域的数量小于 `minDomains` 时，拓扑分布将“全局最小值”（global minimum）设为 0，
-    然后进行 `skew` 计算。“全局最小值” 是一个符合条件的域中匹配 Pod 的最小数量，
+    然后进行 `skew` 计算。“全局最小值”是一个符合条件的域中匹配 Pod 的最小数量，
     如果符合条件的域的数量小于 `minDomains`，则全局最小值为零。
   - 当符合条件的拓扑键匹配域的个数等于或大于 `minDomains` 时，该值对调度没有影响。
   - 如果你未指定 `minDomains`，则约束行为类似于 `minDomains` 等于 1。
@@ -751,7 +751,8 @@ There are some implicit conventions worth noting here:
   present. This implies that:
 
   1. any Pods located on those bypassed nodes do not impact `maxSkew` calculation - in the
-     above example, suppose the node `node1` does not have a label "zone", then the 2 Pods will
+     above [example](#example-conflicting-topologyspreadconstraints), suppose the node `node1`
+     does not have a label "zone", then the 2 Pods will
      be disregarded, hence the incoming Pod will be scheduled into zone `A`.
   2. the incoming Pod has no chances to be scheduled onto this kind of nodes -
      in the above example, suppose a node `node5` has the **mistyped** label `zone-typo: zoneC`
@@ -766,10 +767,11 @@ There are some implicit conventions worth noting here:
 
 - 调度器会忽略没有任何 `topologySpreadConstraints[*].topologyKey` 的节点。这意味着：
 
-  1. 位于这些节点上的 Pod 不影响 `maxSkew` 计算，在上面的例子中，假设节点 `node1` 没有标签 "zone"，
-     则 2 个 Pod 将被忽略，因此新来的 Pod 将被调度到可用区 `A` 中。
+  1. 位于这些节点上的 Pod 不影响 `maxSkew` 计算，在上面的[例子](#example-conflicting-topologyspreadconstraints)中，
+     假设节点 `node1` 没有标签 "zone"，则 2 个 Pod 将被忽略，因此新来的
+     Pod 将被调度到可用区 `A` 中。
   2. 新的 Pod 没有机会被调度到这类节点上。在上面的例子中，
-     假设节点 `node5` 带有 **拼写错误的** 标签 `zone-typo: zoneC`（且没有设置 `zone` 标签）。
+     假设节点 `node5` 带有**拼写错误的**标签 `zone-typo: zoneC`（且没有设置 `zone` 标签）。
      节点 `node5` 接入集群之后，该节点将被忽略且针对该工作负载的 Pod 不会被调度到那里。
 
 <!--
@@ -879,7 +881,7 @@ instead of using the Kubernetes defaults.
 对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些拓扑键的节点评分。
 这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同。
 
-如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和 `topology.kubernetes.io/zone` 标签，
+如果你的节点不会**同时**设置 `kubernetes.io/hostname` 和 `topology.kubernetes.io/zone` 标签，
 你应该定义自己的约束而不是使用 Kubernetes 的默认约束。
 {{< /note >}}