控制节点上的拓扑管理策略

越来越多的系统利用 CPU 和硬件加速器的组合来支持对延迟敏感的执行和高吞吐量的并行计算。这些包括电信、科学计算、机器学习、金融服务和数据分析等领域的工作负载。这样的混合系统构成了一个高性能环境。

为了提取最佳性能，需要与 CPU 隔离、内存和设备局部性相关的优化。然而，在 Kubernetes 中，这些优化是由一组不相关的组件处理的。

拓扑管理器是 kubelet 组件，旨在协调负责这些优化的组件集合。

开始之前

您需要一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与您的集群通信。建议在至少有两个节点（不充当控制平面主机）的集群上运行本教程。如果您还没有集群，可以使用 minikube 创建一个，或者可以使用以下 Kubernetes 游乐场

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

要检查版本，请输入 kubectl version。

拓扑管理器的工作原理

在引入拓扑管理器之前，Kubernetes 中的 CPU 和设备管理器独立地做出资源分配决策。这可能会导致在多套接字系统上产生不良分配，并且对延迟敏感的应用程序会因这些不良分配而受到影响。不良分配在此处意味着，例如，CPU 和设备被分配到不同的 NUMA 节点，从而产生额外的延迟。

拓扑管理器是 kubelet 组件，充当事实来源，以便其他 kubelet 组件可以做出与拓扑对齐的资源分配选择。

拓扑管理器为组件提供一个接口，称为提示提供程序，用于发送和接收拓扑信息。拓扑管理器有一组节点级别策略，如下所述。

拓扑管理器从提示提供程序接收拓扑信息，作为表示可用 NUMA 节点和首选分配指示的位掩码。拓扑管理器策略对提供的提示执行一组操作，并收敛到策略确定的提示，以获得最佳结果。如果存储了不良提示，则提示的首选字段将被设置为 false。当前策略中，首选是范围最窄的首选掩码。所选提示存储在拓扑管理器中，供提示提供程序在做出资源分配决策时使用。

可以在下面的图中看到流程。

Windows 支持

可以通过使用 WindowsCPUAndMemoryAffinity 特性门控并在容器运行时中提供支持，在 Windows 上启用拓扑管理器支持。

拓扑管理器范围和策略

拓扑管理器当前

• 对所有 QoS 类别的 Pod 进行对齐。
• 对提示提供程序提供的拓扑提示的请求资源进行对齐。

如果满足这些条件，拓扑管理器将对齐请求的资源。

为了自定义如何执行此对齐，拓扑管理器提供了两种不同的选项：scope 和 policy。

scope 定义了您希望执行资源对齐的粒度，例如，在 pod 或 container 级别。而 policy 定义了用于执行对齐的实际策略，例如 best-effort、restricted 和 single-numa-node。有关今天可用的各种 scopes 和 policies 的详细信息，请参见下文。

拓扑管理器范围

拓扑管理器可以处理不同范围内的资源对齐

• container (默认)
• pod

可以在 kubelet 启动时通过在 kubelet 配置文件 中设置 topologyManagerScope 来选择任何选项。

container 范围

默认使用 container 范围。您也可以在 kubelet 配置文件 中显式设置 topologyManagerScope 为 container。

在此范围内，拓扑管理器执行一系列资源对齐，即，对于每个容器（在 pod 中），计算单独的对齐。换句话说，对于此范围，没有将容器分组到特定 NUMA 节点的概念。实际上，拓扑管理器对单个容器到 NUMA 节点的对齐执行任意操作。

出于目的，将容器分组到以下范围，例如 pod 范围，并在以下范围内认可并实施了该概念。

pod 范围

要选择 pod 范围，请在 kubelet 配置文件 中将 topologyManagerScope 设置为 pod。

此范围允许将 pod 中的所有容器分组到一组通用的 NUMA 节点。也就是说，拓扑管理器将 pod 视为一个整体，并尝试将整个 pod（所有容器）分配到一个 NUMA 节点或一组通用的 NUMA 节点。以下示例说明了拓扑管理器在不同场合产生的对齐情况

• 所有容器都可以并且被分配到一个 NUMA 节点；
• 所有容器都可以并且被分配到一组共享的 NUMA 节点。

