From d154005e4555db3bcad7105684cbde588eb5d829 Mon Sep 17 00:00:00 2001
From: chenrui <rui@meetup.com>
Date: Tue, 4 Dec 2018 20:34:26 -0500
Subject: [PATCH] zh-trans: add concepts/configuration/scheduler-perf-tuning
 (#11452)

* zh-trans: add concepts/configuration/scheduler-perf-tuning

* zh-trans: comment out the english script lines

* zh-trans: update per PR comments

* zh-trans: updates per PR suggestions
---
 .../configuration/scheduler-perf-tuning.md    | 175 ++++++++++++++++++
 1 file changed, 175 insertions(+)
 create mode 100644 content/zh/docs/concepts/configuration/scheduler-perf-tuning.md

diff --git a/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md b/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md
new file mode 100644
index 0000000000..3ca2c81c8d
--- /dev/null
+++ b/content/zh/docs/concepts/configuration/scheduler-perf-tuning.md
@@ -0,0 +1,175 @@
+---
+reviewers:
+- bsalamat
+title: 调度器性能调优
+content_template: templates/concept
+weight: 70
+---
+
+<!-- ---
+reviewers:
+- bsalamat
+title: Scheduler Performance Tuning
+content_template: templates/concept
+weight: 70
+--- -->
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.12" >}}
+
+<!-- Kube-scheduler is the Kubernetes default scheduler. It is responsible for
+placement of Pods on Nodes in a cluster. Nodes in a cluster that meet the
+scheduling requirements of a Pod are called "feasible" Nodes for the Pod. The
+scheduler finds feasible Nodes for a Pod and then runs a set of functions to
+score the feasible Nodes and picks 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". -->
+
+Kube-scheduler 是 Kubernetes 的默认调度器。负责将 Pods 安排到集群中的节点上。
+集群中达到 Pod 调度要求的节点也被称为这个 Pod 的“可行性”节点。
+调度器首先找出 Pod 的可行性节点，然后运行一套打分函数来为可行性节点打分，
+最后挑选出分数最高的可行性节点来运行 Pod。随后，调度器将这个决定通知给 API 服务器，
+这个通知流程叫做“绑定”（"Binding"）。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+<!-- ## Percentage of Nodes to Score -->
+## 可行性打分的节点比例
+
+<!-- Before Kubernetes 1.12, Kube-scheduler used to check the feasibility of all the
+nodes in a cluster and then scored the feasible ones. Kubernetes 1.12 has a new
+feature that allows the scheduler to stop looking for more feasible nodes once
+it finds a certain number of them. This improves the scheduler's performance in
+large clusters. The number is specified as a percentage of the cluster size and
+is controlled by a configuration option called `percentageOfNodesToScore`. The
+range should be between 1 and 100. Other values are considered as 100%. The
+default value of this option is 50%. A cluster administrator can change this value by providing a
+different value in the scheduler configuration. However, it may not be necessary to change this value. -->
+
+在 Kubernetes 1.12 之前， Kube-scheduler 曾经是检查集群中所有节点的可行性，并为它们依次打分。
+而在 Kubernetes 1.12 中加入了一项新的功能，允许调度器在找到足够合适的可行性节点之后，停止搜索。
+这项功能将提高调度器在大型集群应用中的性能。这是一个比例参数，通过一个名为 `percentageOfNodesToScore` 的配置选项，
+指明了集群大小中的比例。参数值范围在 1 到 100 之间。其它的数值将被认为是 100%。
+选项的默认值为 50%。集群管理员也可以在调度器的配置文件中，提供不同数值来做修改。
+但可能也并不需要修改这个值。
+
+```yaml
+apiVersion: componentconfig/v1alpha1
+kind: KubeSchedulerConfiguration
+algorithmSource:
+  provider: DefaultProvider
+
+...
+
+percentageOfNodesToScore: 50
+```
+
+{{< note >}}
+
+<!-- **Note**: In clusters with zero or less than 50 feasible nodes, the
+scheduler still checks all the nodes, simply because there are not enough
+feasible nodes to stop the scheduler's search early. -->
+
+**注意**：如果集群中可行性节点的数量为 0 或者小于 50 个，调度器还是会检查所有的节点，
+仅仅是因为没有足够多的可行性节点让调度器终止搜索。
+
+{{< /note >}}
+
+
+
+<!-- **To disable this feature**, you can set `percentageOfNodesToScore` to 100. -->
+可以将 `percentageOfNodesToScore` 设置为 100 来**禁止这项功能**。
+
+<!-- ### Tuning percentageOfNodesToScore -->
+### 调优 `percentageOfNodesToScore`
+
+<!-- `percentageOfNodesToScore` must be a value between 1 and 100
+with the default value of 50. There is also a hardcoded minimum value of 50
+nodes which is applied internally. The scheduler tries to find at
+least 50 nodes regardless of the value of `percentageOfNodesToScore`. This means
+that changing this option to lower values in clusters with several hundred nodes
+will not have much impact on the number of feasible nodes that the scheduler
+tries to find. This is intentional as this option is unlikely to improve
+performance noticeably in smaller clusters. In large clusters with over a 1000
+nodes setting this value to lower numbers may show a noticeable performance
+improvement. -->
+
+`percentageOfNodesToScore` 的数值必须在 1 到 100 之间，默认值为 50。
+在内部设计里面，还存在有硬编码的至少 50 个节点的要求。无论 `percentageOfNodesToScore` 设置如何，
+调度器都至少会搜索 50 个节点。换言之，在只有数百个节点的集群中调低这个参数，并不会对调度器搜索可行性节点有影响。
+这样设计是经过考虑的，因为在较小的集群中，这个参数并不会显著提升性能。
+而在超过 1000 个节点的大型集群中调低这个参数，将会有显著的性能提升。
+
+<!-- An important note to consider when setting this value is that when a smaller
+number of nodes in a cluster are checked for feasibility, some nodes are not
+sent to be scored for a given Pod. As a result, a Node which could possibly
+score a higher value for running the given Pod might not even be passed to the
+scoring phase. This would result in a less than ideal placement of the Pod. For
+this reason, the value should not be set to very low percentages. A general rule
+of thumb is to never set the value to anything lower than 30. Lower values
+should be used only when 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. -->
+
+在设置这个数值时，需要注意一点，如果集群中只有较少的一部分节点进行了可行性检查，
+有些节点将不会被作可行性打分。
+因而，有运行 Pod 可行性分数更高的节点甚至可能不会到达打分阶段。这会造成一个并不十分理想的安排结果。
+正因为如此，这个数值不应该设置得非常低。
+一个重要原则就是这个数值不应该小于 30。
+更小的数值只应该在应用对调度器的吞吐量十分敏感，而节点的可行性打分相对不重要的前提下使用。
+换言之，只要节点适合运行 Pod 就可以安排到该节点上运行。
+
+<!-- It is not recommended to lower this value from its default if your cluster has
+only several hundred Nodes. It is unlikely to improve the scheduler's
+performance significantly. -->
+
+如果集群只有数百个节点，我们不建议将参数值调到比默认值低。因为这并不能显著提升调度器的性能。
+
+<!-- ### How the scheduler iterates over Nodes -->
+### 调度器是如何遍历节点的
+
+<!-- This section is intended for those who want to understand the internal details
+of this feature. -->
+
+这一节是为那些希望了解这项功能内部细节的人准备的。
+
+<!-- In order to give all the Nodes in a cluster a fair chance of being considered
+for running Pods, the scheduler iterates over the nodes in a round robin
+fashion. You can imagine that Nodes are in an array. The scheduler starts from
+the start of the array and checks feasibility of the nodes until it finds enough
+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. -->
+
+为了让集群中所有的节点都有平等的机会被考虑运行 Pods，调度器需要以轮转的方式遍历所有的节点。
+你可以这样理解：所有节点都在记录在某数组之中，调度器从数组的一端开始检查节点的可行性，直到找到 `percentageOfNodesToScore`
+指明的、足够多的节点。对于下一个 pod，调度器将从前一个 Pod 的结束节点开始，继续开始搜索。
+
+<!-- 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: -->
+
+如果节点在不同的区域，调度器也将遍历不同区域的所有节点，保证不同区域的节点都会被考虑在列。
+例如，如果六个节点分布在两个区域：
+
+```
+Zone 1: Node 1, Node 2, Node 3, Node 4
+Zone 2: Node 5, Node 6
+```
+
+<!-- The Scheduler evaluates feasibility of the nodes in this order: -->
+
+调度器将会按照下面的顺序来对所有的节点进行可行性检查：
+
+```
+Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
+```
+
+<!-- After going over all the Nodes, it goes back to Node 1. -->
+
+当遍历完所有的节点后，会重新从 Node 1 开始搜索。
+
+{{% /capture %}}