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
This commit is contained in:
chenrui
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
953ab2f96c
commit
d154005e45
@@ -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 %}}
|
||||
Reference in New Issue
Block a user