CN116820687B - 基于kubelet的NUMA架构资源分配方法及系统 - Google Patents

Abstract

本发明公开了一种基于kubelet的NUMA架构资源分配方法及系统，方法包括：获取用户创建的应用Pod，若为目标类型且包含预设标记，执行下一步；根据Pod的资源请求量以及各NUMA node剩余可用资源，计算得到不同组件对应的NUMA node组合；将各组件的NUMA node组合进行全排列后进行合并，根据NUMA node之间的距离，从合并后的NUMA node组合中获取最佳的NUMA node组合，将最佳的NUMA node组合中的资源分配给Pod。本发明能够显著减少在多NUMA node场景下的工作节点创建Pod的时间，并且能够节约NUMA资源，避免造成不必要的资源浪费。

Description

基于kubelet的NUMA架构资源分配方法及系统

技术领域

本发明涉及计算机领域，尤其涉及一种基于kubelet的NUMA架构资源分配方法及系统。

背景技术

现代计算机的CPU架构多采用NUMA（Non-UniformMemoryAccess，非统一内存访问）架构。NUMA就是将cpu资源分开，以node（节点）为单位进行分组，每个node都有着独有的cpu、memory等资源，当一个NUMA node内的资源相交互时，性能将会有很大的提升，多个NUMA node之间的资源交互性能会相比一个NUMA node内的资源交互差一些。

目前，越来越多的应用（包括电信、科学计算、机器学习、金融服务和数据分析等领域的工作负载）是访存密集型和高吞吐量并行计算应用。要使这些应用获得最佳性能，需将应用需要的CPU、内存分配在同一个NUMA node（NUMA节点）中。为了满足这种情况，K8s集群的kubelet统筹cpuManager（cpu管理器）、memoryManager（内存管理器）和deviceManager（设备管理器）这几种不相交的组件，提供一种topologymanager（拓扑管理器）机制来协调不同组件的细粒度硬件资源分配，以避免出现跨NUMA node的资源组合。

目前topologymanager协调不同组件的硬件资源分配逻辑如图1所示，包括以下步骤：

第一步分别针对不同组件求出各自的NUMA node组合，使用TopologyHint来存储。如图2所示，比如Pod需要6个cpu，服务器有4个NUMA node 且每个NUMA node 有4个cpu，那么任意两个NUMA node 组合都可以满足Pod的要求，得到cpu组件的NUMA组合是cpu:[{0011true} {0101 true} {1001 true} {0110 true} {1010 true} {1100 true} {0111false} {1011 false} {1101 false} {1110 false} {1111 false}]。其中0011这种位掩码表示4个NUMA node 取NUMA0和NUMA1 （从右到左，第0位为1就表示组合包含NUMA0，以此类推），true表示该NUMA组合是最佳组合，false则不是最佳组合。memory也可以得到同样的NUMA组合；

第二步使用二维数组存储cpu和memory的NUMA node组合；

第三步分别求出cpu和memory的NUMA node组合中最小NUMA node个数值，然后取这两个值中的最大值；

第四步对cpu和memory的NUMA node组合作全排列；

第五步对每一种排列组合进行合并操作；

第六步对合并后的组合求出一组最佳的NUMA node组合作为最终的资源组合分配给Pod。

上述步骤的NUMA感知资源分配逻辑有如下缺点：

缺点1. 第一步得到各组件的NUMA node组合，是使用数学中的组合概率求出结果：共m个NUMA node，需要n个满足要求，那么求NUMA node组合数公式为：，当m值很大且n值很小时，得到的组合数会非常大。

第四步求全排列时，cpu有x个组合，memory有y个组合，全排列后组合数为：。假设第一步中求cpu和memory的NUMA node组合中m值为16、n值为1那么组合数分别有65535种，第四步全排列后的值为4294836225。对40多亿种组合进行第五步和第六步的运算，运算量非常大，显著增加kubelet创建Pod的时间；

缺点2. 第六步求最佳的NUMA node组合时没有考虑NUMA node之间的距离，假设如下两种组合对比{0011 true} {0101 true}，目前的方案会比较0011和0101十进制值的大小（0011为3，0101为5）因此会选择{0011 true}组合。但是假如0011 组合的NUMA node距离比0101组合的NUMA node距离大，显然{0101 true}才是最佳组合；

