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

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

为了获得最佳性能，需要与 CPU 隔离、内存和设备本地性相关的优化。然而，在 Kubernetes 中，这些优化由一组分离的组件处理。

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

开始之前

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

• Killercoda
• 玩转 Kubernetes

拓扑管理器的工作原理

在引入拓扑管理器之前，Kubernetes 中的 CPU 和设备管理器独立地进行资源分配决策。这会导致在多插槽系统上出现不希望的分配，性能/延迟敏感型应用程序会因这些不希望的分配而受到影响。不希望在这种情况下的含义是指例如 CPU 和设备从不同的 NUMA 节点分配，从而导致额外的延迟。

拓扑管理器是一个 Kubelet 组件，它充当事实来源，以便其他 Kubelet 组件可以做出与拓扑相关的资源分配选择。

拓扑管理器为组件提供了一个接口，称为提示提供程序，用于发送和接收拓扑信息。拓扑管理器有一组节点级策略，将在下面解释。

拓扑管理器从提示提供程序接收拓扑信息，该信息以位掩码的形式表示可用的 NUMA 节点，以及首选分配指示。拓扑管理器策略对提供的提示执行一组操作，并收敛到由策略确定的提示以提供最佳结果，如果存储了不希望的提示，则提示的首选字段将设置为 false。在当前策略中，首选是范围最窄的首选掩码。选定的提示将存储为拓扑管理器的一部分。根据配置的策略，pod 可以根据选定的提示被接受或拒绝加入节点。然后，该提示存储在拓扑管理器中，供提示提供程序在进行资源分配决策时使用。

拓扑管理器范围和策略

拓扑管理器目前

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

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

为了自定义这种对齐方式的执行方式，拓扑管理器提供了两个不同的旋钮：范围 和 策略。

范围 定义了您希望执行资源对齐的粒度（例如，在 pod 或 容器 级别）。而 策略 定义了用于执行对齐的实际策略（例如，尽力而为、受限、单 NUMA 节点 等）。有关当今可用的各种 范围 和 策略 的详细信息，请参见下文。

拓扑管理器范围

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

• 容器（默认）
• pod

可以在 Kubelet 启动时选择任何一个选项，方法是在 Kubelet 配置文件 中设置 topologyManagerScope。

容器 范围

容器 范围是默认使用的范围。您也可以在 Kubelet 配置文件 中将 topologyManagerScope 显式设置为 容器。

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

容器分组的概念在以下范围中得到认可和实施，例如 pod 范围。

pod 范围

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

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

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

整个 pod 的特定资源的总需求量是根据 有效请求/限制 公式计算的，因此，该总值等于以下两者的最大值

• 所有应用程序容器请求的总和，
• 初始化容器请求的最大值，

对于一个资源。

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

在 单 NUMA 节点 策略的情况下，只有在可能分配中存在合适的 NUMA 节点集时才会接受 pod。重新考虑上面的示例

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

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

拓扑管理器策略

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

• 无（默认）
• 尽力而为
• 受限
• 单 NUMA 节点

无 策略

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

尽力而为 策略

对于 Pod 中的每个容器，Kubelet 使用 尽力而为 拓扑管理策略调用每个提示提供程序以发现其资源可用性。使用此信息，拓扑管理器将存储该容器的首选 NUMA 节点亲和性。如果亲和性不受欢迎，拓扑管理器将存储它并仍然将 pod 接受到节点中。

然后，提示提供程序可以在进行资源分配决策时使用此信息。

受限 策略

对于 Pod 中的每个容器，Kubelet 使用 受限 拓扑管理策略调用每个提示提供程序以发现其资源可用性。使用此信息，拓扑管理器将存储该容器的首选 NUMA 节点亲和性。如果亲和性不受欢迎，拓扑管理器将拒绝该 pod 加入节点。这将导致 pod 处于 已终止 状态，并出现 pod 准入失败。

一旦 pod 处于 已终止 状态，Kubernetes 调度程序将 不 尝试重新调度 pod。建议使用 ReplicaSet 或 Deployment 触发 pod 的重新部署。还可以实施外部控制循环以触发已出现 拓扑亲和性 错误的 pod 的重新部署。

如果 pod 被接受，然后，提示提供程序可以在进行资源分配决策时使用此信息。

单 NUMA 节点 策略

对于 Pod 中的每个容器，Kubelet 使用 单 NUMA 节点 拓扑管理策略调用每个提示提供程序以发现其资源可用性。使用此信息，拓扑管理器确定是否可以进行单个 NUMA 节点亲和性。如果是，拓扑管理器将存储它，然后，提示提供程序可以在进行资源分配决策时使用此信息。但是，如果不可能，则拓扑管理器将拒绝 pod 加入节点。这将导致 pod 处于 已终止 状态，并出现 pod 准入失败。

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

拓扑管理器策略选项

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

您可以根据其成熟度级别，使用以下功能特性来启用或禁用选项组

• TopologyManagerPolicyBetaOptions 默认启用。启用以显示测试版级别的选项。
• TopologyManagerPolicyAlphaOptions 默认禁用。启用以显示 Alpha 级别的选项。

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

prefer-closest-numa-nodes（测试版）

prefer-closest-numa-nodes 选项自 Kubernetes 1.28 起为测试版。在 Kubernetes 1.31 中，此策略选项默认可见，前提是 TopologyManagerPolicyOptions 和 TopologyManagerPolicyBetaOptions 功能特性 已启用。

默认情况下，拓扑管理器不知道 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.31 起为测试版。在 Kubernetes 1.31 中，此策略选项默认可见，前提是 TopologyManagerPolicyOptions 和 TopologyManagerPolicyBetaOptions 功能特性 已启用。

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

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

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

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

考虑以下 Pod 清单中的容器

spec:
  containers:
  - name: nginx
    image: nginx

此 Pod 在 BestEffort QoS 类中运行，因为没有指定资源 requests 或 limits。

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

此 Pod 在 Burstable QoS 类中运行，因为请求小于限制。

如果选择的策略不是 none，则拓扑管理器将考虑这些 Pod 规范。拓扑管理器将咨询提示提供者以获取拓扑提示。在 static 的情况下，CPU 管理器策略将返回默认拓扑提示，因为这些 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"

此具有整数 CPU 请求的 Pod 在 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"

此具有共享 CPU 请求的 Pod 在 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"

此 Pod 在 BestEffort QoS 类中运行，因为没有 CPU 和内存请求。

拓扑管理器将考虑上述 Pod。拓扑管理器将咨询提示提供者（即 CPU 和设备管理器）以获取 Pod 的拓扑提示。

在具有整数 CPU 请求的 Guaranteed Pod 的情况下，static CPU 管理器策略将返回与独占 CPU 相关的拓扑提示，而设备管理器将返回所请求设备的提示。

在具有共享 CPU 请求的 Guaranteed Pod 的情况下，static CPU 管理器策略将返回默认拓扑提示，因为没有独占 CPU 请求，而设备管理器将返回所请求设备的提示。

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

在 BestEffort Pod 的情况下，static CPU 管理器策略将返回默认拓扑提示，因为没有 CPU 请求，而设备管理器将返回每个请求设备的提示。

使用这些信息，拓扑管理器计算 Pod 的最佳提示并将这些信息存储起来，提示提供者在进行资源分配时将使用这些信息。

已知限制

1. 拓扑管理器允许的 NUMA 节点数最大为 8。如果 NUMA 节点数超过 8 个，则在尝试枚举可能的 NUMA 关联并将它们的提示生成时，将出现状态爆炸。请参阅 max-allowable-numa-nodes（测试版）以获取更多选项。

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