whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #23157 from tengqm/zh-resync-topologymgr

Browse Source 
[zh] Resync TopologyManager task
This commit is contained in:
Kubernetes Prow Robot
2020-09-01 23:45:07 -07:00
committed by GitHub
parent c92e5d7c5a 0f97bf3c67
commit 5845d84edc
1 changed files with 103 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/administer-cluster/topology-manager.md
+103 -85
View File
@@ -1,29 +1,23 @@
---
title: 控制节点上的拓扑管理策略
reviewers:
- ConnorDoyle
- klueska
- lmdaly
- nolancon
content_type: task
min-kubernetes-server-version: v1.18
---
<!--
---
title: Control Topology Management Policies on a node
reviewers:
- ConnorDoyle
- klueska
- lmdaly
- nolancon
- bg-chun
content_type: task
---
min-kubernetes-server-version: v1.18
-->
<!-- overview -->
{{< feature-state state="alpha" >}}
{{< feature-state state="beta" for_k8s_version="v1.18" >}}
<!--
An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.
@@ -41,17 +35,12 @@ In order to extract the best performance, optimizations related to CPU isolation
<!--
_Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations.
-->
_拓扑管理器（Topology Manager）_ 是一个 Kubelet 的一部分，旨在协调负责这些优化的一组组件。
_拓扑管理器（Topology Manager）_ 是一个 kubelet 的一部分，旨在协调负责这些优化的一组组件。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@@ -91,42 +80,59 @@ The hint is then stored in the Topology Manager for use by the *Hint Providers*
取决于所配置的策略，所选建议可用来决定节点接受或拒绝 Pod 。
之后，建议会被存储在拓扑管理器中，供 *建议提供者* 进行资源分配决策时使用。
<!--
### Enable the Topology Manager feature
Support for the Topology Manager requires `TopologyManager` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.18.
-->
### 启用拓扑管理器功能特性
对拓扑管理器的支持要求启用 `TopologyManager`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
从 Kubernetes 1.18 版本开始，这一特性默认是启用的。
<!--
### Topology Manager Policies
The Topology Manager currently:
- Aligns Pods of all QoS classes.
- Aligns the requested resources that Hint Provider provides topology hints for.
-->
### 拓扑管理器策略
<!--
The Topology Manager currently:
-->
当前拓扑管理器：
拓扑管理器目前：
<!--
- Works on Nodes with the `static` CPU Manager Policy enabled. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
- Works on Pods making CPU requests or Device requests via extended resources
-->
- 在启用了 `static` CPU 管理器策略的节点上起作用。 请参阅[控制 CPU 管理策略](/docs/tasks/administer-cluster/cpu-management-policies/)
- 适用于通过扩展资源发出 CPU 请求或设备请求的 Pod
- 对所有 QoS 类的 Pod 执行对齐操作
- 针对建议提供者所提供的拓扑建议，对请求的资源进行对齐
<!--
If these conditions are met, Topology Manager will align the requested resources.
-->
如果满足这些条件，则拓扑管理器将调整请求的资源。
如果满足这些条件，则拓扑管理器将对齐请求的资源。
<!--
To align CPU resources with other requested resources in a Pod Spec, the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
-->
{{< note >}}
为了将 Pod 规约中的 CPU 资源与其他请求资源对齐，CPU 管理器需要被启用并且
节点上应配置了适当的 CPU 管理器策略。
参看[控制 CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/).
{{< /note >}}
<!--
Topology Manager supports four allocation policies. You can set a policy via a Kubelet flag, `--topology-manager-policy`.
There are four supported policies:
-->
拓扑管理器支持四种分配策略。
您可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。
所支持的策略有四种：
<!--
* `none` (default)
* `best-effort`
* `restricted`
* `single-numa-node`
-->
拓扑管理器支持四种分配策略。
你可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。
所支持的策略有四种：
* `none` (默认)
* `best-effort`
* `restricted`
@@ -134,27 +140,26 @@ There are four supported policies:
<!--
### none policy {#policy-none}
This is the default policy and does not perform any topology alignment.
-->
### none 策略 {#policy-none}
<!--
This is the default policy and does not perform any topology alignment.
-->
这是默认策略，不执行任何拓扑对齐。
<!--
### best-effort policy {#policy-best-effort}
-->
### best-effort 策略 {#policy-best-effort}
<!--
For each container in a Guaranteed Pod, kubelet, with `best-effort` topology
management policy, calls each Hint Provider to discover their resource availability.
Using this information, the Topology Manager stores the
preferred NUMA Node affinity for that container. If the affinity is not preferred,
Topology Manager will store this and admit the pod to the node anyway.
-->
对于 Guaranteed 类的 Pod 中的每个容器，具有 `best-effort` 拓扑管理策略的 kubelet 将调用每个建议提供者以确定资源可用性。
### best-effort 策略 {#policy-best-effort}
对于 Guaranteed 类的 Pod 中的每个容器，具有 `best-effort` 拓扑管理策略的
kubelet 将调用每个建议提供者以确定资源可用性。
使用此信息，拓扑管理器存储该容器的首选 NUMA 节点亲和性。
如果亲和性不是首选，则拓扑管理器将存储该亲和性，并且无论如何都将 pod 接纳到该节点。
@@ -166,17 +171,17 @@ resource allocation decision.
<!--
### restricted policy {#policy-restricted}
-->
### restricted 策略 {#policy-restricted}
<!--
For each container in a Guaranteed Pod, kubelet, with `restricted` topology
management policy, calls each Hint Provider to discover their resource availability.
Using this information, the Topology Manager stores the
preferred NUMA Node affinity for that container. If the affinity is not preferred,
Topology Manager will reject this pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
-->
对于 Guaranteed 类 Pod 中的每个容器， 配置了 `restricted` 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。。
### restricted 策略 {#policy-restricted}
对于 Guaranteed 类 Pod 中的每个容器， 配置了 `restricted` 拓扑管理策略的 kubelet
调用每个建议提供者以确定其资源可用性。。
使用此信息，拓扑管理器存储该容器的首选 NUMA 节点亲和性。
如果亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod 。
这将导致 Pod 处于 `Terminated` 状态，且 Pod 无法被节点接纳。
@@ -185,21 +190,19 @@ Topology Manager will reject this pod from the node. This will result in a pod i
Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a ReplicaSet or Deployment to trigger a redeploy of the pod.
An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
-->
一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。
建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
还可以通过实现外部控制环，以启动对具有 `Topology Affinity` 错误的 Pod 的重新部署。
<!--
If the pod is admitted, the *Hint Providers* can then use this information when making the
resource allocation decision.
-->
如果 Pod 被允许运行在该节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。
如果 Pod 被允许运行在某节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。
<!--
### single-numa-node policy {#policy-single-numa-node}
-->
### single-numa-node 策略 {#policy-single-numa-node}
<!--
For each container in a Guaranteed Pod, kubelet, with `single-numa-node` topology
management policy, calls each Hint Provider to discover their resource availability.
Using this information, the Topology Manager determines if a single NUMA Node affinity is possible.
@@ -207,7 +210,10 @@ If it is, Topology Manager will store this and the *Hint Providers* can then use
resource allocation decision.
If, however, this is not possible then the Topology Manager will reject the pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
-->
对于 Guaranteed 类 Pod 中的每个容器， 配置了 `single-numa-nodde` 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。
### single-numa-node 策略 {#policy-single-numa-node}
对于 Guaranteed 类 Pod 中的每个容器， 配置了 `single-numa-nodde` 拓扑管理策略的
kubelet 调用每个建议提供者以确定其资源可用性。
使用此信息，拓扑管理器确定单 NUMA 节点亲和性是否可能。
如果是这样，则拓扑管理器将存储此信息，然后 *建议提供者* 可以在做出资源分配决定时使用此信息。
如果不可能，则拓扑管理器将拒绝 Pod 运行于该节点。
@@ -217,17 +223,17 @@ If, however, this is not possible then the Topology Manager will reject the pod
Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a Deployment with replicas to trigger a redeploy of the Pod.
An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
-->
一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。
建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
还可以通过实现外部控制环，以触发具有 `Topology Affinity` 错误的 Pod 的重新部署。
<!--
### Pod Interactions with Topology Manager Policies
Consider the containers in the following pod specs:
-->
### Pod 与拓扑管理器策略的交互
<!--
Consider the containers in the following pod specs:
-->
考虑以下 pod 规范中的容器：
```yaml
@@ -241,7 +247,7 @@ spec:
This pod runs in the `BestEffort` QoS class because no resource `requests` or
`limits` are specified.
-->
该 Pod 在 `BestEffort` QoS 类中运行，因为没有指定资源 `requests` 或 `limits` 。
该 Pod 以 `BestEffort` QoS 类运行，因为没有指定资源 `requests` 或 `limits`。
```yaml
spec:
@@ -261,11 +267,12 @@ This pod runs in the `Burstable` QoS class because requests are less than limits
由于 requests 数少于 limits，因此该 Pod 以 `Burstable` QoS 类运行。
<!--
If the selected policy is anything other than `none` , Topology Manager would not consider either of these Pod
specifications.
If the selected policy is anything other than `none`, Topology Manager would consider these Pod specifications. The Topology Manager would consult the Hint Providers to get topology hints. In the case of the `static`, the CPU Manager policy would return default topology hint, because these Pods do not have explicity request CPU resources.
-->
如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器不会考虑这些 Pod 中的任何一个规范。
如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器都会评估这些 Pod 的规范。
拓扑管理器会咨询建议提供者，获得拓扑建议。
若策略为 `static`，则 CPU 管理器策略会返回默认的拓扑建议，因为这些 Pod
并没有显式地请求 CPU 资源。
```yaml
spec:
@@ -284,10 +291,10 @@ spec:
```
<!--
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
This pod with integer CPU request runs in the `Guaranteed` QoS class because
`requests` are equal to `limits`.
-->
此 Pod 在 `Guaranteed` QoS 类中运行，因为其 `requests` 值等于 `limits` 值。
此 Pod 以 `Guaranteed` QoS 类运行，因为其 `requests` 值等于 `limits` 值。
```yaml
spec:
@@ -302,48 +309,59 @@ spec:
example.com/deviceA: "1"
example.com/deviceB: "1"
```
<!--
This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
-->
由于没有 CPU 和内存请求，因此该 Pod 在 `BestEffort` QoS 类中运行。
因为未指定 CPU 和内存请求，所以 Pod 以 `BestEffort` QoS 类运行。
<!--
The Topology Manager would consider both of the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods.
In the case of the `Guaranteed` pod the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
In the case of the `Guaranteed` pod with integer request, the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
-->
拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询 CPU 和设备管理器，以获取 Pod 的拓扑提示。
对于 `Guaranteed` Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示，而设备管理器将返回有关所请求设备的提示。
拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询建议提供者即 CPU 和设备管理器，以获取 Pod 的拓扑提示。
对于 `Guaranteed` 类的 CPU 请求数为整数的 Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示，
而设备管理器将返回有关所请求设备的提示。
<!--
In the case of the `BestEffort` pod the CPU Manager would send back the default hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
In the case of the `Guaranteed` pod with sharing CPU request, the `static` CPU Manager policy would return default topology hint as there is no exclusive CPU request and the Device Manager would send back hints for the requested device.
In the above two cases of the `Guaranteed` pod, the `none` CPU Manager policy would return default topology hint.
-->
对于 `BestEffort` Pod，由于没有 CPU 请求，CPU 管理器将发送默认提示，而设备管理器将为每个请求的设备发送提示。
对于 `Guaranteed` 类的 CPU 请求可共享的 Pod，`static` CPU
管理器策略将返回默认的拓扑提示，因为没有排他性的 CPU 请求；而设备管理器
则针对所请求的设备返回有关提示。
在上述两种 `Guaranteed` Pod 的情况中，`none` CPU 管理器策略会返回默认的拓扑提示。
<!--
In the case of the `BestEffort` pod, the `static` CPU Manager policy would send back the default topology hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
-->
对于 `BestEffort` Pod，由于没有 CPU 请求，`static` CPU 管理器策略将发送默认提示，
而设备管理器将为每个请求的设备发送提示。
<!--
Using this information the Topology Manager calculates the optimal hint for the pod and stores this information, which will be used by the Hint Providers when they are making their resource assignments.
-->
使用此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供提示提供程序在进行资源分配时使用。
基于此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供
提示提供程序在进行资源分配时使用。
<!--
### Known Limitations
1. The maximum number of NUMA nodes that Topology Manager allows is 8. With more than 8 NUMA nodes there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
3. The Device Manager and the CPU Manager are the only components to adopt the Topology Manager's HintProvider interface. This means that NUMA alignment can only be achieved for resources managed by the CPU Manager and the Device Manager. Memory or Hugepages are not considered by the Topology Manager for NUMA alignment.
-->
### 已知的局限性
<!--
1. As of K8s 1.16 the Topology Manager is currently only guaranteed to work if a *single* container in the pod spec requires aligned resources. This is due to the hint generation being based on current resource allocations, and all containers in a pod generate hints before any resource allocation has been made. This results in unreliable hints for all but the first container in a pod.
*Due to this limitation if multiple pods/containers are considered by Kubelet in quick succession they may not respect the Topology Manager policy.
-->
1. 从 K8s 1.16 开始，当前只能在保证 Pod 规范中的 *单个* 容器需要相匹配的资源时，拓扑管理器才能正常工作。这是由于生成的提示信息是基于当前资源分配的，并且 pod 中的所有容器都会在进行任何资源分配之前生成提示信息。这样会导致除 Pod 中的第一个容器以外的所有容器生成不可靠的提示信息。
* 由于此限制，如果 kubelet 快速连续考虑多个 Pod/容器，它们可能不遵守拓扑管理器策略。
<!--
2. The maximum number of NUMA nodes that Topology Manager will allow is 8, past this there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
-->
2. 拓扑管理器允许的最大 NUMA 节点数为 8，并且在尝试枚举可能的 NUMA 关联并生成其提示信息时，将出现状态问题。
<!--
3. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
-->
3. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。
1. 拓扑管理器所能处理的最大 NUMA 节点个数是 8。若 NUMA 节点数超过 8，
枚举可能的 NUMA 亲和性并为之生成提示时会发生状态爆炸。
2. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。
3. 设备管理器和 CPU 管理器时能够采纳拓扑管理器 HintProvider 接口的唯一两个组件。
这意味着 NUMA 对齐只能针对 CPU 管理器和设备管理器所管理的资源实现。
内存和大页面在拓扑管理器决定 NUMA 对齐时都还不会被考虑在内。