缺点3.K8s为了保证集群中Pod 的服务质量（QoS），对运行的 Pod 进行分类，并将每个 Pod 分配到特定的QoS类，可选的 QoS 类有Guaranteed、Burstable和BestEffort。当一个工作节点耗尽资源时，Kubernetes 将首先驱逐该工作节点上运行的BestEffortPod，然后是BurstablePod，最后是GuaranteedPod。而topologymanager机制是否给Pod使用NUMA感知是根据Pod是否为Guaranteed类型的Pod来决定的。假设用户创建的Pod并不是访存密集型应用，但是为了保证服务质量将Pod配置为Guaranteed类型，那么该Pod就会占用NUMA资源而造成NUMA资源的浪费，甚至出现访存密集型应用没有NUMA资源可用的情况。

发明内容

本发明要解决的技术问题就在于：针对现有技术存在的技术问题，本发明提供一种基于kubelet的NUMA架构资源分配方法及系统，能够显著减少在多NUMA node场景下的工作节点创建Pod的时间，并且能够节约NUMA资源，避免造成不必要的资源浪费。

为解决上述技术问题，本发明提出的技术方案为：

一种基于kubelet的NUMA架构资源分配方法，包括以下步骤：

获取用户创建的应用Pod，若所述Pod为目标类型，且所述Pod包含预设标记，执行下一步；

根据所述Pod的资源请求量以及各NUMA node 剩余可用资源，计算得到不同组件对应的NUMA node组合；

将各组件的NUMA node 组合进行全排列后进行合并，根据NUMA node之间的距离，从合并后的NUMA node 组合中获取最佳的NUMA node组合，将最佳的NUMA node组合中的资源分配给所述Pod。

进一步的，所述目标类型为Guaranteed，所述预设标记为"numa-aware": true的注解Annotations，获取用户创建的应用Pod之后还包括：若所述Pod不为Guaranteed类型，或者所述Pod不包含"numa-aware": true的注解Annotations，按照操作系统默认的方式为所述Pod分配资源。

进一步的，根据所述Pod的资源请求量以及各NUMA node 剩余可用资源，计算得到不同组件对应的NUMA node组合时，具体包括以下步骤：

获取所述Pod中目标组件的资源请求量，将NUMA node 按照其剩余可分配资源量，以指定的顺序进行排序；

使用滑动窗口算法，根据NUMA node 剩余可分配资源量计算得到满足要求的最小NUMA node个数；

根据满足要求的最小NUMA node个数n和所有NUMA node的数量m，计算从所有NUMAnode中选择满足要求的NUMA node的组合数，将/>个NUMA node组合作为目标组件的NUMA node 组合。

进一步的，所述滑动窗口算法具体包括：

使用指定的窗口宽度，从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，若存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则停止滑动，并将指定的窗口宽度为满足要求的最小NUMA node个数；

若不存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则增大窗口宽度，并再次从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，直到存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，或者窗口宽度达到预设阈值。

进一步的，所述滑动窗口算法还包括：若窗口宽度达到预设阈值，将所述阈值作为满足要求的最小NUMA node个数的值。

进一步的，将各组件的NUMA node 组合进行全排列后进行合并时，包括：将全排列的NUMA node 组合中一对NUMA node 组合合并时，将这一对NUMA node 组合的位掩码的与运算结果作为合并后对应NUMA node 组合的位掩码，若这一对NUMA node 组合的位掩码相等，则设置合并后对应NUMA node 组合的组合标记为true，若这一对NUMA node 组合的位掩码不相等，则设置合并后对应NUMA node 组合的组合标记为false。

进一步的，根据NUMA node之间的距离，从合并后的NUMA node 组合中获取最佳的NUMA node组合时，具体包括：

获取各NUMA node之间的距离并存储；

在合并后的NUMA node 组合中选取两个NUMA node 组合，将两个NUMA node 组合进行对比得到较佳NUMA node 组合，较佳的NUMA node组合为两个组合标记不同的NUMAnode 组合中组合标记为true的NUMA node 组合，或者为两个组合标记均为true的NUMAnode 组合中NUMA node距离最短的NUMA node 组合；

