From 0f97bf3c670ffec7659da66c6ca0a161e971e89e Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 15 Aug 2020 20:24:22 +0800 Subject: [PATCH] [zh] Resync TopologyManager task Mainly fix the upstream English text changes. --- .../administer-cluster/topology-manager.md | 188 ++++++++++-------- 1 file changed, 103 insertions(+), 85 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/topology-manager.md b/content/zh/docs/tasks/administer-cluster/topology-manager.md index c0eb000957..d197f5dcf7 100644 --- a/content/zh/docs/tasks/administer-cluster/topology-manager.md +++ b/content/zh/docs/tasks/administer-cluster/topology-manager.md @@ -1,29 +1,23 @@ --- title: 控制节点上的拓扑管理策略 -reviewers: -- ConnorDoyle -- klueska -- lmdaly -- nolancon - content_type: task +min-kubernetes-server-version: v1.18 --- -{{< feature-state state="alpha" >}} +{{< feature-state state="beta" for_k8s_version="v1.18" >}} -_拓扑管理器（Topology Manager）_ 是一个 Kubelet 的一部分，旨在协调负责这些优化的一组组件。 - - +_拓扑管理器（Topology Manager）_ 是一个 kubelet 的一部分，旨在协调负责这些优化的一组组件。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - +### 启用拓扑管理器功能特性 + +对拓扑管理器的支持要求启用 `TopologyManager` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +从 Kubernetes 1.18 版本开始，这一特性默认是启用的。 + ### 拓扑管理器策略 - -当前拓扑管理器： +拓扑管理器目前： - -- 在启用了 `static` CPU 管理器策略的节点上起作用。 请参阅[控制 CPU 管理策略](/docs/tasks/administer-cluster/cpu-management-policies/) -- 适用于通过扩展资源发出 CPU 请求或设备请求的 Pod +- 对所有 QoS 类的 Pod 执行对齐操作 +- 针对建议提供者所提供的拓扑建议，对请求的资源进行对齐 -如果满足这些条件，则拓扑管理器将调整请求的资源。 +如果满足这些条件，则拓扑管理器将对齐请求的资源。 + + +{{< note >}} +为了将 Pod 规约中的 CPU 资源与其他请求资源对齐，CPU 管理器需要被启用并且 +节点上应配置了适当的 CPU 管理器策略。 +参看[控制 CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/). +{{< /note >}} -拓扑管理器支持四种分配策略。 -您可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。 -所支持的策略有四种： - +拓扑管理器支持四种分配策略。 +你可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。 +所支持的策略有四种： + * `none` (默认) * `best-effort` * `restricted` @@ -134,27 +140,26 @@ There are four supported policies: ### none 策略 {#policy-none} - 这是默认策略，不执行任何拓扑对齐。 -### best-effort 策略 {#policy-best-effort} - -对于 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-restricted} - -对于 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 的重新部署。 -如果 Pod 被允许运行在该节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。 +如果 Pod 被允许运行在某节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。 -### single-numa-node 策略 {#policy-single-numa-node} - -对于 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 与拓扑管理器策略的交互 - 考虑以下 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 类运行。 -如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器不会考虑这些 Pod 中的任何一个规范。 - +如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器都会评估这些 Pod 的规范。 +拓扑管理器会咨询建议提供者，获得拓扑建议。 +若策略为 `static`，则 CPU 管理器策略会返回默认的拓扑建议，因为这些 Pod +并没有显式地请求 CPU 资源。 ```yaml spec: @@ -284,10 +291,10 @@ spec: ``` -此 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" ``` + -由于没有 CPU 和内存请求，因此该 Pod 在 `BestEffort` QoS 类中运行。 +因为未指定 CPU 和内存请求，所以 Pod 以 `BestEffort` QoS 类运行。 -拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询 CPU 和设备管理器，以获取 Pod 的拓扑提示。 -对于 `Guaranteed` Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示，而设备管理器将返回有关所请求设备的提示。 +拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询建议提供者即 CPU 和设备管理器，以获取 Pod 的拓扑提示。 +对于 `Guaranteed` 类的 CPU 请求数为整数的 Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示， +而设备管理器将返回有关所请求设备的提示。 -对于 `BestEffort` Pod，由于没有 CPU 请求，CPU 管理器将发送默认提示，而设备管理器将为每个请求的设备发送提示。 +对于 `Guaranteed` 类的 CPU 请求可共享的 Pod，`static` CPU +管理器策略将返回默认的拓扑提示，因为没有排他性的 CPU 请求；而设备管理器 +则针对所请求的设备返回有关提示。 + +在上述两种 `Guaranteed` Pod 的情况中，`none` CPU 管理器策略会返回默认的拓扑提示。 + + +对于 `BestEffort` Pod，由于没有 CPU 请求，`static` CPU 管理器策略将发送默认提示， +而设备管理器将为每个请求的设备发送提示。 -使用此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供提示提供程序在进行资源分配时使用。 +基于此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供 +提示提供程序在进行资源分配时使用。 ### 已知的局限性 - -1. 从 K8s 1.16 开始，当前只能在保证 Pod 规范中的 *单个* 容器需要相匹配的资源时，拓扑管理器才能正常工作。这是由于生成的提示信息是基于当前资源分配的，并且 pod 中的所有容器都会在进行任何资源分配之前生成提示信息。这样会导致除 Pod 中的第一个容器以外的所有容器生成不可靠的提示信息。 -* 由于此限制，如果 kubelet 快速连续考虑多个 Pod/容器，它们可能不遵守拓扑管理器策略。 - - -2. 拓扑管理器允许的最大 NUMA 节点数为 8，并且在尝试枚举可能的 NUMA 关联并生成其提示信息时，将出现状态问题。 - - -3. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。 - +1. 拓扑管理器所能处理的最大 NUMA 节点个数是 8。若 NUMA 节点数超过 8， + 枚举可能的 NUMA 亲和性并为之生成提示时会发生状态爆炸。 +2. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。 +3. 设备管理器和 CPU 管理器时能够采纳拓扑管理器 HintProvider 接口的唯一两个组件。 + 这意味着 NUMA 对齐只能针对 CPU 管理器和设备管理器所管理的资源实现。 + 内存和大页面在拓扑管理器决定 NUMA 对齐时都还不会被考虑在内。