拓扑感知调度在Kubernetes中的应用 第1部分：高层商业案例 - 掘金
如何充分利用裸金属硬件？信不信由你，计算机中的资源布局，从内存和CPU到存储和I/O，对性能有着巨大的影响。直到最近，Kubernetes用户无法直接影响硬件和软件之间的这种关键交互，通常被称为资源拓扑。
本博客系列将描述拓扑感知调度，这是Kubernetes于2021年推出的一项功能。拓扑感知调度使得Kubernetes控制平面在将Pod放置在节点上时，能够遵守资源拓扑约束。这种方法与拓扑管理器相辅相成，拓扑管理器最初在Kubernetes 1.17中引入，它是kubelet中的节点级资源拓扑执行器，但这些将在后面详细介绍。
资源拓扑为何重要？
非一致性内存访问（NUMA）是一种计算平台架构，允许不同的CPU以不同的速度访问不同的内存区域。当我们提到资源拓扑时，我们指的是CPU、内存和PCI设备的相对位置。
这种架构具有重要的优势。任何CPU核心都可以潜在地访问系统上的所有内存，但在性能方面存在一些潜在的问题。例如，在下面的图表中，靠近CPU核心1的内存对CPU核心1的访问速度比靠近CPU核心7的内存更快。
FIGURE 1: A Non-uniform Memory Access (NUMA) system
到目前为止，这还是相对简单的，即使在Kubernetes集群中，底层操作系统也会管理大部分情况。然而，当您想从裸金属中获得低延迟性能时，您需要将独立的资源专门分配给特定的应用程序。随着我们添加新类型的资源，情况变得越来越复杂。
对于受I/O限制的工作负载，远程NUMA区域上的网络接口会降低信息到达应用程序的速度。高性能工作负载（如运行5G网络的工作负载）在这些条件下无法按规格运行。
以请求2个CPU和一个PCI设备的Pod为例，图2展示了资源不对齐的情况，而图3展示了资源对齐的情况：
FIGURE 2: A NUMA System with no Resource Alignment
FIGURE 3: A NUMA System with Resource Alignment
在不处理资源拓扑的情况下，Kubernetes在1.20版本中无法满足这类应用程序的需求。终端用户可以通过为集群添加约束来绕过这个问题。其中一种选择是将裸金属部署替换为虚拟机，另一种选择是限制开发人员可用的Pod配置。
Kubernetes的默认调度器在将Pod分配给节点时是否考虑资源拓扑？
Kubernetes拓扑管理器允许工作负载在针对低延迟进行优化的环境中运行。性能关键的工作负载需要拓扑信息，以便在电信、高性能计算（HPC）和物联网（IoT）等行业中使用共同位置的CPU核心和设备。然而，当前的原生调度器在选择节点时不会基于其拓扑信息进行选择。这是因为调度器缺乏对资源拓扑的了解，这可能导致应用程序性能的不可预测性。一般来说，这意味着性能不佳，而在最糟糕的情况下，资源请求和kubelet策略完全不匹配，例如调度注定失败的Pod，潜在地进入故障循环。
将集群级别的拓扑暴露给调度器使其能够做出智能的NUMA感知放置决策，从而优化整个集群中工作负载的性能。
在Kubernetes中启用拓扑感知调度的商业案例是什么？
在Kubernetes中启用拓扑感知调度的商业案例是什么？ 一家公司可以通过提供公共云服务或向第三方销售云解决方案（例如，面向NFV用例的电信运营商和其他公司）来开展业务。在公共云的情况下，云提供商可以在最终用户协议或公共报价中仅提供具有固定资源数量的套餐。在这种情况下，资源对齐的问题由基础设施即服务（IAAS）级别和我们在套餐中找到的资源数量（例如网卡、GPU）来解决，而这些数量与每个NUMA节点上的数量对齐。
另一种情况是当一家公司销售云解决方案，客户要求更高的灵活性。对于他们来说，灵活性意味着能够在裸金属上工作并能够请求任意数量和类型的资源。因此，使kube调度器具备拓扑感知能力的解决方案对于那些向第三方销售云解决方案的公司来说非常有吸引力。
在博客文章的下一部分中，我们将讨论拓扑管理器，并更详细地解释拓扑感知调度的设计。