然后依次将合并后的NUMA node 组合中每个剩余NUMA node 组合与前一较佳NUMA node 组合进行对比得到新的较佳NUMA node 组合，将最后得到的较佳NUMA node 组合作为最佳的NUMA node组合。

进一步的，所述较佳的NUMA node组合为两个组合标记均为false的NUMA node组合中NUMA node个数值等于基准值的NUMA node 组合，或者为两个组合标记为false且NUMAnode个数值等于基准值的NUMA node 组合中NUMA node距离最短的NUMA node 组合；

将各组件的NUMA node 组合进行全排列后进行合并之前，还包括：从各组件的NUMA node 组合中分别选取各组件的最小NUMA node个数值，然后从各组件的最小NUMAnode个数值中选取最大值作为基准值。

进一步的，将最佳的NUMA node组合中的资源分配给所述Pod时，具体包括：调用CRI接口，将最佳的NUMA node组合中的NUMA资源分配给Pod对应的容器。

本发明还提出一种基于kubelet的NUMA架构资源分配系统，包括：

用户端，用于创建应用Pod，并按需给所述Pod添加用于表示应用是访存密集型应用的标记；

k8s集群，用于将Pod应用调度到工作节点；

工作节点，用于执行任一所述的基于kubelet的NUMA架构资源分配方法。

与现有技术相比，本发明的优点在于：

1，本发明在计算最佳NUMA node 组合中，第一步求各组件NUMA node 组合时，根据Pod的资源请求量以及各NUMA node 剩余可用资源求出NUMA node 组合数，减少了计算结果的数量，同时也间接减少了第四步的全排列组合数。这样可以显著减少运算量，加快Pod的创建时间。

2，本发明在求最佳NUMA node 组合时考虑NUMA node 之间的距离，使选出的最佳NUMA node 组合一定是访问延迟最小的组合。

3，本发明在创建Pod时，给Pod增加一个预设的标记，来区分用户创建的Pod是否使用kubelet NUMA感知功能。这样可以节约NUMA资源，避免造成不必要的资源浪费。

附图说明

图1为现有技术生成最佳NUMA node组合的流程图。

图2为现有技术生成最佳NUMA node组合的原理图。

图3为本发明实施例中生成最佳NUMA node组合的流程图。

图4为本发明实施例中生成最佳NUMA node组合的原理图。

图5为本发明实施例中滑动窗口算法的原理图。

图6为本发明实施例中系统的工作流程示意图。

具体实施方式

以下结合说明书附图和具体优选的实施例对本发明作进一步描述，但并不因此而限制本发明的保护范围。

在介绍本实施例的具体方案之前，先对于相关概念进行说明。

Kubernetes：简称k8s，是一个开源的容器编排管理工具。

NUMA：非统一内存访问架构（non-uniform memory access，简称NUMA）是一种为多处理器计算机设计的内存架构，内存访问时间取决于内存相对于处理器的位置。在NUMA下，处理器访问自己本地内存的速度比非本地内存（内存位于另一个处理器，或者是处理器之间共享的内存）快。

Kubelet ：是 kubernetes 工作节点上的一个代理组件，运行在每个工作节点上，主要工作是创建和删除Pod。

Pod：在Kubernetes中最小的管理元素不是一个个独立的容器，而是Pod，Pod是一组容器的集合。

topologyManager：是kubelet的一个子组件，提供给kubelet做出与拓扑结构相对应的资源分配决定。

cpuManager：是kubelet的一个子组件，用来管理Pod需要的cpu资源。

memoryManager：是kubelet的一个子组件，用来管理Pod需要的memory资源。

deviceManager：是kubelet的一个子组件，用来管理Pod需要的device资源。

QoS类：又称为服务质量 (QoS) 类，基于 Pod 中容器的资源请求进行分类，Kubernetes 使用这种分类来影响不同 Pod 被处理的方式。

CRI：容器运行时接口（Container Runtime Interface，简称CRI）是一个插件接口，它使 kubelet 能够使用各种容器运行时，如 Docker 、Containerd等。

实施例一

