Kubelet从入门到放弃：拓扑管理(上)

时间  2021-08-14 标签 node nginx git github 算法 服务器 markdown 网络 机器学习 ide

<Kubelet从入门到放弃>系列将对Kubelet组件由基础知识到源码进行深刻梳理。上一篇zouyee带各位看了CPU 管理的相关内容，其中说起拓扑管理，本文将对此进行详细剖析,拓扑管理在Kubernetes 1.18时提高为Beta。 TopologyManager功能可实现CPU、内存和外围设备（例如SR-IOV VF和GPU）的NUMA对齐，从而使集群知足低延迟需求。node

1、背景介绍nginx

注：下文TopologyManager简称为拓扑管理器git

1.1 需求说明github

随着单服务器节点内的处理器数量、硬件加速器及其余外围设备日益增多，愈来愈多的系统利用 CPU 和硬件加速器的组合来支持对延迟要求较高的任务和高吞吐量的并行计算。 这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。如何优化延迟敏感型的高性能并行计算应用的性能成了一个重大的挑战。

在引入拓扑管理器以前，CPU、内存和设备管理器在资源分配决策上彼此独立。 这可能致使在多处理系统上出现与指望不符的资源分配，因为这些与指望不一致的分配，对性能或延迟敏感的应用将受到影响，例如， CPU 和设备是从不一样的 NUMA 节点分配的，所以会致使额外的延迟。为了得到最佳性能，须要进行与 CPU 隔离、内存和设备局部性等有关的优化。 

拓扑管理器是Kubelet中ContainerManager组件的一部分，充当存储分配资源信息的角色，以便ContainerManager组件能够作出与拓扑结构相适应的资源分配决策，以便在资源分配的时候实现拓扑结构上的对齐。注意拓扑管理不是单独起做用的，它和CPU manager、memory manager、Device manager共同为Pod分配资源，优化资源访问。
复制代码

1.2 NUMA算法

在CPU管理中，咱们已经介绍了NUMA技术（再回顾一遍）。服务器

NUMAmarkdown

NUMA，之内存访问的不一致性为代价，减轻对总线和memory的带宽需求。这种结构对进程调度算法的要求较高，尽可能减小跨Node的内存访问次数，以提高系统性能。Core之间会共享总线、内存等资源。若是Core的数量较少，则没什么问题，但随着Core的增多，对总线以及内存带宽的需求就会显著增大，最终总线和内存会成为系统性能的瓶颈。网络

以下图所示，一个NUMA Node包括一个或者多个Socket，以及与之相连的local memory。一个多核的Socket有多个Core。若是CPU支持HT，OS还会把这个Core当作 2个Logical Processor。机器学习

  • Socket是一个物理上的概念，指的是主板上的cpu插槽
  • Node是一个逻辑上的概念，上图中没有说起。因为SMP体系中各个CPU访问内存只能经过单一的通道，致使内存访问成为瓶颈，cpu再多也无用。后来引入了NUMA，经过划分node，每一个node有本地RAM，这样node内访问RAM速度会很是快。但跨Node的RAM访问代价会相对高一点,咱们用Node之间的距离（Distance，抽象的概念）来定义各个Node之间互访资源的开销。
  • Core就是一个物理cpu,一个独立的硬件执行单元，好比寄存器，计算单元等
  • Thread就是超线程（HyperThreading）的概念，是一个逻辑cpu，共享core上的执行单元

2、功能介绍ide

2.1 相关配置

在Kubernetes 1.18版本以前若须要启用拓扑管理器，须要在Kublet的特性门控处启用该特性。 从Kubernetes 1.18 版本开始，这一特性默认启动。--feature-gates="...,TopologyManager=<true|false>"

为了知足定制对齐方式需求，拓扑管理器提供了两种不一样的方式：scope 和 policy。

  • scope 定义了资源对齐的粒度（当前提供pod与 container 两种级别）。
  • policy 定义了对齐时实际使用的策略（当前提供best-effort、none、restricted、single-numa-node 等）。

注意：为了将 Pod 中的 CPU 与其余请求资源对齐，须要启用CPU 管理而且配置适当的 CPU 管理策略。

a. 做用域

