Kubelet 从入门到放弃：拓扑管理 (上)
<Kubelet 从入门到放弃>系列将对 Kubelet 组件由基础知识到源码进行深入梳理。上一篇 zouyee 带各位看了 CPU 管理的相关内容，其中提及拓扑管理，本文将对此进行详细剖析,拓扑管理在 Kubernetes 1.18 时提升为 Beta。 TopologyManager 功能可实现 CPU、内存和外围设备（例如 SR-IOV VF 和 GPU）的 NUMA 对齐，从而使集群满足低延迟需求。
一、背景介绍
注：下文 TopologyManager 简称为拓扑管理器
1.1 需求说明
随着单服务器节点内的处理器数量、硬件加速器及其他外围设备日益增多，越来越多的系统利用 CPU 和硬件加速器的组合来支持对延迟要求较高的任务和高吞吐量的并行计算。 这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。如何优化延迟敏感型的高性能并行计算应用的性能成了一个重大的挑战。
在引入拓扑管理器之前，CPU、内存和设备管理器在资源分配决策上彼此独立。 这可能导致在多处理系统上出现与期望不符的资源分配，由于这些与期望不一致的分配，对性能或延迟敏感的应用将受到影响，例如， CPU 和设备是从不同的 NUMA 节点分配的，因此会导致额外的延迟。为了获得最佳性能，需要进行与 CPU 隔离、内存和设备局部性等有关的优化。
拓扑管理器是 Kubelet 中 ContainerManager 组件的一部分，充当存储分配资源信息的角色，以便 ContainerManager 组件可以做出与拓扑结构相适应的资源分配决策，以便在资源分配的时候实现拓扑结构上的对齐。注意拓扑管理不是单独起作用的，它和 CPU manager、memory manager、Device manager 共同为 Pod 分配资源，优化资源访问。
1.2 NUMA
在 CPU 管理中，我们已经介绍了 NUMA 技术（再回顾一遍）。
NUMA
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.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 类运行。
总结如下：
对于 Guaranteed 类的 Pod, 如果 CPU 请求数为整数，CPU 管理器策略为 static 时，将返回与 CPU 请求有关的 hint， 而设备管理器将返回有关所请求设备的 hint。对于 Guaranteed 类的 CPU 请求可共享的 Pod（非整数 CPU），CPU 管理器策略为 static 时，将返回默认的拓扑 hint，因为没有排他性的 CPU 请求，而设备管理器则针对所请求的设备返回有关 hint。在上述两种 Guaranteed Pod 的情况中，CPU 管理器策略为 none 时， 返回默认的拓扑 hint。
对于 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-3、GPU 0 和 NIC 0 在 Socket 0 中，其属于 NUMA 0 节点，CPU 4-7、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 调度程序将不会尝试重新调度。
https://mp.weixin.qq.com/s/L02BjTt4Znpw3KrllkeP-Q
后续相关内容，请查看公众号：DCOS
1.https://kubernetes.io/blog/2020/04/01/kubernetes-1-18-feature-topoloy-manager-beta/</br>
2.https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/</br>
3.https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/</br>
还未添加个人签名 2020.09.22 加入
公众号：DCOS
评论