如图2所示，目前对于NUMA架构的资源分配逻辑在得到各组件的NUMA node组合，是使用数学中的组合概率求出结果：共n个NUMA node，需要m个满足要求，那么求NUMA node组合数的公式为：，当m值很大且n值很小时，得到的组合数会非常大，比如m为16、n为1时组合数有65535种。导致对各组件作全排列得到的结果为4294836225，这样会加大运算时间，使kubelet创建Pod的时间变得非常久。

为了避免这种高复杂度出现，现有的技术方案一般采用限制NUMA node数量的方式，导致对于具有更多NUMA node的服务器，无法充分发挥出硬件的性能，并且该方案也不支持具有16个NUMA node的国产飞腾架构的服务器。

因此，我们提出一种基于kubelet的NUMA架构资源分配方法，考虑在求取NUMA组合数时能显著减少复杂度，放开NUMA node 数量的限制，能够支持国产飞腾服务器。同时求出最佳NUMA组合时考虑各NUMA node 之间的距离，使选出的最终NUMA node 组合一定是访问延迟最小的组合。

为了达到上述效果，我们考虑从以下几个方面着手，对现有的资源分配逻辑进行改进：

首先，我们考虑在求各组件NUMA node组合时，根据Pod的资源请求量以及各NUMAnode剩余可用资源求出NUMA node组合数，例如Pod需要6个cpu，服务器有16个NUMA node且每个NUMA node有4个cpu可分配，那么组合数为=120种，而不是原方案的=65519种，同时也间接减少了后续步骤中全排列组合数。这样可以显著减少运算量，加快Pod的创建时间。

其次，我们在求最佳NUMA node 组合时，考虑NUMA node 之间的距离，使选出的最佳NUMA node 组合一定是访问延迟最小的组合。

最后，我们考虑在创建Pod时，给Pod增加一个自定义的标记，该标记为"numa-aware": true的注解Annotations，来区分用户创建的Pod是否使用kubelet NUMA感知功能。一个Pod需要既是Guaranteed 类型，同时加上"numa-aware": true的注解Annotations，才会被认定为NUMA感知的。这样可以节约NUMA资源，避免造成不必要的资源浪费。

如图3所示，本实施例中的基于kubelet的NUMA架构资源分配方法包括以下步骤：

S1）获取用户创建的应用Pod，若所述Pod为目标类型，且所述Pod包含预设标记，执行步骤S2；

S2）根据所述Pod的资源请求量以及各NUMA node 剩余可用资源，计算得到不同组件对应的NUMA node组合；

S3）使用多维数组存储各组件的NUMA node 组合；

S4）求出各组件NUMA node 组合中最小NUMA node 个数值，接着取各组件最小个数值中的最大值；

S5）将各组件的NUMA node 组合进行全排列；

S6）对全排列后的NUMA node 组合进行合并；

S7）根据NUMA node之间的距离，从合并后的NUMA node 组合中获取最佳的NUMAnode组合，将最佳的NUMA node组合中的资源分配给所述Pod。

在上述步骤中，通过步骤S1，可以区分用户创建的Pod是否使用kubelet NUMA感知功能，通过步骤S2，根据Pod的资源请求量以及各NUMA node剩余可用资源来求出NUMA node组合数，减少了运算量，通过步骤S7，求最佳的NUMA node组合时考虑NUMA node之间的距离，使选出的NUMA node组合一定是访问延迟最小的组合。

下面对于每个步骤分别进行具体说明。

本实施例的步骤S1中，根据前文所述，所述目标类型为Guaranteed，所述预设标记为"numa-aware": true的注解Annotations，若所述Pod不为Guaranteed类型，或者所述Pod不包含"numa-aware": true的注解Annotations时，按照操作系统默认的方式为所述Pod分配资源并退出资源分配的流程。

步骤S1包括以下步骤：

S11）用户编写应用Pod的yaml/json格式的配置文件或者使用麒麟容器云平台创建Pod，创建Pod时，用户知晓用户访存密集型应用的Pod才需要NUMA感知，给Pod添加"numa-aware": true的注解Annotations；

S12）Pod调度到工作节点后，工作节点的kubelet组件创建Pod时，判断相关信息中存在"numa-aware": true的注解Annotations，于是执行后续步骤，使用NUMA感知功能给Pod分配资源。