正如上文所述，拓扑管理器提供如下两种不一样的资源对齐粒度：

  • container （默认）
  • pod

在 kubelet 启动时，可使用 --topology-manager-scope 标志来配置其中任一粒度。

1）容器做用域

默认使用的是 container 做用域，拓扑管理依次进行一系列的资源对齐， 即对每个容器（包含在一个 Pod 里）单独计算对齐。 拓扑管理会把单个容器任意地对齐到 NUMA 节点上。

2）Pod做用域

在启动 kubelet时，配置 --topology-manager-scope=pod ，便可对齐粒度为 pod 。

该做用域容许把一个 Pod 里的全部容器做为一个分组，分配到一个共同的 NUMA 节点，即拓扑管理会把一个 Pod 当成一个总体， 而且试图把整个 Pod（全部容器）分配到一个单个的 NUMA 节点或者一个共同的 NUMA 节点集。 下例说明了拓扑管理器在不一样的场景下使用的对齐方式：

  • 全部容器能够被分配到一个单一的 NUMA 节点；
  • 全部容器能够被分配到一个共享的 NUMA 节点集合。 整个 Pod 请求的某种资源总量经过 request/limit公式计算， 所以，对某一种资源而言，该总量等于如下数值中的最大值：
  • 全部应用容器请求之和
  • Init容器请求的最大值 对于延迟敏感或者 IPC 高吞吐量工做负载，在配置Pod 做用域及 single-numa-node 拓扑管理策略时，能够把一个 Pod 里的全部容器都放到单一 NUMA 节点， 使得该 Pod 消除了 NUMA 之间的通讯开销。 在 single-numa-node 策略下，只有当可能的分配方案中存在合适的 NUMA 节点集时，Kubelet才会准入该Pod。 以下述的示例：
  • 节点集只包含单个 NUMA 节点时，Pod 就会被准入
  • 节点集包含多个 NUMA 节点时，Pod 会被拒绝 简而言之，拓扑管理器首先计算出 NUMA 节点集，而后使用拓扑管理策略来测试该集合， 从而决定拒绝或者接受 Pod。

b. 策略

拓扑管理支持四种分配策略，在 Kubelet 启动时，能够经过 Kubelet命令行 --topology-manager-policy 设置。 当前支持的策略有四种：

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

1）none

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

2）best-effort

对于 Guaranteed 类Pod 中的每一个容器，配置 best-effort 拓扑管理策略的 kubelet 将调用每一个Hint Provider以肯定资源可用性。 使用此信息，拓扑管理器存储该容器的首选亲和性NUMA 节点。 若是亲和性不是首选，则拓扑管理器将存储该亲和性，而且不管如何都将 Pod 接纳到该节点。

以后Hint Provider在进行资源分配决策时使用该信息。

3）restricted 策略

对于 Guaranteed 类 Pod 中的每一个容器， 配置了 restricted 拓扑管理策略的 Kubelet 调用每一个Hint Provider以肯定其资源可用性。 使用此信息，拓扑管理器存储该容器的首选亲和性 NUMA 节点。 若是亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod 。 这将致使 Pod 处于 Terminated 状态。Pod调度失败，Kubernetes 调度器不会尝试从新调度该 Pod，建议使用 ReplicaSet 或者 Deployment部署 Pod。

若是 Pod 被容许运行在某节点，则 Hint Provider 能够在作出资源分配决策时使用此信息。

4）single-numa-node 策略

对于 Guaranteed 类 Pod 中的每一个容器， 配置了 single-numa-nodde 拓扑管理策略的 Kubelet 调用每一个Hint Provider以肯定其资源可用性。 使用此信息，拓扑管理器肯定单一 NUMA 节点亲和性是否可能。 若是是这样，则拓扑管理器将存储此信息，而后Hint Provider能够在作出资源分配决定时使用此信息。 若是不知足，则拓扑管理器将拒绝该Pod ，这将致使 Pod 处于 Terminated 状态。

一旦 Pod 处于 Terminated 状态，Kubernetes 调度器将不会尝试从新调度该 Pod。 建议使用 ReplicaSet 或者 Deployment 来从新部署 Pod。

2.2 Pod配置

注意：关于Pod三种QoS介绍，后续会详细说明。