根据 有效请求/限制 公式计算整个 pod 所需的特定资源的总量，因此，此总值等于

• 所有 app 容器请求的总和，
• init 容器请求的最大值，

对于一种资源。

将 pod 范围与 single-numa-node 拓扑管理器策略结合使用，对于对延迟敏感的工作负载或执行 IPC 的高吞吐量应用程序特别有价值。通过结合这两个选项，您可以将 pod 中的所有容器放置在单个 NUMA 节点上；因此，可以消除该 pod 的 NUMA 节点间通信开销。

在 single-numa-node 策略的情况下，仅当在可能的分配中存在合适的 NUMA 节点集合时，才接受 pod。

• 仅包含单个 NUMA 节点的集合 - 它会导致 pod 被接受，
• 而包含更多 NUMA 节点的集合 - 它会导致 pod 被拒绝（因为需要两个或多个 NUMA 节点来满足分配，而不是一个 NUMA 节点）。

总而言之，拓扑管理器首先计算一组 NUMA 节点，然后根据拓扑管理器策略对其进行测试，从而导致 pod 被拒绝或接受。

拓扑管理器策略

拓扑管理器支持四种分配策略。您可以通过 kubelet 标志 --topology-manager-policy 设置策略。有四种受支持的策略

• none (默认)
• best-effort
• restricted
• single-numa-node

none 策略

这是默认策略，不执行任何拓扑对齐。

best-effort 策略

对于 Pod 中的每个容器，kubelet 在使用 best-effort 拓扑管理策略时，会调用每个 Hint Provider 来发现它们的资源可用性。使用此信息，拓扑管理器会存储该容器的首选 NUMA Node 亲和性。如果未偏好该亲和性，拓扑管理器将存储此信息并仍然允许该 pod 进入节点。

Hint Providers 随后可以使用此信息在做出资源分配决策时。

restricted 策略

对于 Pod 中的每个容器，kubelet 在使用 restricted 拓扑管理策略时，会调用每个 Hint Provider 来发现它们的资源可用性。使用此信息，拓扑管理器会存储该容器的首选 NUMA Node 亲和性。如果未偏好该亲和性，拓扑管理器将拒绝该 pod 进入节点。这将导致 pod 进入 Terminated 状态，并出现 pod 准入失败。

一旦 pod 进入 Terminated 状态，Kubernetes 调度器将 不 尝试重新调度该 pod。建议使用 ReplicaSet 或 Deployment 来触发 pod 的重新部署。也可以实现外部控制循环来触发具有 Topology Affinity 错误的 pod 的重新部署。

如果 pod 被准入，Hint Providers 随后可以使用此信息在做出资源分配决策时。

single-numa-node 策略

对于 Pod 中的每个容器，kubelet 在使用 single-numa-node 拓扑管理策略时，会调用每个 Hint Provider 来发现它们的资源可用性。使用此信息，拓扑管理器确定是否有可能进行单个 NUMA Node 亲和性。如果是，拓扑管理器将存储此信息，并且 Hint Providers 随后可以使用此信息在做出资源分配决策时。但是，如果这不可能，则拓扑管理器将拒绝该 pod 进入节点。这将导致 pod 进入 Terminated 状态，并出现 pod 准入失败。

一旦 pod 进入 Terminated 状态，Kubernetes 调度器将 不 尝试重新调度该 pod。建议使用带有副本的 Deployment 来触发 Pod 的重新部署。也可以实现外部控制循环来触发具有 Topology Affinity 错误的 pod 的重新部署。

拓扑管理器策略选项

支持拓扑管理器策略选项需要启用 TopologyManagerPolicyOptions feature gate（默认情况下已启用）。

您可以使用以下特性门控根据其成熟度级别切换启用或禁用选项组

• TopologyManagerPolicyBetaOptions 默认启用。启用以显示 beta 级别的选项。
• TopologyManagerPolicyAlphaOptions 默认禁用。启用以显示 alpha 级别的选项。

您仍然需要使用 Topology ManagerPolicyOptions kubelet 选项来启用每个选项。

prefer-closest-numa-nodes

prefer-closest-numa-nodes 选项自 Kubernetes 1.32 起为 GA。在 Kubernetes 1.35 中，只要启用了 TopologyManagerPolicyOptions feature gate，此策略选项默认可见。