本实施例中，步骤S2具体包括以下步骤：

S21）获取所述Pod中目标组件的资源请求量，将NUMA node 按照其剩余可分配资源量，以指定的顺序进行排序，例如按照从小到大的顺序进行排序；

S22）使用滑动窗口算法，根据NUMA node 剩余可分配资源量计算得到满足要求的最小NUMA node个数；

本实施例中滑动窗口算法原理如下：

使用指定的窗口宽度，从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，若存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则停止滑动，并将指定的窗口宽度为满足要求的最小NUMA node个数；

若不存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则增大窗口宽度，并再次从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，直到存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，或者窗口宽度达到预设阈值；

若窗口宽度达到预设阈值，将所述阈值作为满足要求的最小NUMA node个数的值。

如图5所示，当小于3个窗口即3个以内NUMA node 能满足Pod资源请求量时，NUMAnode 个数直接取值窗口宽度的值。本实施例中，窗口宽度的阈值为3，当窗口宽度超过3即3个以上NUMA node 中的剩余可分配资源量才能满足Pod资源请求量时，将满足要求的最小NUMA node个数直接取值为3，因为超过3个NUMA node的情况下，此时NUMA node 的跨度很大，应用的访问延迟已经得不到保证，需要按照操作系统默认的方式分配资源。

S23）根据满足要求的最小NUMA node个数n和所有NUMA node的数量m，计算从所有NUMA node中选择满足要求的NUMA node的组合数，将/>个NUMA node组合作为目标组件的NUMA node 组合；

S24）针对其他的组件，重复步骤S21至步骤S23，得到每个组件的NUMA node 组合。

本实施例的步骤S3中，多维数组的维数与组件的数量一一对应，假设只有CPU和Memory资源，那就使用二维数组存储这两种组件资源的NUMA node 组合；

本实施例的步骤S4中，从各组件的NUMA node 组合中分别选取各组件的最小NUMAnode个数值，然后从各组件的最小NUMA node个数值中选取最大值作为基准值，选取最大值作为基准值是为了避免如下的情况：

如图4所示，在4个NUMA node中，CPU需要其中2个NUMA node的剩余可用资源才能满足资源请求量的需求，于是CPU的NUMA node组合为cpu:[{0011 true} {0101 true}{1001 true} {0110 true} {1010 true} {1100 true}]；Memory需要其中1个NUMA node便能满足，于是Memory的NUMA node组合为memory:[{0001 true} {0010 true} {0100 true}{1000 true}]。此时直接按照位掩码的十进制数的最小值选出来的最佳组合为{0001true}，显然该组合不满足CPU资源的需求，若求出各组件最小NUMA node个数值的最大值，那么选出来的最佳组合为{0011 true}，该组合能够满足两种资源的需求。

本实施例的步骤S5中，将多维数组存储的NUMA组合作全排列，全排列是一种常规的计算方法，在此不做赘述，仅通过以下举例进行说明：

例如，假设步骤S3中多维数组为[ [{01 true} {10 true}][{01 true} {10true}]]，全排列后结果为：[ [{01 true} {01 true}][{01 true} {10 true}][{10 true}{01 true}][{10 true} {10 true}] ]。

本实施例的步骤S6中，合并操作遵循如下原则：位掩码之间使用与运算进行合并；两个位掩码必须相等才为true，不等即为false。具体的，将全排列的NUMA node 组合中一对NUMA node 组合合并时，将这一对NUMA node 组合的位掩码的与运算结果作为合并后对应NUMA node 组合的位掩码，若这一对NUMA node 组合的位掩码相等，则设置合并后对应NUMA node 组合的组合标记为true，若这一对NUMA node 组合的位掩码不相等，则设置合并后对应NUMA node 组合的组合标记为false。

例如，[{0011 true} {0011 true}]这一对NUMA node 组合合并后得到的NUMAnode 组合为{0011 true}，[{0011 true} {0101 true}]这一对NUMA node 组合合并后得到的NUMA node 组合为{0001 false}。

本实施例的步骤S7具体包括以下步骤：