由于没有指定资源 requests 或 limits，该 Pod 以 BestEffort QoS 运行。

spec:
  containers:
  - name: nginx
    image: nginx
复制代码

由于 requests少于 limits，该 Pod 以 Burstable QoS 运行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
复制代码

针对上述 Pod，若是选择的策略是 none 之外的任何其余策略，拓扑管理器都会评估这些 Pod 的资源使用。 拓扑管理器会调用Hint Provider，得到拓扑结果。 若策略为 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"
复制代码

上述 Pod由于其 requests 值等于 limits 值 ，所以以 Guaranteed QoS 运行。

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由于未指定 CPU 和内存请求，因此 Pod 以 BestEffort QoS 类运行。

总结以下：

  1. 对于 Guaranteed 类的Pod, 若是CPU 请求数为整数，CPU 管理器策略为static 时，将返回与 CPU 请求有关的hint， 而设备管理器将返回有关所请求设备的hint。对于 Guaranteed 类的 CPU 请求可共享的 Pod（非整数CPU），CPU 管理器策略为static 时，将返回默认的拓扑hint，由于没有排他性的 CPU 请求，而设备管理器则针对所请求的设备返回有关hint。在上述两种 Guaranteed Pod 的状况中，CPU 管理器策略为none时， 返回默认的拓扑hint。
  2. 对于 BestEffort Pod，因为没有 CPU 请求，CPU 管理器策略为static时， 将发送默认hint， 而设备管理器将为每一个请求的设备发送hint。

基于此信息，拓扑管理器将为 Pod 计算最佳hint并存储该信息，为 Hint Provider在进行资源分配时使用。

2.3 示范说明

例如，在图1中，包含2个NUMA节点，2个Socket（每一个Socket具备4个CPU，2个GPU和2个NIC），CPU 0-三、GPU 0和NIC 0在Socket 0中，其属于NUMA 0节点，CPU 4-七、GPU 1和NIC 1在Socket 1中，其属于NUMA 1节点。

只有相应外设实现Device Plugin接口，且Kubelet启用Device Manager时，Pod才可以从设备插件提供的可用资源中请求设备资源（例如intel.com/sriov、nvidia.com/gpu等）。例如已经完成Device Plugin接口的Nvidia GPU设备插件和Intel SRIOV网络设备插件。

假设Kubelet对于CPUManager启用了static策略，而且gpu-vendor.com和nic-vendor.com的设备插件已实现Device Plugin接口，则下面的Pod配置可使用拓扑管理器以运行其选定的策略：

spec:
   containers:
   - name: numa-aligned-container
     image: alpine
     resources:
         limits:
             cpu: 2
             memory: 200Mi
             gpu-vendor.com/gpu: 1
             nic-vendor.com/nic: 1
复制代码

按照图1资源状况，资源对齐结果以下所示：

{cpu: {0, 1}, gpu: 0, nic: 0}
{cpu: {0, 2}, gpu: 0, nic: 0}
{cpu: {0, 3}, gpu: 0, nic: 0}
{cpu: {1, 2}, gpu: 0, nic: 0}
{cpu: {1, 3}, gpu: 0, nic: 0}
{cpu: {2, 3}, gpu: 0, nic: 0}

{cpu: {4, 5}, gpu: 1, nic: 1}
{cpu: {4, 6}, gpu: 1, nic: 1}
{cpu: {4, 7}, gpu: 1, nic: 1}
{cpu: {5, 6}, gpu: 1, nic: 1}
{cpu: {5, 7}, gpu: 1, nic: 1}
{cpu: {6, 7}, gpu: 1, nic: 1}
复制代码

注意：（再次申明）若是某个Pod被拓扑管理器拒绝，它的状态将为Terminated，并带有一个Pod准入错误和“TopologyAffinityError的缘由说明。 一旦Pod处于该状态，Kubernetes调度程序将不会尝试从新调度。

mp.weixin.qq.com/s/L02BjTt4Z…

后续相关内容，请查看公众号：DCOS

1.kubernetes.io/blog/2020/0…
2.kubernetes.io/docs/tasks/…
3.kubernetes.io/docs/tasks/…
4.github.com/kubernetes/…

联系我们 沪ICP备13005482号-10