默认情况下，拓扑管理器不知道 NUMA 距离，并且在做出 Pod 准入决策时不会考虑它们。这种限制出现在多插槽以及单插槽多 NUMA 系统中，如果拓扑管理器决定在不相邻的 NUMA 节点上对齐资源，可能会导致延迟敏感型执行和高吞吐量应用程序的性能显著下降。

如果您指定 prefer-closest-numa-nodes 策略选项，则 best-effort 和 restricted 策略在做出准入决策时会优先选择距离较短的 NUMA 节点集。

您可以通过将 prefer-closest-numa-nodes=true 添加到拓扑管理器策略选项来启用此选项。

默认情况下（未使用此选项），拓扑管理器将资源对齐到单个 NUMA 节点，或者在需要多个 NUMA 节点的情况下，使用最少的 NUMA 节点数。

max-allowable-numa-nodes

max-allowable-numa-nodes 选项自 Kubernetes 1.35 起为 GA。在 Kubernetes 1.35 中，只要启用了 TopologyManagerPolicyOptions feature gate，此策略选项默认可见。

准入 pod 的时间与物理机器上的 NUMA 节点数相关。默认情况下，Kubernetes 不会在检测到超过 8 个 NUMA 节点的任何 (Kubernetes) 节点上运行启用了拓扑管理器的 kubelet。

您可以通过将 max-allowable-numa-nodes=true 添加到拓扑管理器策略选项来启用此选项。

设置 max-allowable-numa-nodes 的值本身不会影响 pod 准入的延迟，但将 Pod 绑定到具有许多 NUMA 的 (Kubernetes) 节点会产生影响。Kubernetes 未来的潜在改进可能会提高 Pod 准入性能以及 NUMA 节点数增加时发生的延迟。

Pod 与拓扑管理器策略的交互

考虑以下 Pod 清单中的容器

spec:
  containers:
  - name: nginx
    image: nginx

由于未指定资源 requests 或 limits，此 pod 运行在 BestEffort QoS 类中。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

由于请求小于限制，此 pod 运行在 Burstable QoS 类中。

如果选择的策略不是 none，拓扑管理器将考虑这些 Pod 规范。拓扑管理器将咨询 Hint Providers 以获取拓扑提示。对于 static，CPU Manager 策略将返回默认拓扑提示，因为这些 Pod 未显式请求 CPU 资源。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

此 pod 具有整数 CPU 请求，运行在 Guaranteed QoS 类中，因为 requests 等于 limits。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"

此 pod 具有共享 CPU 请求，运行在 Guaranteed QoS 类中，因为 requests 等于 limits。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        example.com/deviceA: "1"
        example.com/deviceB: "1"
      requests:
        example.com/deviceA: "1"
        example.com/deviceB: "1"

由于没有 CPU 和内存请求，此 pod 运行在 BestEffort QoS 类中。

拓扑管理器将考虑上述 pod。拓扑管理器将咨询 Hint Providers，即 CPU 和 Device Manager，以获取 pod 的拓扑提示。

对于具有整数 CPU 请求的 Guaranteed pod，static CPU Manager 策略将返回与独占 CPU 相关的拓扑提示，Device Manager 将返回请求设备的提示。

对于具有共享 CPU 请求的 Guaranteed pod，static CPU Manager 策略将返回默认拓扑提示，因为没有独占 CPU 请求，Device Manager 将返回请求设备的提示。

在上述 Guaranteed pod 的两种情况下，none CPU Manager 策略将返回默认拓扑提示。

对于 BestEffort pod，static CPU Manager 策略将发送默认拓扑提示，因为没有 CPU 请求，Device Manager 将返回请求的每个设备的提示。

使用此信息，拓扑管理器计算 pod 的最佳提示并将此信息存储起来，Hint Providers 在进行资源分配时将使用此信息。

已知限制

1. 拓扑管理器允许的最大 NUMA 节点数为 8。超过 8 个 NUMA 节点，在尝试枚举可能的 NUMA 亲和性并生成其提示时，将出现状态爆炸。有关更多选项，请参阅 max-allowable-numa-nodes (beta)。

2. 调度器不了解拓扑，因此有可能在节点上被调度，然后由于拓扑管理器而在节点上失败。