S71）获取各NUMA node之间的距离并存储；

S72）在步骤S6中合并后的NUMA node 组合中选取两个NUMA node 组合，将两个NUMA node 组合进行对比得到较佳NUMA node 组合，较佳的NUMA node组合为两个组合标记不同的NUMA node 组合中组合标记为true的NUMA node 组合，或者为两个组合标记均为true的NUMA node 组合中NUMA node距离最短的NUMA node 组合，或者为两个组合标记均为false的NUMA node组合中NUMA node个数值等于基准值的NUMA node 组合，或者为两个组合标记为false且NUMA node个数值等于基准值的NUMA node 组合中NUMA node距离最短的NUMA node 组合；

然后依次将合并后的NUMA node 组合中每个剩余NUMA node 组合与前一较佳NUMA node 组合进行对比得到新的较佳NUMA node 组合，将最后得到的较佳NUMA node 组合作为最佳的NUMA node组合。

本实施例中，两个NUMA node 组合的对比规则为：

若两个NUMA node 组合的组合标记不同，选取组合标记均为true的NUMA node 组合作为较佳的NUMA node组合；

若两个NUMA node 组合的组合标记均为true，选取NUMA node距离最短的NUMAnode 组合作为较佳的NUMA node组合；

若两个NUMA node 组合的组合标记均为false，选取NUMA node个数值等于基准值的NUMA node 组合作为较佳的NUMA node组合

若两个NUMA node 组合的组合标记均为false，且NUMA node个数值均等于基准值，选取NUMA node距离最短的NUMA node 组合作为较佳的NUMA node组合。

S73）得到最佳的NUMA node组合后，将最佳的NUMA node组合中的资源分配给所述Pod，具体包括：kubelet调用CRI（容器运行时）接口，将最佳的NUMA node组合中的NUMA资源分配给Pod对应的容器。

实施例二

本实施例基于实施例一提出一种基于kubelet的NUMA架构资源分配系统，包括：

用户端，用于创建应用Pod，并按需给所述Pod添加用于表示应用是访存密集型应用的标记；

k8s集群，用于将Pod应用调度到工作节点；

工作节点，用于执行任一所述的基于kubelet的NUMA架构资源分配方法。

如图6所示，本实施例的系统工作流程如下：

步骤101：用户通过用户端创建应用Pod，并给Pod添加"numa-aware": true的注解Annotations，表示应用是访存密集型应用；

步骤102：k8s集群将Pod应用调度到工作节点；

步骤103：工作节点的kubelet创建Pod，并使用NUMA感知功能，执行实施例一的方法，给应用计算出一个最佳NUMA组合，然后调用CRI（容器运行时）接口将最佳NUMA组合资源分配给应用。

综上所述，本发明提出了面向NUMA架构的资源分配优化过程中，求NUMA组合数时能显著减少复杂度，放开NUMA node 数量的限制，能够支持国产飞腾服务器。同时求出最佳NUMA组合时考虑各NUMA node 之间的距离，使选出的最终NUMA node 组合一定是访问延迟最小的组合。和现有技术相比，本发明的优势在于：

（1）不会对服务器NUMA node个数有限制，支持国产飞腾架构服务器；

（2）显著减少在多NUMA node场景下的工作节点创建Pod的时间；

（3）区分用户创建的Pod是否使用NUMA感知功能，节约NUMA资源，避免造成不必要的资源浪费。

上述只是本发明的较佳实施例，并非对本发明作任何形式上的限制。虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明。因此，凡是未脱离本发明技术方案的内容，依据本发明技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均应落在本发明技术方案保护的范围内。

Claims (8)

1.一种基于kubelet的NUMA架构资源分配方法，其特征在于，包括以下步骤：

获取用户创建的应用Pod，若所述Pod为目标类型，且所述Pod包含预设标记，执行下一步；

根据所述Pod的资源请求量以及各NUMA node 剩余可用资源，计算得到不同组件对应的NUMA node组合，包括以下步骤：

获取所述Pod中目标组件的资源请求量，将NUMA node 按照其剩余可分配资源量，以指定的顺序进行排序；

使用滑动窗口算法，根据NUMA node 剩余可分配资源量计算得到满足要求的最小NUMAnode个数；

