zh-trans: docs/concepts/scheduling/scheduler-perf-tuning.md

[GeorgeSen]

No description provided.

[SataQiu]

Thanks @GeorgeSen
Add some comments！

[SataQiu]

1. 去掉译文中的 reviewers，译文不需要加 reviewers 字段，因为不需要外国友人评审
2. 将译文和注释了的原文调换顺序，文档开头不能是注释，会影响 hugo 渲染，页面不正常

[GeorgeSen]

已修改

[SataQiu]

中文译文， 不用写成复数形式 Pods、Nodes，建议直接使用单数形式 Pod、Node

Suggested change

	作为 kubernetes 集群的默认调度器，kube-scheduler 主要负责将 Pods 调度到集群的 Nodes 上。
	作为 kubernetes 集群的默认调度器，kube-scheduler 主要负责将 Pod 调度到集群的 Node 上。

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	在一个集群中，满足一个 Pod 调度请求的所有 Nodes 称之为_可调度_节点。调度器先在集群中找到一个 Pod 的可调度节点，然后根据一系列函数对这些可调度节点打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做节点绑定。
	在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定_。

[GeorgeSen]

已修改

[SataQiu]

Suggested change

在 Kubernetes 1.12 版本之前，kube-scheduler 会检查集群中所有节点的可调度性，并且给可调度节点打分。Kubernetes 1.12 版本添加了一个新的特性功能，其允许调度器在找到一定数量的可调度节点之后就停止继续寻找可调度节点。这个特性能提高调度器在大规模集群下的调度性能。这个数值是集群规模的百分比。这个百分比通过 percentageOfNodesToScore 参数来进行配置。其值的范围在 1 到 100 之间。最大值就是 100%。如果设置为 0 就代表没有提供这个参数配置。Kubernetes 1.14 版本又加入了一个特性，在该参数没有被用户配置的情况下，调度器会根据集群的规模自动设置一个集群比例，然后通过这个比例筛选一定数量的可调度节点进入打分阶段。该特性使用线性公式计算出集群比例，如在 100-node 的集群下取 50%。在 5000-node 的集群下取 10%。这个自动设置的参数的最低值是 5%。换句话说，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。

在 Kubernetes 1.12 版本之前，kube-scheduler 会检查集群中所有节点的可调度性，并且给可调度节点打分。Kubernetes 1.12 版本添加了一个新的功能，允许调度器在找到一定数量的可调度节点之后就停止继续寻找可调度节点。该功能可提高调度器在大规模集群下的调度性能。这个数值是集群规模的百分比。这个百分比通过 `percentageOfNodesToScore` 参数来进行配置。其值的范围在 1 到 100 之间，最大值就是 100%。如果设置为 0 就代表没有提供这个参数配置。Kubernetes 1.14 版本又加入了一个特性，在该参数没有被用户配置的情况下，调度器会根据集群的规模自动设置一个集群比例，然后通过这个比例筛选一定数量的可调度节点进入打分阶段。该特性使用线性公式计算出集群比例，如在 100-node 的集群下取 50%。在 5000-node 的集群下取 10%。这个自动设置的参数的最低值是 5%。换句话说，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	{{< note >}} 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Nodes，因为可调度节点太少不足以停止调度器最初的过滤选择。{{< /note >}}
	{{< note >}} 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。{{< /note >}}

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	### 调度器做调度选择的时候如何覆盖所有的 Nodes
	### 调度器做调度选择的时候如何覆盖所有的 Node

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	在将 Pods 调度到 Nodes 上时，为了让集群中所有 Nodes 都有公平的机会去运行这些 Pods，调度器将会以轮询的方式覆盖全部的 nodes。你可以将 Nodes 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Nodes 列表的位置，将会来作为这次调度筛选 Nodes 开始的位置。
	在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	如果集群中的 Nodes 在多个区域，那么调度器将从不同的区域中轮询 Nodes，来确保不同区域的 Nodes 接受可调度性检查。如下例，考虑两个区域中的六个节点：
	如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	调度器将会按照如下的顺序去评估 Nodes 的可调度性：
	调度器将会按照如下的顺序去评估 Node 的可调度性：

[GeorgeSen]

已修改

[SataQiu]

Suggested change

	在评估完所有 Nodes 后，将会返回到 Node 1，从头开始。
	在评估完所有 Node 后，将会返回到 Node 1，从头开始。

[GeorgeSen]

已修改

[SataQiu]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SataQiu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• content/zh/OWNERS [SataQiu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[SataQiu]

中文译文不需要写 reviewers，可以去掉这个字段，因为不需要外国友人审阅了

[GeorgeSen]

已修改

[SataQiu]

建议调换文档头译文跟原文的先后顺序，文档不要以注释开头，会打乱 hugo 构建，造成页面显示异常

[GeorgeSen]

已修改

[SataQiu]

/lgtm

[GeorgeSen]

ok