在节点级别，资源对齐由 Kubelet 的Topology Manager 处理。默认情况下，Kubelet 不会尝试应用任何特定的约束，但可以设置拓扑管理器策略来强制执行资源对齐。
Topology Manager是Kubernetes资源拓扑管理系统的核心部分。它确保 Pod 在进入运行时时获得正确对齐的资源。然而，Kubelet 必然无法了解集群的所有信息。knowledge gap可能导致失败，从意外低性能到完全停止应用程序的情况。
一旦 pod 登陆节点，该系统就会运行良好。Kubelet 可以考虑可用资源并确保 pod 获得最佳对齐。然而，Kubelet 不能做的是告诉我们集群中的其他地方是否有更好的资源对齐可用。这是调度程序的工作。
协同工作：拓扑管理器和拓扑感知调度。
当工作负载请求与计算节点上设置的策略完全不匹配时，当今资源拓扑的最坏情况就会出现。如果 Kubelet 试图对资源拓扑实施“单 numa-node”策略，这种不匹配会导致 pod 失败。这在集群中显示为拓扑亲和性错误。
假设一个繁重的工作负载 ( Pod 1 ) 在其 Pod 规范中请求 20 个专用 CPU 和两个工作节点，节点 A总共有 20 个内核，每个 NUMA 区域 10 个，节点 B总共有 40 个内核，每个 NUMA 区域 20 个。节点 A 和节点 B 都在运行 single-numa-zone 策略。
图 1：机器布局图
从上图可能很清楚，只有Node B可以满足Pod Spec 1的资源需求，但是从调度器读取Kubernetes API的角度来看，一点也不清楚。这是它看到的：
图 2：Kube-Scheduler 视图图
启用拓扑管理器后，调度程序将节点 A 和节点 B 视为运行 Pod 1 的合适平台。但是，当将 Pod 1 部署到节点 A 时，我们会收到“拓扑关联错误”。这会阻止工作负载运行，并可能在集群中产生连锁反应。有关此问题的更多讨论，请参阅scheduler being topology-unaware can cause runaway pod creation。
如果我们启用 Topology Aware Scheduling，调度程序将开始看到构成简化节点级资源视图基础的资源拓扑复杂性。在调度器中启用 Topology Awareness 后，它会看到：
图 3：具有拓扑感知调度的调度程序视图图
上面的视图意味着调度程序不会将 Pod 1 部署到节点 A，从而避免拓扑亲和性错误。随着更多不同的资源请求被添加到 Pod 规范中以及更多异构类型的机器被添加到集群中，上述文章中描述的情况变得越来越可能。
有关 Topology Manager 的更多信息，请参阅Kubernetes Topology Manager Moves to Beta - Align Up！
这对 Kubernetes 有什么好处？
拓扑感知调度旨在支持新型工作负载在裸机 Kubernetes 集群上运行。
该设计主要关注在 Kubernetes 集群中提供一致的、可预测的资源对齐决策。有了它，已启用的工作负载永远不应放置在无法满足与其拓扑偏好一致的资源需求的平台上。
高性能和低延迟计算依赖于几乎绝对的资源保证来实现可预测的性能。这些工作负载经过调整以确保可以从平台中获得绝对最大性能，同时在工作负载的生命周期内将中断量降至最低。
在今天的 Kubernetes 中，基于 NUMA 的服务器需要大量的变通方法才能提供这种性能。要么是 Kubernetes 之外的东西实现了约束——比如拥有虚拟化节点——要么是节点和 Pod 配置的灵活性降低了。
数据包处理工作负载，如 5G 核心和边缘网络中的工作负载以及机器学习工作负载，是资源拓扑对齐的首要目标。但是有很多工作负载可能会受益于系统能够提供的那种保证。
这一切将如何运作？
我们将在本系列的后面深入探讨真正推动拓扑感知调度的因素。从较高的层次来看，解决方案由三个组成部分组成：
图 4：拓扑感知调度的系统级图（单击图片查看全尺寸）
-
Kubelet负责通过 PodResource API 提供现有资源拓扑的信息。作为拓扑感知调度工作的一部分，此 API 正在得到增强。
-
Node Feature Discovery将从 Kubelet 端点读取并通过与集群中节点对应的自定义资源 (CR) 提供资源拓扑信息。
3）Kubernetes Scheduler读取Node Featured Discovery导出的信息，阻塞调度到不能满足特定工作负载需求的节点。
Topology Aware Scheduling 集成了现有的 Kubernetes 组件，包括社区赞助的 Node Feature Discovery，为集群级拓扑管理提供了一个嵌入式解决方案：
图 5：拓扑感知调度的时序图（单击图片查看全尺寸）
这些组件通过 Kubernetes API 相互通信。
查看本系列中的更多文章，这些文章将跟踪从节点一直到调度程序的资源拓扑管理。