根据满足要求的最小NUMA node个数n和所有NUMA node的数量m，计算从所有NUMAnode中选择满足要求的NUMA node的组合数，将/>个NUMA node组合作为目标组件的NUMA node 组合；

将各组件的NUMA node 组合进行全排列后进行合并；

根据NUMA node之间的距离，从合并后的NUMA node 组合中获取最佳的NUMA node组合，具体包括：

获取各NUMA node之间的距离；

在合并后的NUMA node 组合中选取两个NUMA node 组合，将两个NUMA node 组合进行对比得到较佳NUMA node 组合，较佳的NUMA node组合为两个组合标记不同的NUMA node组合中组合标记为true的NUMA node 组合，或者为两个组合标记均为true的NUMA node 组合中NUMA node距离最短的NUMA node 组合；

然后依次将合并后的NUMA node 组合中每个剩余NUMA node 组合与前一较佳NUMAnode 组合进行对比得到新的较佳NUMA node 组合，将最后得到的较佳NUMA node 组合作为最佳的NUMA node组合；

将最佳的NUMA node组合中的资源分配给所述Pod。

2. 根据权利要求1所述的基于kubelet的NUMA架构资源分配方法，其特征在于，所述目标类型为Guaranteed，所述预设标记为"numa-aware": true的注解，获取用户创建的应用Pod之后还包括：若所述Pod不为Guaranteed类型，或者所述Pod不包含"numa-aware": true的注解，按照操作系统默认的方式为所述Pod分配资源。

3.根据权利要求1所述的基于kubelet的NUMA架构资源分配方法，其特征在于，所述滑动窗口算法具体包括：

使用指定的窗口宽度，从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，若存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则停止滑动，并将指定的窗口宽度为满足要求的最小NUMA node个数；

若不存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，则增大窗口宽度，并再次从排好序的NUMA node序列的起始位置向终点位置滑动，并计算窗口内的NUMA node的剩余可分配资源量，直到存在NUMA node的剩余可分配资源量大于或等于目标组件的资源请求量的位置，或者窗口宽度达到预设阈值。

4. 根据权利要求3所述的基于kubelet的NUMA架构资源分配方法，其特征在于，所述滑动窗口算法还包括：若窗口宽度达到预设阈值，将所述阈值作为满足要求的最小NUMA node个数的值。

5. 根据权利要求1所述的基于kubelet的NUMA架构资源分配方法，其特征在于，将各组件的NUMA node 组合进行全排列后进行合并时，包括：将全排列的NUMA node 组合中一对NUMA node 组合合并时，将这一对NUMA node 组合的位掩码的与运算结果作为合并后对应NUMA node 组合的位掩码，若这一对NUMA node 组合的位掩码相等，则设置合并后对应NUMA node 组合的组合标记为true，若这一对NUMA node 组合的位掩码不相等，则设置合并后对应NUMA node 组合的组合标记为false。

6. 根据权利要求1所述的基于kubelet的NUMA架构资源分配方法，其特征在于，所述较佳的NUMA node组合为两个组合标记均为false的NUMA node组合中NUMA node个数值等于基准值的NUMA node 组合，或者为两个组合标记为false且NUMA node个数值等于基准值的NUMA node 组合中NUMA node距离最短的NUMA node 组合；

将各组件的NUMA node 组合进行全排列后进行合并之前，还包括：从各组件的NUMAnode 组合中分别选取各组件的最小NUMA node个数值，然后从各组件的最小NUMA node个数值中选取最大值作为基准值。

7. 根据权利要求1所述的基于kubelet的NUMA架构资源分配方法，其特征在于，将最佳的NUMA node组合中的资源分配给所述Pod时，具体包括：调用CRI接口，将最佳的NUMA node组合中的NUMA资源分配给Pod对应的容器。

8.一种基于kubelet的NUMA架构资源分配系统，其特征在于，包括：

用户端，用于创建应用Pod，并按需给所述Pod添加用于表示应用是访存密集型应用的标记；

k8s集群，用于将Pod应用调度到工作节点；

工作节点，用于执行权利要求1~7任一所述的基于kubelet的NUMA架构资源分配方法。